Hackit! 2007: Nivel 9, espiando conversaciones VoIP

Posted on May 6th, 2008 in HackIt, Seguridad by admin (330 lecturas)

Lo primero que vemos al entrar en el nivel 9 es la posibilidad de descargarnos un fichero .zip que incluye un único fichero tampering.cap . El propio Linux nos indica de qué se trata:

sh-3.2$ file tampering.pcap
tampering.pcap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)

Una captura de tráfico hecha con tcpdump. Vamos a darle un poco de trabajo a Wireshark (ex-Ethereal), mediante el comando

$ wireshark tampering.cap

Vemos en la columna Protocol que aparte de ARP, aparece el acrónimo SIP (Session Initiation Protocol), o sea, “protocolo de iniciación, modificación y finalización de sesiones interactivas de usuario donde intervienen elementos multimedia como el video, voz…” (Wikipedia dixit) ¿Han capturado tramas de voz? Menos mal que me he traído los auriculares :-) También veo tramas RTP (Real-time Transport Protocol, que define un formato para el transporte de audio y video sobre Internet)… veamos qué tenemos en Wireshark al respecto…

Varias opciones del menú se relacionan con SIP, RTP y llamadas de voz. Por medio de la vieja táctica de “prueba y error” ;-) llegamos a la opción “VoIP Calls”. Nos sale esta pantalla:

Pulsamos en Player y obtenemos:

Esto parece una matrioska :-) Veamos… si pulsamos en “Decode”.

Esto tiene muy buena pinta. Pónte los cascos, pulsa “Play” y escucha la conversación… mañana seguiremos con la resolución del misterio (inténtalo por tu cuenta, ¡hombre!)

HackIt! Nivel 8: reverse engineering en Windows (solución)

Posted on April 10th, 2008 in HackIt, Seguridad by admin (355 lecturas)

Si hacemos lo que vimos en el post anterior, veremos la siguiente cadena: “Compressed by Petite (c)1999 Ian Luck”

Así que ahora que sabemos el compresor usado en el .exe, habrá que descomprimirlo. La primera pega, sacada del readme de Petite: “No existe un descompresor de Petite.” Genial… vamos a preguntar al sabio a ver si opina lo contrario. Entre los resultados, uno curioso: “r!sc’s Petite enlarger” (alargador de petite) :-) Tras ejecutar enlarger.exe sobre login.exe vemos que tenemos éxito :-)

Se genera en la misma carpeta de login.exe un nuevo binario descomprimido de nombre un-packed.exe . Ése será el ejecutable que abriremos con OllyDBG, y ahora sí, estaremos en disposición de depurarlo:

Pondremos un punto de ruptura en la dirección 0×0401290 (tocamos la línea y pulsamos F2). Pulsamos el botón Play (Run Program = F9) . En la línea 0×04012D4 vemos que se intenta leer el fichero license.lic (en concreto los campos user y login). Antes de seguir depurando, por tanto, vamos a cumplimentar esos campos (el user lo dejamos tal cual está en el fichero original, “euskal15″, y en el password pondremos “contraseña”, por ejemplo).

Seguimos depurando paso a paso pulsando F7 (ejecutar paso a paso, metiéndose en el código de las funciones - destino de los call - ) ó F8 (ejecutar paso a paso, pero NO meterse en el código de las funciones - no meterse en el destino de los call - ) .

Cuando lleguemos a la instrucción 0×04013AA debemos fijarnos en la zona superior derecha, en el valor de los registros EAX, ECX, etc. Veremos la cadena HACKthis (podemos empezar de cero, probando a poner esa cadena en el password y ejecutar el .exe. Veremos que no es la contraseña que necesitamos) Seguimos ejecutando paso a paso, hasta que al llegar en una de las vueltas a la instrucción 0×04013CD veremos lo siguiente:


“HFODdget” … qué cadena más curiosa, ¿no? ;-) No voy a explicar exactamente qué hace cada región de código ensamblador, eso lo dejo “como ejercicio para el lector” ;-)

Hack It! Nivel 8: reverse engineering en Windows

Posted on April 9th, 2008 in HackIt, Seguridad by admin (281 lecturas)

Descargamos el archivo .zip del nivel 8 y descomprimimos. Veremos dos ficheros : login.exe y login.lic

Ejecutamos login.exe y nos saludará la siguiente ventana:

O sea, “¡No! pero gracias por concursar…”

