Damn Vulnerable Linux (DVL) es una distribución especialmente pensada para ser usada en clases de seguridad informática. Dispone de numerosas aplicaciones de seguridad y otras tantas aplicaciones con vulnerabilidades conocidas. Igualmente, podemos encontrar crackmes, exploitmes, y demás retos que nos harán pasar un buen rato. Lo más novedoso es que para la versión Strychnine+E605 se esperan videos demostrativos de las distintas técnicas de ataque y penetración de sistemas que se podrán poner en marcha con DVL. Según el autor la ISO acaba de salir de la grabadora y en estos momentos se están actualizando los mirrors, por lo que cuando terminen, darán el enlace. Ya tenemos diversión para este verano, que por cierto, para el autor de estas líneas acaba de comenzar 🙂 ¡A disfrutar del buen tiempo!
Categoría: Seguridad
HackIt! 2007, buenas sensaciones
Un día después del HackIt! 2007 (Euskal Encounter) hacemos balance: excelente concurso, como siempre, por parte de Txipi de capitán general y Hey_Neken de coronel. 13 pruebas de cracking, criptografía e ingenio. Por nuestra parte «sólo» conseguimos llegar hasta la 10 cuando terminó el concurso, pero creemos que es una buena marca, máxime teniendo en cuenta el atasco general que todos los grupos salvo uno tuvimos en la 5ª. El concurso comenzó hacia las 11 de la noche del viernes. La primera prueba, facilita, pero divertida, pues inicialmente no veíamos el truco Javascript 😉 La segunda, crackeo de un md5, rapidito si sabes el procedimiento (al rico arco iris, arco iris…). Con la 3ª , a desempolvar los desensambladores de Java. La 4ª nos hizo descubrir que también existen para Flash. Y llegó el plato fuerte del HackIt, la china en el zapato, la fatídica Roma clásica (un saludo a todos los sufridores colegas de este año 😉 En nuestro caso, llegamos a eso de las 2 ó 3 de la mañana. Era claro que alguna dificultad extra entrañaría una prueba que desde el principio, intuíamos que se trataba de un cifrado César. Sabíamos que dado que en la 5ª se enviaba el primer email a la organización dando cuenta del progreso, no sería tan facil. A las 6 de la mañana ya empezamos a mosquearnos, porque la hoja de cálculo de nuestro gurú Excel (sí, no hay manera de que se pase a OpenOffice) empezaba a echar humo de tantas posibilidades probadas. Los alfabetos los pusimos de adelante hacia atrás, de lado, boca arriba, en latín y hasta en Euskera, pero nada. No había manera. César con todos los desplazamientos, sustituciones, análisis de frecuencia, análisis de distancia entre las letras de posibles palabras, nada. No había manera…. 7 de la mañana del sábado, primeras bajas, desfilamos hacia los sacos de dormir. 11 de la mañana, vuelvo de la ducha y las primeras conversaciones en torno a soluciones alternativas, jeje… cuánto masoca. Alguno no ha podido ni dormir dándole vueltas. Café, café… bendito café. Vamos allá, no podemos clavarnos así en la 5ª. Mediodía y hora de comer. Nothing de nothing. No hay manera. El gurú Excel empieza a cabrearse de verdad. Discusiones internas sobre criptogramas de la roma clásica y posibilidad de cifrar un mensaje sólo con las letras de los números romanos. Más café. Una vuelta por la Euskal para ver si somos los únicos empantanados en el 5º y sin ver ninguna vía de escape tras más de 10 horas con lo mismo. ¡Oh sorpresa! Salvo 1 grupo todos los demás estamos pegándonos con la misma prueba (y algunos con anteriores 😉
Reunión de urgencia con bandera blanca y otros dos grupos. Se pacta una alianza temporal para pasar la 5ª (txipi: perdona nuestros pecados, ha sido por causa mayor X-) … 5 de la tarde . Cuando ya estábamos sacando las cuchillas para cortarnos las venas (alguno quería «hablar» con txipi antes, jejeje…) llegan dos mensajeros de uno de los grupos aliados con cara de o haberse metido un chute o haber pasado la prueba. B . Nos dan alguna pista, pero no nos cuentan el procedimiento, lógico, para poder sacarnos ventaja previamente. 17:30. El Excel vuelve a echar humo. «Comienza por C». «La habéis visto, sólo que no la habéis entendido». … pampi… pamplon…. verbum… est. Aaaargghhhhh…. 18:00, un 4º grupo, del que sólo queda 1 miembro despierto con los ojos ensangrentados nos solicita ayuda. Cuando voy a su puesto se me ilumina la cara: «¡pero si lo tienes delante!» Un bug arrastrado desde la HackIt 2006 que impide darle a intro para probar el texto introducido en el formulario ha hecho que no la diera por válida («hay que pulsar el botón de enviar, no vale darle a intro!»). Más de 14 horas después, conseguimos superar la 5ª prueba. Pequeño rifi-rafe en el el chat. «Elegir otro algoritmo de cifrado sería apócrifo» son las primeras palabras de txipi. Creo que en esos primeros instantes no se daba cuenta del nivel de dificultad extra que entrañaba el alfabeto elegido (mucho más allá del algoritmo usado, que efectivamente era trivial) . Nos llueven los privados en el chat («ha llegado a mis oídos que habéis pasado la 5ª. Ayudadnos o nos suicidamos!!!!!!!!!!!!!!!!!!!!!») Jejeje… angelitos. Unas horas después ayudamos a varios grupos (y conocimos de paso a algunos miembros de la ORG de la NavarParty).
La 6ª resuelta en 15 minutos (gracias al entrenamiento con ELF+UPX+GDB del que ya hablamos en DiarioLinux) . La 7ª nos enfrentó con un .exe, del que salimos airosos en 1 hora con la ayuda de OllyDBG. De la 8ª nos salvó AirCrack, tras varias horas de ataque de todos los colores (diccionario – en castellano,inglés – + brute-force) con WepLab . La 9ª, en mi opinión, una obra maestra, una joya que me encantó: ataque contra unas tramas SIP, oír las pistas del organizador, búsqueda del .zip y crackeo con Advanced Zip Password Recovery (otra joyita de la gente de Elcomsoft).
Y llegamos a la 10 (4 o 5 de la madrugada del sábado al domingo), donde nos volvimos a atascar. ¿Cómo poner un watch a una dirección de memoria con GDB? Cabeceras ELF volatilizadas. Can’t access memory address. Memory address out of bounds. «¿Alguien sabe cómo buscar la dirección de una cadena de texto en GDB?». «¡Bájate el IDA para Linux!». oooppps… pero si es de pago. Probemos con LiDA. Buah! no sabe abrir el ejecutable … «Pues prefiero el GDB»… «Si hubiera un Olly para Linux». O sea: «What I really want is a debugger which is as functional and useable as OllyDbg but for Linux». Y lo encontramos, se llama EDB (Evan’s Debugger), y aunque todavía le queda camino, le da mil vueltas a GDB o a sus interfaces (DDD y compañía). Pero demasiado tarde. ¡Gong! 4 de la tarde del domingo 22 de Julio. Fin de la fiesta. Hasta el año que viene.
Nota: esperaré a que txipi publique las pruebas en su blog para comentarlas. También nos gustaría saber cuál fue la clasificación final. No puedo finalizar este pequeño resumen de la prueba sin enviar de nuevo mis agradecimientos y respetos por el excelente concurso que una vez más ha vuelto a organizar el señor Pablo G. para la HackIt . Esperamos ansiosos, desde ya, la edición del 2008; eso sí, a ser posible, sin pruebas killer nº 5 como la de este año 😉 Greetings for all the hacking teams.
Repaso al HackIt’06 : atascado en el nivel 11
Me he quedado atascado en el nivel 11. El proceso de solución que he seguido es el que plantea Txipi, el organizador de la prueba, en su blog. En esa página podemos encontrar indicaciones para solucionar casi todos los retos planteados, pero en ocasiones son precisamente eso, indicaciones, no se muestra el proceso en detalle.
El nivel 11 nos plantea el siguiente reto: dado un fichero ejecutable ELF, crackearlo para obtener la clave que esconde. Tras analizar el fichero vemos que está cifrado/comprimido con UPX (upx.sourceforge.net) Este tipo de compresión no es como la típica .zip, .rar, etc. sino que UPX comprime las ecciones internas del ELF, añadiendo al ejecutable una rutina de autodescompresión.
Lo anterior, si fuera tal cual, cual no sería problemático: se descomprime con el propio upx y listo (upx -d fichero_elf) . Pero estando en el nivel 11 del juego, lógicamente, la cosa no es tan sencilla. El autor del reto ha eliminado cadenas del ejecutable de tal forma que al intentar la escompresión (upx -d) el UPX dice que ese fichero NO está comprimido con él. Así que hay que reconstruir las secciones del UPX (básicamente, saber qué han eliminado/cambiado y volverlo a poner). El proceso consistiría en comprimir con UPX varios archivos ejecutables onocidos y extraer las cadenas o características propias de UPX. Una vez hecho eso y con el conocimiento de las cadenas típicas que un fichero comprimido con UPX muestra, comparar con el archivo que nos dan y ver qué demonios han eliminado. Tras hacer este trabajo, podemos ver que han sustituido las apariciones de la cadena UPX (55 50 58 en hexadecimal) por (20 20 20).
¡Ah! parece pan comido. Más adelante, se ve que no sólo han hecho la sustitución previamente indicada, sino que también han cambiado una cadena más completa del tipo «This program has been compressed using UPX version .01…» o similar, convirtiéndola también a caracteres 20 20 20.
Hay distintos editores de hexadecimal, pero como últimamente uso VIM para casi todo, he editado también el fichero ELF con este editor (hay que teclear :%!xxd para convertirlo a hexadecimal y poder editar. Una vez terminada la edición, hay que realizar el proceso inverso con :%!xxd -r y guardar :wq) Tras arreglarlo, intentamos la descompresión y upx dice que tururú, que las cabeceras siguen estando mal.
Analicemos más a fondo: los últimos bytes de un fichero UPX suelen seguir también un patrón del tipo XXXXnumeritosYYYY. Y podemos comprobar que el fichero que nos dan, NO lo sigue. Añadimos esa última sección y ahora, el comando «upx -l» indica que OK, que eso sí es un fichero UPX, pero cuando lanzamos el comando «upx -d» contra el fichero arreglado, para descomprimirlo, nos indica el siguiente error
Exception: compressed data violation
y no descomprime nada. El problema es que no sé cómo arreglar este problema, me he atascado :-O . En mi opinión l error se debe a que en la cadena del final, XXXXnumeritosYYYY, los numeritos, tras distintas pruebas, he visto que son DISTINTOS dependiendo del
archivo que comprimamos. Y ahí me pierdo, porque no sé qué algoritmo seguir para generarlos… Aunque tal vez no sea ese el problema. ¡ Agradecería cualquier ayuda !
El archivo level-11-solved es el que he reconstruído a partir del original para conseguir que UPX lo detecte como propio.
Ingeniería Inversa: cómo destripar un ELF
Esta semana ha sido muy ajetreada (trabajos, exámenes, prácticas…) y para liberar un poco de stress, aparte de ir a hacer un poco de footing, he desempolvado un viejo problema del concurso de HackIt! de la Euskal Encounter 2006 y le he dedicado algunos minutos (bueno, vale, tal vez algo más O:-) El reto consiste en ‘romper’ un fichero ejecutable Linux (formato ELF) para obtener una clave. Como ayuda, partimos del siguiente programa C (lógicamente no es exactamente el que genera el ejecutable, pero nos sirve como pista para ver por dónde van los tiros):
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char *argv[]){
char serial[15] = "UNREGISTERED";
char login[20]; printf("Introduzca su nombre de usuario: ");
gets(login);
printf("Comprobando número de serie... %sn", serial);
if(!strcmp(serial, "00-11-22-33-44"))
{
printf("Hola %s, bienvenido al sistema...n", login);
printf("La contraseña del siguiente nivel es LALALALAn");
} else
{
printf("Lo siento %s, su numero de serie ha caducadon", login);
exit(-1);
}
}
Sigue leyendo Ingeniería Inversa: cómo destripar un ELF