lunes, 20 de diciembre de 2010

Este fin de semana estuvo movido por el 1er CTF - RuCTF, (1 cada año) en el cual tuve la posibilidad de participar por Colombia con el grupo de Hacking LowNoiseHG. Universidades de Rusia, Italia, Alemania, Francia, España y Colombia (Uniandes, UNAL, UDEA) entre otras participaron en este evento.


Para los que no sepan que es un CTF (Capture The Flag) voy a dar una breve inducción.

Se trata de un concurso de Hacking en donde cada equipo se conecta a una red privada mediante una conexion VPN (Virtual Private Network) la cual debe ser configurada y puesta a punto días anteriores al evento, también se debe desacargar una imagen de una máquina virtual que está cifrada con PGP y la contraseña es entregada 1 hora antes de que empiecen a atacar :), ésta imagen contiene 8 aplicaciones que tienen huecos de seguridad que permiten acceder a las banderas de otros equipos.

La idea principal es capturar unas cadenas de texto con un formato definido las cuales se les llama las banderas y básicamente son 31 letras seguidas de un igual ejemplo "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=", una vez capturadas estas banderas hay que enviarlas a un servidor que actúa como jurado y nos va dando puntos por cada vez que enviemos una bandera de otro equipo.

Ya conociendo la idea de lo que es un CTF voy a contar lo que sucedió en este CTF.

Días anteriores estuvimos en la casa de ByteMare preparando la infraestructura y adecuando el espacio para que todo estuviera listo el día del evento.

Nos reunimos 3 horas antes de dar inicio a la competencia para probar que todo funcionara como esperabamos y asi fué, el nerviosismo reinaba en el ambiente y más la curiosidad de saber con qué retos nos ibamos a encontrar.
Más allá de ostentar el 1er lugar con la jugosa suma de 900$ dolares, teníamos la idea de ser los conejillos de india y grabar todos los ataques que nos hicieran los Rusos, para luego tener material de estudio y así aprender de nuevas tecnologías de Hacking, llevándonos una grata sorpresa que cerca de 2 horas despues de haber iniciado el juego pudimos llevar a cabo 8 ataques de manera exitosa, los cuales nos generaron los puntos que con la que a la final terminariamos.
Intentamos crear herramientas que automatizaran los ataques, pero cometimos errores muy inocentes debido a la presión de la emoción que sentíamos en ese momento de saber que estabamos atacando a otros equipos y con ataques 100% exitosos.
Tuvimos que lidiar y tratar de bloquear ataques de todo tipo, como son intrusiones de virus, redirección de información, denegación de servicio y finalmente el objetivo del concurso, captura de nuestras banderas.
Nos defendimos hasta el último segundo lo que nos permitió tener un muy merecido 70% de defensa, comparable con puestos como el 10-20 de las Universidad de Italia, Rusia, Estados Unidos etc, donde los superamos ampliamente.
Luego de 12 horas continuas de
Lo importante de esto fué haber podido poner el nombre de Colombia en este tipo de competiciones y sentir la satisfacción del reconocimiento realizado por los otros equipos respecto a nuestra participación.



domingo, 5 de diciembre de 2010

Se podria decir que quedamos de 2do puesto porque trabajamos en equipo, fuimos superados por un equipo de 2 personas, lo importante era medirnos y pues bueno aca estamos les dejo el trabajo que hicimos (les debo las fotos)

LEVEL 1:

Se bajó el archivo ‘level1’, y se identificó con el comando ‘file’ de Linux que era una imagen BMP:


root@lnhg-lab-1:~# file level1

level1: PC bitmap, Windows 3.x format, 1126 x 73 x 24


El ver la imagen se veía este código de barras:

Al interpretar el código de barras se obtuvo “od fodyh sdud hvwh uhwr hv edvwdqwh pdv vhqflood”, que al procesarlo con rotaciones (ROT23, en este caso), dio “la clave para este reto es bastante mas sencilla”. Así que la solución no era por ahí, pero esos datos se utilizarían más adelante …

Se abrió la imagen BMP en un editor hexadecimal, y en la parte de datos sólo debería haber 000000’s y FFFFFF’s, ya que la imagen era solo blancos y negros, pero había 01’s y FE’s regados por todo lado, así que se determinó que había algún tipo de esteganografía.

Con el programa StegoHide se procesó el archivo BMP, y usando como clave la pista (palabra “imágenes”) se extrajo un archivo ZIP, que contenía un archivo JPG, protegido por clave. Esta segunda clave nos la hab;ia entregado el código de barras, cuando decía que “la clave es bastante más sencilla” … La clave del ZIP es “bastantesencilla”.