Empecemos con la artillería: abrimos el ejecutable en OllyDBG, y obtenemos otro mensaje de alerta no muy bonito:

“Entry Point Alert. Module login has entrypoint outside the code (as specified in the PE header). Maybe this file is self-extracting or self-modifying. Please keep it in mind when setting breakpoints!”

Probablemente el .exe esté comprimido. Lo más habitual es con UPX (de hecho este compresor de ejecutables ya ha aparecido en otras pruebas del HackIt! …) Sin embargo, tras probar con UPX veremos que no es el caso. ¿Qué hacer? Lo que deberíamos de haber hecho desde un principio, echarle un vistazo al binario con un editor de textos (como UltraEdit), a ver si vemos algún string interesante.

Y aquí os dejo que penséis un poco cómo seguir ;-)

Hack It! Nivel 7: solución

Posted on April 8th, 2008 in HackIt, Seguridad by admin (245 lecturas)

Como ya comentamos, no tenía demasiado misterio. Descargar la captura de tramas de una conexión wifi con cifrado WEP contenida en el fichero tampered.cap y pasarle un crackeador por ataque de diccionario (en español). El diccionario utilizado es lemario-espanol-2002-10-25 encontrado en http://lemarios.olea.org/

La orden de crackeo también es sencilla:

$ aircrack-ng -w lemario-espanol-2002-10-25.txt tampered.cap

En unos pocos minutos aparecerá la clave para pasar al siguiente nivel: proclive .

El nivel 8 sí que nos costó un poco… tal vez porque había que practicar ingeniería inversa sobre un binario .exe , y estamos un poco oxidados en OllyDBG ;-)

Nivel 7: wireless cracking

Posted on April 1st, 2008 in HackIt, Seguridad by admin (499 lecturas)

El nivel 7 fue el que menos tiempo nos costó resolver :-)  Veníamos preparados..

hackit nivel 7

Unas horas para que lo penséis… (y el password que aparece en pantalla no es el correcto ;-)

HackIt! 2007 : nivel 6: solución

Posted on March 30th, 2008 in Devel, HackIt, Seguridad by admin (245 lecturas)

Reverse Engineering. Cracking. Un poco de conocimientoso sobre ambos temas serán imprescindibles para
pasar este nivel (os he dejado muchos días para que fuerais sacándolo por vuestra cuenta, ¿qué tal os ha ido?) Vamos a por ello. Tras descargarnos el fichero .zip que indica la página, lo descomprimimos e intentamos ejecutar (txipi nos dijo que no había virus ni código maligno en los ejecutables, por eso nos atrevemos a ejecutar un binario a pelo…). La salida es bastante pobre, por decir algo:


sh-3.2$ ./program
sh-3.2$

Así que toca depurar con GDB.


$ gdb ./program
warning: no loadable sections found in added symbol-file /tmp/program
(no debugging symbols found)

Vaya, si no hay tabla de símbolos, la depuración puede ser un infierno. Así que comprobemos primero que el ejecutable
no haya sido comprimido con UPX o similares (UPX es el compresor más conocido de ficheros ELF en Linux):


$ upx -l ./program
Ultimate Packer for eXecutables
Copyright (C) 1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007
UPX 3.00 Markus Oberhumer, Laszlo Molnar & John Reiser Apr 27th 2007
.
File size Ratio Format Name
-------------------- ------ ----------- -----------
532432 -> 52404 9.84% linux/elf386 ./program

¡Tachán! Efectivamente el ejecutable está comprimido con UPX. Descompresión al canto:


$ sh-3.2$ upx -d ./program
Ultimate Packer for eXecutables
Copyright (C) 1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007
UPX 3.00 Markus Oberhumer, Laszlo Molnar & John Reiser Apr 27th 2007
.
File size Ratio Format Name
-------------------- ------ ----------- -----------
532432 <- 52404 9.84% linux/elf386 program
Unpacked 1 file.

Y ahora volvemos a pasarlo por GDB, a ver qué nos dice:


sh-3.2$ gdb ./program
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb)

Mejor :-) Bien, vamos a poner un punto de ruptura en main():


(gdb) break main
Breakpoint 1 at 0x8048455
(gdb)

Ejecutemos hasta el punto de ruptura y pidamos un desensamblado de la zona:

