WriteUp Guessit wgsbd2

Criptografía. Métodos de sustitución

En critptografía se conoce como cifrado por sustitución el método que cifran el mensaje sustituyendo unos caracteres por otros siguiendo un sistema "regular". El método más sencillo es el conocido como cifrado de César que consiste en sustituir cada letra del abcedario desplazandonos tres posiciones adelante en la secuencia del alfabeto.

Es decir:

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

^ ^ ^ A B C D E F G H I J K L M N O P Q R S T U V W

| | |

| | |

X Y Z

Con un alfabeto de 26 letras puede definirse con aritmética modular como E(x) = x+3 mod 26, donde x es la posicion numérica de la letra en el abecedario (A=1... Z=26).

En la pasada Campus Party de Valencia de 2011, se nos presentó un "challenge" de criptoanálisis.

Empleamos el método análisis de frecuencia donde conociendo las letras que más se repiten de un idioma, con un poco de intuición y perseverancia, se puede llegar a conseguir el texto en claro.

El texto a descifrar era el siguiente:

Af.p Oáxaer o. j.n.xpó na .byp.ia e. lp.mcro Xcyájrpao 2010 .b .n .k.byr cby.p"g. an 'g. O.jgpcyf Xf E.uagny .oyaxa brmcbaer .b na jay.irpía e. -M.hrp xnri e. o.igpceae cburpmáycja- hgbyr jrb -Gb cburpmáycjr .b .n Naer E.n Man- f Tpclyólrncov