El archivo JPG extraído contenía este código de barras QR:

Que al ser decodificado decía: “la clave es: 82d2660c00980b8ba3287af4d35876e34dd436c7”




LEVEL 2:

Se descargó el archivo ‘level2’ y al verificarlo con el comando file aparece que es un pcap,

root@lnhg-lab-1:~# file level2

level2: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)

Al analizarlo, se observan paquetes ICMP con un payload diferente al habitual (16 paquetes ICMP, cada uno con una porción de datos de 23 bytes):


Al extraer toda la información de las porciones de datos, se obtiene (en hexadecimal y en ASCII):


4c6930754c6941754c534167494330754c5334674c6930 Li0uLiAuLSAgIC0uLS4gLi0

754c6941754c5341754c69347449433467494341744c69 uLiAuLSAuLi4tIC4gICAtLi

34674c694167494334674c693475494330674c69416749 4gLiAgIC4gLi4uIC0gLiAgI

4334744c6941750a494330674c533074494341674c6941 C4tLiAu IC0gLS0tICAgLiA

754c693467494341744c5330744c694175494334754c69 uLi4gICAtLS0tLiAuIC4uLi

3074494330754c693475494334754c693074494334674c 0tIC0uLi4uIC4uLi0tIC4gL

533475494334754c693475494334740a494330744c5330 S4uIC4uLi4uIC4t IC0tLS0

75494330754c5334674c5330744c5330674c6934744c69 uIC0uLS4gLS0tLS0gLi4tLi

41744c693475494330754c6941754c6934754c6941744c AtLi4uIC0uLiAuLi4uLiAtL

693475494330744c693475494330744c53307449433075 i4uIC0tLi4uIC0tLS0tIC0u

0a4c693475494330754c6934674c5334744c6941754943 Li4uIC0uLi4gLS4tLiAuIC

34754c693475494330744c533475494334744c53307449 4uLi4uIC0tLS4uIC4tLS0tI

4334674c533475494334754c693475494330744c533075 C4gLS4uIC4uLi4uIC0tLS0u

494330744c5330750a494334674c6934744c5330674c53 IC0tLS0u IC4gLi4tLS0gLS

30744c5334674c5334744c6941744c693475494330744c 0tLS4gLS4tLiAtLi4uIC0tL

533475494334674c6930744c5330674c5330744c53344b S4uIC4gLi0tLS0gLS0tLS4K


Las porciones ASCII parecen sospechosamente codificadas en Base64, con sus separaciones entre cadenas por el hexadecimal ‘0a’, por lo que se intenta descifrar de esta manera, y se obtienen cadenas de espacios, puntos y rayas, que al decodificar como Código Morse, entrega el flag, así:


Li0uLiAuLSAgIC0uLS4gLi0uLiAuLSAuLi4tIC4gICAtLi4gLiAgIC4gLi4uIC0gLiAgIC4tLiAu

.-.. .- -.-. .-.. .- ...- . -.. . . ... - . .-. .

LA CLAVE DE ESTE RE


IC0gLS0tICAgLiAuLi4gICAtLS0tLiAuIC4uLi0tIC0uLi4uIC4uLi0tIC4gLS4uIC4uLi4uIC4t

- --- . ... ----. . ...-- -.... ...-- . -.. ..... .-

TO ES 9E363ED5A


IC0tLS0uIC0uLS4gLS0tLS0gLi4tLiAtLi4uIC0uLiAuLi4uLiAtLi4uIC0tLi4uIC0tLS0tIC0u

----. -.-. ----- ..-. -... -.. ..... -... --... ----- -.

9C0FBD5B706


Li4uIC0uLi4gLS4tLiAuIC4uLi4uIC0tLS4uIC4tLS0tIC4gLS4uIC4uLi4uIC0tLS0uIC0tLS0u

... -... -.-. . ..... ---.. .---- . -.. ..... ----. ----.

BCE581ED599


IC4gLi4tLS0gLS0tLS4gLS4tLiAtLi4uIC0tLS4uIC4gLi0tLS0gLS0tLS4K

. ..--- ----. -.-. -... ---.. . .---- ----.

E29CB8E19


Al concatenar todo, se obtiene:

LA CLAVE DE ESTE RETO ES 9E363ED5A9C0FBD5B706BCE581ED599E29CB8E19


Y la pista dice “minúsculas”, así que el flag es: 9e363ed5a9c0fbd5b706bce581ed599e29cb8e19




LEVEL 3:

Se bajó el archivo ‘level3’, y se identificó con el comando ‘file’ de Linux que era un archivo comprimido con GZIP:


root@lnhg-lab-1:~# file level3

level3: gzip compressed data, from Unix, last modified: Fri Dec 3 13:45:20 2010

Al descomprimirlo, se obtenía otro archivo, que ‘file’identificó así:

root@lnhg-lab-1:~# file level3

level3: x86 boot sector, mkdosfs boot message display, code offset 0x3c, OEM-ID " mkdosfs", sectors/cluster 4, root entries 512, sectors 34126 (volumes <=32 MB) , Media descriptor 0xf8, sectors/FAT 34, heads 255, serial number 0x9c38eeec, label: " ", FAT (16 bit)

Esto nos indica que el archivo es una imagen hecha con mkdosfs, y se procedió a montarla en Linux con el comando “mount –o loop ./level3 ./level3_mount. Esta imagen contenía:


root@lnhg-lab-1:~/level3_mount# ls -la

total 408

drwxr-xr-x 4 root root 16384 2010-12-05 11:07 .

drwx------ 44 root root 4096 2010-12-05 13:10 ..

-rwxr-xr-x 1 root root 741 2010-12-03 13:41 camiloPub.pem

-rwxr-xr-x 1 root root 47 2010-12-03 13:41 ejemplocifra.txt

drwxr-xr-x 2 root root 2048 2010-12-03 13:41 images

drwxr-xr-x 5 root root 2048 2010-12-03 13:42 john-1.7.6

-rwxr-xr-x 1 root root 306 2010-12-05 11:05 level3.sh

-rwxr-xr-x 1 root root 305 2010-12-03 13:41 level3.sh.old

-rwxr-xr-x 1 root root 57456 2010-12-03 13:41 logo-tux.jpg

-rwxr-xr-x 1 root root 102400 2010-12-03 13:44 part.dd

-rwxr-xr-x 1 root root 222742 2010-12-03 13:43 words-english


Pero al mirar más a fondo la imagen antes de montarla, se identificó un set de archivos PAR2, borrados (.level.sh*), que al recuperarlos permitían la corrección de un archivo … Ese archivo (mismo nombre) es el level3.sh que estaba dentro de la imagen y que se ve en el listado anterior.


El archivo level3.sh al ejecutarse antes de la corrección, generaba un archivo de texto (temporal) y le sacaba el hash SHA1. Al corregir el archivo (cambiaba un carácter solamente), el SHA1 generado es diferente (y es el flag):


root@lnhg-lab-1:~/level3d# md5sum ./level3.sh.old

541a3505f20e50da7eae2bbd0bd2482a ./level3.sh.old


root@lnhg-lab-1:~/level3d# md5sum ./level3.sh

20716a30376cfae2ce919b4390854eda ./level3.sh


El flag era “20716a30376cfae2ce919b4390854eda”


LEVEL 4:

Se bajó el archivo ‘level4’, y se identificó con el comando ‘file’ de Linux que era un archivo de captura de tráfico PCAP:


root@lnhg-lab-1:~# file level4

level4: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)

Al abrirlo, se identificó un tráfico de VoIP (sólo SIP) con varios paquetes de autenticación (REGISTER SUBSCRIBE INVITE), donde hay responses en MD5.


Se cargó el archivo de captura en Cain, y se crackeó for fuerza bruta, obteniendo el password:

sipbar

La pista decía “Resuma el punto clave de esta conversación”, y debía ser interretada como “vuelve a sumar la clave de la conversación”, así que se realizó el hash de SHA1 de esa clave, y se obtuvo el flag, que es:

602e878a5bbd4494e3f83cdaac3f2efcbcff2eda


LEVEL 5:

El aplicativo Web al recibir un usuario y password, lo verificaba, pero si se colocaban más parámetros, después de un espacio o comilla sencilla, se recibían datos del aplicativo.Inicialmente se colocó una ‘d, y se recibía un número decimal, con otros caracteres se recibían números hexadecimales … con ‘s entregaba strings, por lo que se le pidió que entregara varios strings con ‘s’s’s’s’s’s’s’s’s’s’s’s’s (El request completo fue: http://74.207.237.145/cgi-bin/index.perl?username=a&password=s%27s%27s%27s%27s%27s%27s%27s%27s%27s%27s%27s%27s)

Y allí se pueden observar el login (littlemidget) y el password (4dIcT04lD0L0r), que al ser ingresados en los campos respectivos entregaban el flag:


Páginas vistas en total

Con la tecnología de Blogger.

Entradas populares

Seguidores