(gdb) run
Starting program: /tmp/program
Breakpoint 1, 0x08048455 in main ()
(gdb) disassemble
Dump of assembler code for function main:
0x08048444 : lea 0×4(%esp),%ecx
0×08048448 : and $0xfffffff0,%esp
0×0804844b : pushl 0xfffffffc(%ecx)
0×0804844e : push %ebp
0×0804844f : mov %esp,%ebp
0×08048451 : push %edi
0×08048452 : push %esi
0×08048453 : push %ebx
0×08048454 : push %ecx
0×08048455 : sub $0×78,%esp
0×08048458 : movl $0×0,0xffffffec(%ebp)
0×0804845f : lea 0xffffffd0(%ebp),%eax
0×08048462 : mov %eax,(%esp)
0×08048465 : call 0×804837c
0×0804846a : movl $0×0,0xffffffe8(%ebp)
0×08048471 : jmp 0×8048477
0×08048473 : addl $0×1,0xffffffe8(%ebp)
0×08048477 : cmpl $0×98967e,0xffffffe8(%ebp)
0×0804847e : jle 0×8048473
0×08048480 : lea 0xffffffc0(%ebp),%eax
0×08048483 : mov %eax,(%esp)
0×08048486 : call 0×804837c

Bien, se ve la zona de paso de variables a la pila (guardar el contexto) y primera llamada call (por el nombre de la función, times, parece que hace algún tipo de comprobación) y en función del resultado, en main+45 saltamos a main+51. Ahí nueva comparación… saltamos (hacia atrás) a main+47. Parece un bucle, ciclando hasta que se cumpla cierta condición. Posteriormente, se hace una nueva llamada a “times”, haciendo alguna nueva comprobación:


0x08048486 : call 0×804837c
0×0804848b : mov 0xffffffc0(%ebp),%edx
0×0804848e : mov 0xffffffd0(%ebp),%eax
0×08048491 : mov %edx,%ecx
0×08048493 : sub %eax,%ecx
0×08048495 : mov %ecx,%eax
0×08048497 : mov %eax,0xffffffe8(%ebp)
0×0804849a : cmpl $0xa,0xffffffe8(%ebp)
0×0804849e : jle 0×8048586
0×080484a4 : movl $0×80c89a8,(%esp)
0×080484ab : call

En main+90 hay alguna condición que tras comprobarla hace que el programa termine (salta a main+322). Vamos a cortocircuitar este último salto . a ver qué pasa ;-) :

(gdb) j *0x080484a4
Continuing at 0x80484a4.
username? jota
error: wrong serial number!
Program exited normally.
(gdb)
Vaya, algo hemos avanzado, porque al menos nos pide username… Pero poniéndole cualquier cosa (jota, p.ej.), vemos que no le gusta.
Mmmmmhhh… volvamos a la carga:


(gdb) run
Starting program: /tmp/program
.
Breakpoint 1, 0x08048455 in main()
(gdb) disassemble
...
0x080484ab : call 0×804835c
0×080484b0 : lea 0xffffffac(%ebp),%eax
0×080484b3 : mov %eax,(%esp)
0×080484b6 : call 0×804833c
0×080484bb : mov $0×303c48b1,%eax
0×080484c0 : sub 0xffffffec(%ebp),%eax
0×080484c3 : mov %eax,0xffffffec(%ebp)
0×080484c6 : addl $0×2faf080,0xffffffec(%ebp)
0×080484cd : cmpl $0×0,0xffffffec(%ebp)
0×080484d1 : jne 0×804857a
0×080484d7 : movb $0×9b,0xffffffe0(%ebp)


Entre el printf (”username”) y el gets (recogida del parámetro por teclado) no hay nada que destacar.
Lo siguiente termina en un jne a main+310. Volvamos a cortocircuitar (no queremos saltar en main+141… queremos ir
a la siguiente instrucción) :

(gdb) j *0x080484d7
Continuing at 0x80484d7.
correct! password = d3nb0r4
Program exited normally.
(gdb)

¡Qué bonito password! :-)

Pwn 2 Own: y el ganador es… ¡Ubuntu!

Posted on March 29th, 2008 in HackIt, Seguridad by admin (1428 lecturas)

