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: blahusuario: campus02,
clave: blahzUhmm 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:
!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.
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 //
