RootedCon CTF writeup niveles 1 y 2

A petición de Pablo Catalina (@xkill), voy a ir poniendo la solución del CTF por partes. Ahora voy a publicar la solución de los niveles 1 y 2 (en este último es donde más gente ha quedado atascada), y cada semana publicaré un nuevo nivel.

Ahí vamos … 🙂

Reto 1

Al validarse en el reto, a cada participante le aparecía una URL de acceso diferente, ya que cada uno debíamos atacar a una máquina virtual distinta. En mi caso, la URL era http://172.23.23.24 y tras acceder por web, únicamente aparecía la siguiente imagen:

Mirando el código fuente de la página, nada más que se ve esto:

De manera que todo apunta a una prueba de esteganografía.

Lo primero que hice fue bajarme la imagen y hacer un strings para ver si salía algo de texto, luego la analicé con un editor hexadecimal (concretamente con el gHex2) por si aparecía algo extraño. También miré, sin éxito, con el 010 Editor, que trae muchos templates para analizar diferentes formatos de ficheros.

Como no sacaba nada en claro, el siguiente paso fue abrirla con el Gimp y empezar a cambiar tonos, brillos, etc, etc, etc. Tampoco hubo suerte.

Como último recurso, me puse a probar, a voleo, diferentes programas de esteganografía (steghide, xdeview, snowdrop, enscribe, openstego, etc) hasta que di con uno (el outguess) que, al fin, sacó los datos ocultos:

La respuesta para pasar el reto es: Lamde:JodNes=

Reto 2

Al pasar el primer reto se obtiene un usuario y una contraseña, pero nada más. Ningún acceso a una nueva web donde validar esos datos ni nada, así que no queda otra que hacer un escaneo a ver si encontramos algo:

Para ello usé DirBuster: http://www.owasp.org/index.php/Category:OWASP_DirBuster_Project

Tras unos minutos de escaneo encontró el directorio: /backstage con algunos subdirectorios. Tras acceder a él se puede ver el acceso a lo que parece un file manager:

Lo primero que trato de hacer es lo más lógico, dado que en el reto anterior obtuve un usuario y una contraseña, traté de usarlos para entrar, pero me decía que los datos eran incorrectos.

Este reto me llevó casi un día resolverlo. La verdad es que fue una verdadera agonía.

Analizando el código, vi que se trataba de la última versión de PHPFileNavigator v2.3.3 (http://pfn.sourceforge.net/) así que lo primero fue buscar alguna vulnerabilidad conocida en securityfocus, exploit-db, etc, sin éxito. El segundo paso fue descargar los fuentes y analizarlos para ver un poco cómo estaba programado y buscar algún posible bug.

Bajé los fuentes y le eché un ojo a los 3 posibles formularios de entrada:

– El de validación de usuario: index.php

– El de recuperación de contraseña: contrasinal.php

– El de activación de nueva contraseña: activar_contrasinal.php

Todos ellos filtraban bien todos los valores que se obtenían.

Echando un ojo a los PHP que se incluían tampoco encontré forma de inyectar nada ya que en todos tenía un control de sesiones. Así que volví a cargar estos 3 formularios en la web para jugar un poco con ellos.

Me llamó la atención el de recuperación de contraseña, ya que nos avisa si el usuario que introducimos es correcto o no:

Usuario: admin

Correo electrónico: x@x.com

No existe ningún usuario con esos datos, por favor comprueba que el usuario y el correo son correctos.

Usuario: Lamde

Correo electrónico: x@x.com

Este usuario no tiene permisos para cambiar su contraseña, por favor contacta con el administrador.

Usuario: lamde

Correo electrónico: x@x.com

Este usuario no tiene permisos para cambiar su contraseña, por favor contacta con el administrador.

(Nota: Esto es un fallo del reto. Luego explicaré por qué)

Tras perder bastante tiempo con los 3 formularios y, ya bastante desesperado, le pasé un par de fuzzers que tengo programados para buscar fallos de SQLi, ICH, RCE, LFI, RFI por si se me escapaba algo, pero tampoco encontró nada.

Como dije antes, perdí casi un día con este reto y no encontré ninguna vulnerabilidad nueva.

Al final, resultó que el usuario era todo en minúsculas y la contraseña tal cual nos salió en el reto anterior: lamde / JodNes=

(Nota: dije antes que era un fallo del reto porque en ambos casos (con Lamde y con lamde), en la pantalla de recuperación de contraseña, nos dice que el usuario no tiene permisos, cuando en el primer caso debería decir que no existe el usuario, tal y como ocurrió cuando probé con admin (y con otros tantos). Esto fue el motivo por el que perdí tanto tiempo y por el que se quedaron atascados muchos de los participantes.)

Una vez que conseguí acceso al dichoso file manager, se podían ver un montón de ficheros PDF, que supongo estarían para despistar, porque cuando se accede a una web de este tipo, al primer lugar a donde se te van los ojos es a los permisos de escritura. En este caso sí que teníamos permisos, por lo que subí un phpinfo (por mera curiosidad) y una shell.

Como para resolver la prueba pedía: ‘numero, numero, numero, …’, me imaginé que se trataba de un knock, así que tras verificar que el demonio knockd estaba corriendo, el siguiente paso era ver los puertos usados:

Editando con un cat el fichero de configuración /etc/knockd.conf vemos:

Los puertos de desbloqueo y la contraseña para pasar este segundo reto es:

7000,8000,9000,2323,23,65000