charlie_macosx.jpgCanSecWest 2008 es una conferencia sobre seguridad digital en la práctica, celebrada en Canadá, que reúne a los mejores grupos y empresas de seguridad informática del mundo. Entre otros interesantes eventos, el que mayor atención recaba es el concurso Pwn2Own. El objetivo es usar un 0day exploit sobre cualquiera de las 3 máquinas en juego:

  • VAIO VGN-TZ37CN ejecutando Ubuntu 7.10
  • Fujitsu U810 corriendo Vista Ultimate SP1
  • MacBook Air usando OSX 10.5.2

Los sistemas vienen instalados con lo justo: lo que “trae el CD” del sistema, instalación por defecto. Son 3 días en los que los mejores equipos de hackers del mundo (en el buen y mal sentido de la palabra ;-) intentan darle candela a esos sistemas. El que primero consiga leer el contenido de un fichero que la organización indica, gana el concurso. Premios: ¡fama! y el portátil que hayan conseguido hackear. Para el primero además, hay un plus de 10.000 dólares y para el segundo $5.000. ¿No está mal, eh? Eso sí, a cambio de ese dinero, la Zero Day Initiative (patrocinadores del evento) les compra los derechos de los exploits ;-) (avisando al fabricante del bug…)

El primer día sólo permiten ataques de red. Los 3 sistemas resistieron como campeones. El segundo día, para facilitar las cosas, permitieron que los atacantes facilitaran a la organización direcciones web que los organizadores visitarían usando el navegador instalado en el portátil. Aquí es donde cayó el primer sistema: MacOSX, debido a una vulnerabilidad (por ahora mantenida bajo secreto por la organización) en el navegador Safari. $10.000 y un precioso Mac Air para Charlie Miller de Independent Security Evaluators (foto de la izquierda). El segundo día no cayó ningún otro sistema. El tercer día quedaban sólo por tanto, Ubuntu Linux y Windows Vista. Los organizadores procedieron a facilitar un poco el concurso, instalando aplicaciones “populares” en ambos sistemas. Una de esas aplicaciones fue el plugin de Flash. Y ahí es donde Shane Macaulay de Security Objectives, junto a sus compañeros Alexander Sotirov y Derek Callaway, se llevaron el Fujitsu y 5.000 petrodólares.

team_vista.jpg

HackIt! 2007 : nivel 5: solución

Posted on March 18th, 2008 in HackIt, Seguridad by admin (333 lecturas)

Bien, vamos a explicarlo para que parezca fácil y trivial. Sólo cuando te das cuenta de que equipos como SexyPandas que se clasificó para la Defcon del año 2007 en las Vegas estuvo atascado aquí es cuando empiezas a pensar que tal vez, no sea una prueba tan trivial… tal vez…

El alfabeto latino, cuando Roma conquistó Grecia en el primer siglo antes de Cristo, incluyó las letras Y y Z, quedando así (he dicho que lo iba a hacer fácil… la dichosa letra K, según la Wikipedia, también estaba en ese alfabeto, sin embargo, en la prueba HackIt! hay que quitarla para que el ejercicio cuadre…) :

A B C D E F G H I L M N O P Q R S T V X Y Z

Asignemos a cada letra del criptograma una letra de dicho alfabeto:

XXII VII XX XVI VI XIV XVI II XIII XXI XVI VIII XI XX VIII XI VI VII X IX VI XX II XIV XV    =
22 7 20 16 6 14 16 2 13 21 16 8 11 20 8 11 6 7 10 9 6 20 2 14 15    =
Z G X R F P R B O Y R H M X H M F G L I F X B P

Bien, en cifrado César puro, cada letra del mensaje en claro se sustituye por la letra que aparezca 3 posiciones más adelante en el alfabeto, por lo que para descifrar, habría que seguir el proceso inverso. Sin embargo, en esta prueba el cifrado se aplicó sustituyendo cada letra por la que estuviera 3 posiciones _más atrás_, por lo que para descifrar, hay que sustituir cada letra del criptograma por la que esté 3 posiciones más adelante. ¿Mareado? Hagamos esto último (la sustitución, no el mareo) :

C L A V I S V E R B U M P A M P I L O N I A E S T (”La palabra clave es pampilonia”).

Y pasamos así al nivel 6, que empieza con el saludo “Sapientia melior auro” («La sabiduría es mejor que el oro» es el lema de la Universidad de Deusto, fundada en 1886 por la Compañía de Jesús. En Deusto trabaja como profesor Pablo Garaizar, txipi, organizador de la prueba del HackIt!)

HackIt! : Nivel 5 : cifrado simétrico

