How to PASS wargame CP 2009: WEB SECURITY

Hola a todos!, continuamos con las soluciones de los niveles relacionados con el tema de seguridad en web.

// RETO 1 //

Cuando le hacemos click en el link de login obtenemos:

Vemos un sistema de autenticación normal, usuario y clave, sin embargo mas abajo tenemos un link de recuperar contraseña. De la experiencia y visitando uno que otro sistema, me he dado cuenta que aveces los desarrolladores ponen mucho énfasis en proteger sus sistemas de autenticación, pero se descuidan con los sistemas secundarios, como los recuperadores de contraseñas, inscripción de usuarios y cosas así. La seguridad tendría que abarcar cada posible entrada de usuario.

Cual atacarías primero?, la entrada principal o el sistema de recuperación de contraseñas?.

Nos hacen una pregunta personal del usuario, así que debemos conocer un poco mas del usuario para poder tener esos datos. Que tal si lo buscamos en google?

En google no vemos nada, en otros buscadores tampoco, intentamos visualizar el sitio, pero no hay nada, intentamos pruebas básicas de sql injection y nada ...

Bueno, después de pensarlo con mas calma leemos nuevamente y nos dicen que este sujeto usa mucho las redes sociales, así que tendrá que ser un usuario activo de tuenti, facebook, twitter, identi.ca, etc, etc. Lo que hacemos entonces es buscar su nombre de usuario en cada una de estas redes y adivinen donde lo encontramos?

En los microposts podemos leer la respuesta a la pregunta secreta: R5CopaTurbo.

Y con esta clave obtenemos la contraseña del usuario que nos esta pidiendo el nivel

Y listo, pasamos el nivel!, fácil eh?, como siempre!, después de hacerlo se da uno cuenta que era hasta fácil, pero la verdad perdí mucho tiempo buscando al campurriano!!!!

Conclusiones:

1. Un nivel bueno para ser el primero de esta serie.

2. La moraleja es: ¿ Que tantas cosas dices en tus blogs, wikis y redes sociales?, ¿Que tanto "material" hay disponible sobre tí para perfilar un ataque a un recordatorio de contraseñas?.

3. ¿Se asustó?, go and chage it!

4. Un sitio de busqueda de nicks registrados en diferentes servicios muy interesante.

// FIN RETO 1 //

Vamos ...

// RETO 2 //

Vemos otro sistema de autenticación ...

Intentamos usuarios y claves al azar y no pasa nada, luego observamos el código fuente y descubrimos que hay un archivo llamado login.swf.

Debes concluir al igual que yo, que el sistema de validación lo hace un archivo de flash. :p

Que hacemos entonces?

Lo primero es descargar el archivo y lo segundo tratar de abrirlo (desemsamblarlo) para ver que tiene por dentro.

root@plasma:~/Desktop# apt-cache search flasm
flasm - assembler and disassembler for Flash (SWF) bytecode
root@plasma:~/Desktop# apt-get install flasm
Reading package lists... Done
Building dependency tree
Reading state information... Done

Desensamblamos y leemos la salida:

root@plasma:~/Desktop# flasm -d login.swf > salida

Leyendo el desensamblado que es una locura, encontramos en las primeras líneas referencias a MD5.

frame 0
constants 'str', '', 'j', 'hex_chr', 'charAt', 'nblk', 'length', 'blks', 'Array', 'i', 'charCodeAt', 'addme', 'rol', 'bitAND', 'bitOR', 'cmn', 'bitXOR', 'x', 'str2blks_MD5', 'a',$
function2 bitOR (r:4='a', r:3='b') ()

Esto me hace pensar que el archivo puede tener una validación donde la contraseña este almacenada en MD5. Entonces la buscamos en el archivo completo (strings -32 salida).

De esa forma encontramos algo que parece un MD5, y como lo crackeamos?, lo primero es intentar con los sitios de crackeo online: 9f29db7287469c5f9520a1f8ddf946f2

• http://passcracking.com/
• http://www.md5crack.com/

Y bueno, encontramos la clave perdida. Y cual es el usuario?, pues como en el enunciado nos dicen que campurriano es el administrador, entonces pruebo con el usuario campurriano y con el usuario admin y sus combinaciones. Ahí termina el nivel ;)