Ucbanm.by. ¡¡ d.mro iabaer !!w e.ojrbrj.mro nro lrpj.byah.o e. kryro l.pr .oyamro o.igpro 'g. na kryajcób da y.bcer 'g. o.p mgf mgf p.ñcea f 'g.w agb'g. og.b. a yólcjrw nro yp.o xnrio ucbancoyao (f xaoyaby.o mao 'g. br nn.iaprb a na ucban) dab d.jdr mépcyro mao 'g. ogucjc.by.o jrmr lapa iabap jrb hgoycjca .n lp.mcrv

Bro da d.jdr mgjdíocma cngocób iabap .oy. lp.mcrw lpcm.pr lrp'g. nn.iap a na ucban oglrb. 'g. kroryprow nro 'g. bro n.écow daxéco y.bcer .n e.yann. e. cbk.pycp kg.oypr yc.mlr .b kryapbro nr 'g. cmlncja gb p.jrbrjcmc.byr a bg.oypa dgmcne. naxrp (IPAJCAO !!!)w f o.igber lrp'g. gb hgpaer mgnycecojclncbap da hg;iaer jrmr kancror bg.oypr ypaxahrv

Ipajcao a yrero nro 'g. dajéco e. OxE nr 'g. .ow ipajcao a yc 'g. y. yrmao na mrn.oyca e. n..pbrow -P.ygcy.apbro-w p.jrm.beapbrow 'g. a k.j.o alrpyao e.haber gb jrm.byapcrw 'g. jgaber jrcbjcecmro .b aniúb ocycr y. yrmao na mrn.oyca .b oangeap f jrm.byap aniúb lroy vvv IPAJCAO !

Ipajcao a yrea na i.by. alrpyó og oaxcegpía .bkcáberbro jrbypcxgjcrb.o 'g. ec.prb (mgjdr) mao kanrp a .oy. xnriv

Ipajcao a na i.by. 'g. bro jrbj.ecó lapy. e. og kancror yc.mlr f o. e.hó .byp.kcoyap lrp broryprov

Ipajcao a yrero nro jrmlañ.pro 'g. yamxcéb .ojpcxío xnrio e. nro 'g. alp.be.mro eía a eíav

F lrp oglg.oyrw ipajcao a Xcyajrpaovjrm lrp o.igcp añr a añrw lp.mcaber na naxrp e. na jrmgbceae xnri dcolabav

Lrp únycmrw 'g.p.mro e.jcpy. anirS

Ogx. .n krngm.b e. ygo anyakrj.o f lgnoa lnafv Jrb japcñr e. lapy. e.n .'gclr e. OxE lapa yc S

Para ello utilizamos una modificación de un script escrito por xgusix.

En un primer momento intentamos el reto con el inglés, ya que todos los tokens que se habían conseguido hasta ese momento eran frases inglesas escritas en h4x0r. Para ello nos centramos en las palabras de tres letras que más se repetían, éstas aparentemente eran: "'g." y "nro". Siendo palabras aisladas que tanto se repiten en inglés una debería ser "and" y la otra "the". Pero tras la sustitución de estas, se podía ver que algunas palabras dejaban de tener sentido, es decir tanto sustituyendo "'g." por "the" como por "and" algunas palabras descifradas dejaban de tener sentido. Aun así, estuvimos dándole con el inglés durante un tiempo porque en la criptografía clásica, una práctica habitual era meter ruido en el mensaje para despistar a los criptoanalistas.

Entonces fue cuando xgusix (yo xD) se fijo que en la primera linea del mensaje estaba escrito lo siguiente: ".b .n". Tras darle vueltas a qué podía ser en inglés, todo le sonó raro (at an?), así que decidimos tirar por el español, ya que problamente correspondiera a "en el" tirando desde ahí se saco el siguiente texto claro:

AYER SABADO SE CELEBRÓ LA ENTREGA DE PREMIOS BITÁCORAS 2010 EN EL EVENTO INTERQUE AL QUE SECURITY BY DEFAULT ESTARA NOMINADO EN LA CATEGORÍA DE -MEJOR BLOG DE SEGURIDAD INFORMÁTICA- JUNTO CON -UN INFORMÁTICO EN EL LADO DEL MAL- Y KRIPTÓPOLIS.

FINALMENTE ¡¡ HEMOS GANADO !!, DESCONOCEMOS LOS PORCENTAJES DE VOTOS PERO ESTAMOS SEGUROS QUE LA VOTACIÓN HA TENIDO QUE SER MUY MUY REÑIDA Y QUE, AUNQUE SUENE A TÍPICO, LOS TRES BLOGS FINALISTAS (Y RESTANTES MAS QUE NO LLEGARON A LA FINAL) HAN HECHO MERITOS MAS QUE SUFICIENTES COMO PARA GANAR CON JUSTICIA EL PREMIO.

NOS HA HECHO MUCHÍSIMA ILUSION GANAR ESTE PREMIO, PRIMERO PORQUE LLEGAR A LA FINAL SUPONE QUE VOSOTROS, LOS QUE NOS LEEIS, HABEIS TENIDO EL DETALLE DE INVERTIR VUESTRO TIEMPO EN VOTARNOS LO QUE IMPLICA UN RECONOCIMIENTO A NUESTRA HUMILDE LABOR (GRACIAS !!!), Y SEGUNDO PORQUE UN JURADO MULTIDISCIPLINAR HA JUZGADO COMO VALIOSO NUESTRO TRABAJO.

GRACIAS A TODOS LOS QUE HACEIS DE SBD LO QUE ES, GRACIAS A TI QUE TE TOMAS LA MOLESTIA DE LEERNOS, -RETUITEARNOS-, RECOMENDARNOS, QUE A VECES APORTAS DEJANDO UN COMENTARIO, QUE CUANDO COINCIDIMOS EN ALGUN SITIO TE TOMAS LA MOLESTIA EN SALUDAR Y COMENTAR ALGUN POST ... GRACIAS !

GRACIAS A TODA LA GENTE APORTO SU SARIDURI­A ENVIANDONOS CONTRIBUCIONES QUE DIERON (MUCHO) MAS VALOR A ESTE BLOG.

GRACIAS A LA GENTE QUE NOS CONCEDIO PARTE DE SU VALIOSO TIEMPO Y SE DEJO ENTREVISTAR POR NOSOTROS.

GRACIAS A TODOS LOS COMPAÑEROS QUE TAMBIEN ESCRIBE­N BLOGS DE LOS QUE APRENDEMOS DIA A DI­A.

Y POR SUPUESTO, GRACIAS A BITACORAS.COM POR SEGUIR AÑO A AÑO, PREMIANDO LA LABOR DE LA COMUNIDAD BLOG HISPANA.

POR ULTIMO, QUEREMOS DECIRTE ALGO:

SUBE EL VOLUMEN DE TUS ALTAVOCES Y PULSA PLAY. CON CARIÑO DE PARTE DEL EQUIPO DE SBD PARA TI:

Descifrando el texto y metiéndolo en google nos llevaba a esta página:

http://www.securitybydefault.com/2010/10/premios-bitacoras-2010-gracias.html

En la página estaba el texto detras de este un video y por último la frase "Sois los mejores, el premio es vuestro", que tenía una pinta de token que no podía con ella... Esto lo conseguimos a medio día del segundo día del war game.

Durante el resto de días probamos todo lo que se podía probar, "Sois los mejores, el premio es vuestro", cifrándolo con las correspondencias que sacamos, título de post, título cifrado, url, la cifrada no porque no estaban todos los caracteres...

Teclado Dvorak, clave del challenge

El penúltimo día por la noche decidimos que debía existir una regla que permitiese al participante lograr la traducción completa y obtener los caracteres que faltaban y que no se pudieron sacar por analisis del texto ya que no aparecían en el. En nuestro caso, la z, la w, y signos de puntuación. Finalmente y Googleando en búsqueda de métodos de sustitución nos percatamos del teclado "Dvorak". En realidad no es un cifrado, sino una configuración del teclado alternativa al conocido "qwerty". Esta secuencia dio nombre al teclado que desarrolló y patentó Christopher Sholes en 1868 y que vendió a la Remington, una de las primeras marcas de máquinas de escribir, que lo adoptó en sus modelos.

En 1936, August Dvorak presentó un teclado simplificado que permitía escribir, según él, con más rapidez y comodidad. El teclado Dvorak colocaba las letras más utilizadas en la fila central, y las menos en la inferior.

Una vez identificamos que el texto se habia cifrado escribiendo en dvorak consultamos una tabla de equivalencias aqui:

http://dvorak.mwbrooks.com/pimlott.html

Y, cifrando la url con el código dvorak conseguimos el token del reto.

dyylSzz,,,vo.jgpcyfxfe.uagnyvjrmz2010z10zlp.mcro[xcyajrpao[2010[ipajcaovdymn

P.D: Adjuntamos un pequeño .py del que nos ayudamos para traducir, aunque si lo quereis mas sencillo usad este traductor online:

http://wbic16.xedoloh.com/dvorak.html

dvorak.py

Writeup sdb wargame keyconsole

Keyconsole era un reto de reversing (al menos yo lo enfoqué así) muy sencillito, de hecho era el primero de todo el panel de retos (si empezamos arriba a la izquierda claro).

Al acceder al reto encontrabamos un enlace a un binario llamado tmp_key que descargabamos y al ejecutar obteníamos unos mensajes de "comprobando el environment" y de que nuestro software no es original así que nos quedamos sin token :).






Visto lo visto empezamos el reversing, en mi caso utilizo gdb. Lo arrancamos con el binario y desamblamos main (por probar a lo loco si se escribió en C).

DISCLAIMER!: Yo soy un newbie en esto del reversing y del hacking en general, yo hago lo que buenamente puedo y me manejo con las herramientas como buenamente puedo, si crees que hubiera sido mejor tirar primero por otro camino, muy probablemente tengas razón, por ejemplo creo que en general es mejor antes de ponerse con el gdb, pasarle un strings al binario y ver si algo por dentro nos llama la atención... esto es algo que he aprendido a posteriori y que a partir de ahora sí haré :), pero aquí pongo un poco el proceso que seguí, que como ya comento no es el más profesional.

Lo que vemos en el desamble de main es lo siguiente:

Una costumbre que tengo yo cuando me pongo a estas cosas es fijarme en las funciones que se llaman (calls) para saber más o menos qué es lo que quiere hacer la función, los he marcado en rojo.

También me fijo en aquellas direcciones que puedan ser ristras de caracteres en memoria. Las identifico buscando los parámetros a las funciones llamadas que deban tener ristras (como a los fopen, cuyo primer parámetro es el path al fichero a abrir) y buscando instrucciones movl que pongan en el registro destino un número que tenga pinta de estar haciendo referencia a la zona de datos, los he marcado en verde.


Finalmente profundizo un poco más en cómo hace lo que quiera que haga el programa en base a mirar los saltos y ver hacia dónde llevan, marcados en azul.


Vemos que hay 3 funciones más definidas en el binario (o sea, creadas por el programador):

• get_random_number_by_sony()
• check_env()
• array()

Antes de ponerme a mirar por dentro cada una de esas funciones le sigo un poco la pista al programa y busco ristras en memoria con las direcciones antes apuntadas:

En rojo tenemos la string que en principio parece que querríamos que nos apareciera. Si le seguimos la pista hacia atrás vemos lo siguiente:

Para entender bien esta imagen hay que seguirla hacia atrás. Vemos que la string interesante la imprime el printf() señalado porque como primer parámetro (%esp) tiene lo que hay contenido en eax, que a su vez viene del movl anterior el cual pone la dirección de nuestra cadena en el registro, a esta instrucción se llega desde el salto jne de main+254, dicho salto se realiza si el valor de lo contenido en 0x6c(%esp) (una variable local de main) es distinto de 1, que a su vez es lo que contenía el registro eax después de la llamada a check_env(). En definitiva algo como:

if (check_env() != 1) {
    printf("[-]System compatible:\n     ");
    array(0x6c(%esp));
}
else {
    ...
}

Pues que bien, ahora se me ocurren dos cosas, ir a la función array() e intentar sacarle lo que nos va a devolver, o ir a check_env para comprobar que es lo que hace y como logramos que no devuelva un 1. Yo he optado por la segunda opción. Desamblamos check_env():

Empezando por el final vemos la instrucción que NO queremos que se ejecute, la que pone un 1 en el registro eax y termina. Siguiendo la pista hacia atrás vemos que queremos que el salto anterior se tome (jne). Para quién no sea un ninja de ensamblador de x86 (como yo, que no lo soy y me pegue aquí un tiempo) la combinación de "test eax, eax" con el jne puede ser algo confusa. Test realiza un AND entre los dos registros, cuando ésto se realiza sobre un mismo registro viene a significar más o menos "es este registro 0?". Los saltos comprueban su condición en base al registro de flags, en el caso del jne se comprobará el zf (zero flag) que estará activo si el test devolvió 0, es decir si eax era 0. En román paladino ese grupo de instrucciones significan:

if (fopen("fichero interesante", "algun modo de apertura"))
    return 1;
else
    return 0;

Así que lo que queremos hacer es que ese "fichero interesante exista". ¿El nombre? Pues siguiéndole la pista hacia atrás vemos que es el primer parámetro para fopen() (%esp), que viene de eax, que a su vez viene de "lea -0x3a(%ebp)". Eso es la dirección de memoria de una variable local, el nombre del fichero que necesitamos que exista para que check_env() devuelva distinto de 1 se construye en tiempo de ejecución. Llegados a este punto podemos ejecutar hasta el fopen(), ver el nombre del fichero necesario, crearlo y luego seguir ejecutando el programa... y no necesitaríamos ponernos a comprender todo lo anterior, srand(), rand(), etc...

Bueno, pues ya sabemos que fichero debe existir... >$ touch /tmp/0_privatekey_2 y continuamos.

Y ya tenemos el token.

PHT en el wargame

Bueno, no esta bien que lo digamos nosotros... pero si no lo decimos nosotros quién lo va a decir?!

PHT SEXTOS EN EL WARGAME DE SBD!!!

Felicidades a todos, tanto a los ganadores como al resto de participantes. Esperamos que hayan pasado TAN BUEN RATO como pasamos nosotros. A los que no hayan participado nunca en un wargame... sin pensárselo y de cabeza.

Breve historia del PHT

Bueno, me gustaría dedicar la primera entrada del blog un poco a presentarnos.

Somos el PHT (Piruletous Hacking Team) un grupo de, por ahora, 4 personas que nos conocimos en el máster de seguridad de la UEM. Los 4 compartimos (al menos) una misma afición, la seguridad de la información y las comunicaciones y en general comprender cómo funcionan los sistemas computacionales.

No somos grandes expertos en seguridad pero tenemos al menos una característica necesaria para este mundillo, una sed insaciable de curiosidad :).

¿Por qué se formó el PHT? Pues la respuesta es bien sencilla, nos enteramos del wargame que iba a organizar Security by Default para la Campus Party de 2011, y decidimos que era un buen momento para comenzar. Ninguno había participado antes en un wargame (todo lo más hecho algunas pruebas de otros wargame outline) y así comenzó todo.