Posted on March 7th, 2008 in HackIt, Seguridad by admin (337 lecturas)

El enunciado del nivel 5 parece que nos aporta bastantes pistas:

“Hablando de secretos, hace un tiempo descubrí un criptograma de la Roma clásica y
me pareció bastante indicado para proteger el siguiente nivel…

XXII VII XX XVI VI XIV XVI II XIII XXI XVI VIII XI XX VIII XI VI VII X IX VI XX II XIV XV "

“Criptograma de la Roma clásica”… en aquella época no se había descubierto aún ninguna técnica de criptografía asimétrica, por lo que el autor debe de haber usado un algoritmo de cifrado simétrico. De hecho, uno de los algoritmos de cifrado simétrico más viejos que se conocen (si no el más popular, uno de los que integran el ranking de los 10 más conocidos) lleva el nombre de un líder militar político de la etapa final de la República de Roma… Con estas pistas, este nivel no parece complicado, pero… muchos grupos del HackIt! tardamos más en resolver ésta prueba que todas las que van de la 6 a la 11 juntas. Desde las perspectiva que da el tiempo transcurrido, pudo ser debido a que la frase original en claro no está en castellano, y algunos grupos la tomamos (¡una vez descifrada!) como ruido, ¡pasamos por alto la solución y seguimos intentando descifrar!. Os dejo el fin de semana para tratar de solucionar esta prueba, tomároslo con calma…

HackIt! 2007 : nivel 4: solución

Posted on March 5th, 2008 in HackIt, Seguridad by admin (349 lecturas)

Vamos allá: estábamos trabajando en el nivel 4 del concurso . Sabemos que hay un formulario integrado en un componente Flash (swf). Nuestra suposición: el código que valida al usuario está en el propio swf (no se hacen llamadas a otro servidor), por tanto, aplicaremos ingeniería inversa sobre el binario .swf, descifraremos el algoritmo usado y pasaremos al siguiente nivel. Facil, ¿no? Pues no… ahora veremos por qué.

Si trabajamos en Windows, podemos encontrar varios descompiladores de ficheros Flash swf. Si trabajamos en Linux, sólo he encontrado uno, Flare 0.6, que al usarlo, dejaba como resultado código ininteligible. Al parecer el .swf del nivel 4 tiene alguna protección que hace que la ingeniería inversa no sea trivial.

Buscando en el sabio, encontramos que Sothink SWF Decompiler es una de las herramientas de ingeniería inversa sobre Flash que más se usan. Lo instalamos en Windows y … ¡ah! no, mejor lo instalamos en Linux. ¿Cómo? con WINE, y no, WINE no es un emulador.

Una vez instalado, veremos que al lanzar Sothink SWF nos sale una alerta indicando que falta el componente flash.ocx. Buscando en el sabio encontramos que es necesario instalar el FlashPlayer para Windows (otra vez desde WINE).

activex.png

Ya tenemos todas las herramientas instaladas. Abrimos el fichero login.swf. Y aquí nos damos cuenta de que el código ActionScript  descompilado también deja mucho que desear. ¿Se acabó? No, nos queda una última bala, Sothink permite exportar todos los recursos que hayan podido descompilarse a partir del .swf . Lo hacemos.

exportar.png

La versión de evaluación de Sothink nos avisa: ojo, esta versión sólo exporta los dos primeros frames. Esperemos tener suerte ;-)

warning_swf.png

Le indicamos a Sothink que deje en /tmp/login/ los resultados de la descompilación (parcial). Veremos que hay bastantes directorios. Ahora toca pensar… a ser posible con un poco de café al lado ;-) . Resumiendo la mini-reunión que tuvimos el día de la competición: ¿qué palabra podríamos buscar en todo lo exportado que tenga que ver con el procedimiento de validación del user y password? Lo primero que se nos viene a la cabeza: “pass” o bien “user” . Vamos a probar suerte…

$ cd /tmp/login
$ grep -irn user *
Coincidencia en el fichero binario Frame/frame1.swf

Vamos a ver qué hemos pescado. Filtremos las cadenas “legibles”, busquemos user y pidamos un contexto de +-5 líneas:


$ cd Frame
$ strings frame1.swf | grep -C5 user
E/d@
EnterButton
Button
C~D^F
./level5-bUrm4nfl4x.html
username
password
UserName
Password
Button
KJ

¿La suerte también cuenta? ;-)

Next Page »