Conclusiones:

1. Deben existir mejores herramientas de desensamblado en .swf, pero flasm fue lo primero que vi.

2. Si deseas asegurar una aplicación programada en flash, entonces usa criptografía fuerte, de modo que no sea vulnerable a desensamblados.

3. Los crackeadores de passwords online son la primera opción a usar cuando requerimos algo rápido. Si pagas por una subscripción seguro que rompes lo que sea :p

// FIN RETO 2 //

go ahead!

// RETO 3 //

De nuevo ...

El código fuente de la página luce muy simple, que hacemos?

Después de desesperarnos un poco podemos plantear diferentes vectores de ataque:

1. hacer fuerza bruta tratando de encontrar archivos o directorios mal ubicado
2. hacer fuzzing para tratar de descubrir problemas en los scripts o en el sitio en general
3. pedir auxilio en el foro, en listas, leer sobre vulnerabilidades web, etc.
4. abandonar el reto :p

Lo que yo hice fue continuar probando posibles entradas maliciosas, hasta que con el símbolo ", saco un error.

El error dice algo acerca de XML y estamos hablando de seguridad en WEB, por lo que me oriento a pensar en un problema de XPATH Injection, la cual esta clasificada como una vulnerabilidad web hace mucho tiempo al igual que los SQL Injection y derivados.

Con esta ruta clara, buscamos información de como inyectarle algo para que nos deje validar.
Podemos intentar algo como:

usuario: xxx" or "1"="1
password: xxx" or "1"="1

Esto efectivamente nos deja pasar y entramos a "un sistema de blogs?" algo simple.

Sigo explorando por todos lados y encuentro algunos scripts de php (ensenia.php, postz.php), pero no logro encontrar cual es la respuesta, será que tengo que inyectar xpath para sacar mas información?, pero ya entre al sistema, para que quiero inyectar mas ...

En fin, después de buscar mucho por ese lado y de leer un poco sobre simplexml (producto del error) decido inventar nombres y rutas a donde se encuentren posibles archivos xml.

• scripts/
• archivos/
• files/
• includes/
• xml/
• bd/
• inc/

De todas estas pruebas me llevo una sorpresa, el directorio xml responde con l siguiente:

El mensaje de advertencia deja mucho que pensar, es una autenticación básica de apache y me esta diciendo que por allí no es, será?. Obviamente intento unas cuantas claves pero no funcionan, en este punto uno puede pensar en un ataque de fuerza bruta contra un sistema de autenticación básica. Bueno, ve a por el!.

El mismo problema de siempre cuando hacemos ataques de fuerza bruta, el tiempo, el tiempo.
Aunque hay un problema mucho peor, no tener afinadas las herramientas. ¿Confias en que tus herramientas realmente hacen lo que dicen?, funcionan?, me he encontrado con herramientas que dan muchos falsos positivos y otras aún peor que bajo mucho stress no se comportan adecuadamente, tengan mucho cuidado con eso ...

Bueno ya empece a desesperarme, busquemos en otros niveles, alguna pista algo interesante ...

Mirando otros niveles me puedo dar cuenta que es necesario conectarse a un servidor ssh, allí me dan el usuario y la clave para conectarme.

usuario: campus01, clave: blah
usuario: campus02, clave: blahz

Uhmm esa clave porque?, sera de blah, blah, blah (cuando una persona habla mucho?), lo que hago entonces es buscar esa palabra en la lista de palabras que tengo llamada all, que en un post anterior dije de donde bajarla.

De la búsqueda encuentro palabras como:

root@plasma:/tmp# grep blah all
bablah
blah
blahlaut
blah
...

Lo que hago es empezar a probar usuarios y claves "custom", pruebo con nombres como: Campu_rriano, admin, administrador, sbd, campus, campus01, campus02, campusxx, mezclandolos con claves con estas claves: blah, blahz, blahs, blashy, etc.

Al tener un diccionario custom, puedo usar una herramienta de fuerza bruta probada y recontraprobada o si tengo mucho tiempo, lo hago a mano!.

Al final y con mucha suerte logro encontrar que la combinación:

usuario: blah
clave: blah

!FUNCIONA!

Pero bueno, al entrar no encuentro nada, es simplemente una página web vacía que no tiene código oculto ni nada, y entonces?.

De aquí podemos analizar varias cosas:

1. Quizás sea un despiste (honeypot :p) para que creamos que hay algo importante en este directorio, así que estaríamos perdiendo las horas de pruebas que hemos realizado hasta el momento.

2. Puede ser que se aseguraron de proteger el directorio porque hay archivos importantes que no estan listados, pero que existen, esto es muy probable.

Que hacemos entonces?, nuevamente empezamos a probar nombres y posibles rutas, que tal si probamos con archivos .inc, .php, .xml, .css ??

Basandonos en los nombres de los scripts que hemos visto, en la salida de los .css que hemos encontrado, después de intentar un buen rato encontramos que hay un archivo llamado posts.xml, ese archivo al ser .xml se visualiza como un archivo de texto plano en el navegador
y puedo observar su contenido:

En el comentario estaba la clave que me pasaría de nivel y listo, después de mucha fuerza bruta y de reintentar y reintentar pudimos encontrar la clave correcta.

Conclusiones:

1. Es importante que piensen que en un wargame debemos usar herramientas que realmente sepamos lo que hacen, que estén comprobadas y que las hayamos afinado para lo que vayamos a realizar. Para esto es clave primero hacer unos "pilotos de ataque", para comprobar su efectividad. de lo contrario nos harán perder el doble del tiempo, ademas de hacernos abandonar la ruta correcta.

2. Los ejercicios de fuerza bruta son desesperantes.

3. Yo creo que el nivel lo pase de una forma que no era, porque encontrar a fuerza bruta la autenticación blah, blah, me permitió pasar también una parte del próximo nivel y leyendo la explicación de la gente de sbd, no creo que el asunto fuera por este lado, pero vale no?

4. Si esta no era la ruta que ellos esperaban, entonces como se supone que podía leer un archivo .xml, inyectando con xpath?, si alguien tiene la solución por favor que la publique.
(update 1 - 20 agosto/2009) Listo ya la tengo, supuestamente usando este tool.

5. Estuvo muy interesante este nivel. thx sbd.

// FIN RETO 3 //

Y para finalizar ...

// RETO 4 //

Lo primero con lo que nos encontramos es con un sistema de validación, otra vez, pero como dije antes, adivinen cual es el usuario y la clave? (blah:blah)

Una vez adentro leemos otra historia mas acerca de Campu_rriano y seguimos el link que nos indican:

De este error podemos ver que el sistema esta esperando que ingresemos un parámetro id, en el script login.php. Al hacer algunas pruebas cambiando el valor del id, nos damos cuenta que el ejercicio posiblemente es de sql injection puesto que obtengo resultados diferentes a medida que cambio parámetros o uso la instrucción SELECT, UNION, etc.

El sistema por defecto muestra un nombre y un usuario, pero suponemos que en las tablas de "mysql?" debe haber un campo de password, pero que el script login.php no lo muestra porque solo saca las posiciones de usuario y nombre. Como le hacemos cambiar de parecer?

Pues lo obligamos a que nos muestre el otro campo haciendo un SELECT incorrecto que no retorne nada y haciendo un UNION que retorne lo que quiero:

id=400' UNION SELECT 1,2

Así en vez de mostrarnos el nombre y el usuario, nos mostraria el usuario y el password, realmente nada raro, solo un ataque de sql injection y volviendo a leer el enunciado entonces nos damos cuenta que es un ataque de sql injection a ciegas ;), posiblemente el bug se encuentre con una herramienta automatizada, pero no vale la pena usarla, ya que el mismo reto nos dice cual es la variable a inyectar. El password mostrado nos dejaba pasar el nivel.

Conclusiones:

1. Un reto fácil porque ya tenia el usuario de la autenticación básica.

2. SQL injection siempre estará de moda en los wargames, hasta que aparezca algo mas entretenido.

3. No me toco cambiar todas las peticiones GET por PUT o algo similar, puesto que me autentique correctamente en el formulario, esto fue una ventaja, ademas me ahorro la ruta de ir a configurar un proxy para que cambiara el método de petición.

4. Nos leemos en la proxyma entrada. Comentarios / Sugerencias, en el link de abajo :p

// FIN RETO 4 //