miércoles, 16 de abril de 2014

Apostando por la seguridad



La anécdota

Hace unos meses me puse en contacto con mi ISP para comentarles un pequeño fallo en su infraestructura que me afectaba personalmente, nada, poca cosa, sólo permitía que cualquier persona desde el exterior pudiera acceder remotamente a mi router a pesar de estar el acceso deshabilitado.

El problema con estas cosas es: cuando entiendes el fallo y ves hasta dónde llega el problema, ¿cómo lo comunicas?¿con quién te pones en contacto? no existe una cultura ni un mecanismo aquí que permita llegado este caso hacer lo que se llama un "responsible disclosure" (término muy de moda esta semana por otros motivos que volveré a tocar más adelante), es decir una forma de poder avisar del fallo sin causar un perjuicio a la gente involucrada, algo que realmente no suele interesar, al menos a mi.

Así que empecé el calvario de la comunicación por la vía menos recomendada: el teléfono.

Por algún motivo pensé que las empresas en general tendrían alguna opción en los infinitos números de opciones de sus centralitas que fuera "quiero hablar con vosotros, y no, no es para compraros ni para venderos nada", pero obviamente estaba equivocado y acabé en algún nivel de soporte técnico en donde la chica de helpdesk y yo hablábamos un idioma similar.

Y esta es la anécdota que quería encontrar, cuando le conté el problemón que me afectaba a mi y a otras 30mil personas aproximadamente (gracias Shodan!) la chica de soporte me dijo algo así como:

- Pues no es un problema tan grande, porque nuestros clientes tienen IP dinámica, por lo que si alguien quiere controlar tu router cuando vaya a hacerlo seguramente tu ya tendrás una IP nueva y se esté conectando a otro sitio.


Bienvenidos a la seguridad probabilística


Desde entonces acuñé un nuevo término que utilizo con colegas de profesión, la seguridad de casualidad o seguridad probabilística, que viene a ser cuando tu seguridad se basa en la esperanza de que cuando un posible atacante vaya a realizar un ataque sobre tus sistemas suceda algún hecho inesperado que con más o menos probabilidad frustre el intento del atacante, dejándolo en la estacada. 

Es un concepto genial, me gusta.

Y con esto llegamos a lo que de verdad quería contar en el post, que en realidad es sobre Heartbleed. Si si, el fallo ese del corazón sangrando del que se lleva hablando toda la semana, pero he hecho una maniobra de distracción para parecer más novedoso y que así la gente no me vote cansino, bueno, y porque es mi blog, que carai, y me gusta contar estas cosas así.




A estas alturas no voy a explicar lo que es Heartbleed, hay explicaciones estupendas que se pueden consultar, y yo no voy a hacer que entiendas el bug mejor que la tira de XKCD

Tampoco voy a entrar en el mundo de las conspiranoias de que si salió el mismo día del fin de soporte a Windows XP y hay un ex-empleado de Microsoft detrás del sitio web del disclosure, que por cierto no ha sido demasiado responsable.

El tema que quiero tratar es: ¿cuáles han sido las consecuencias de verdad de este bug?

Pues básicamente han sido las siguientes: 

  • Un número indeterminado de sitios web, algunos de ellos con un gran número de usuarios, han dejado ver datos importantes sobre sus clientes. 
  • Como consecuencia de esto, un número indeterminado de credenciales han sido filtradas 
  • Las claves privadas de un número indeterminado de servidores seguros pueden haber sido filtradas (la prueba realizada por cloudflare esta semana, demuestra que esto ha podido ser así en muy poco tiempo)
  • Como consecuencia de esto, las capturas de tráfico de estos sitios seguros, presentes y pasadas, han dejado de ser seguras y se han podido descifrar completamente
  • En el caso de los sitios que no han revocado y renovado el certificado (muchísimos aún a día de hoy), con su certificado robado puede haber gente haciendo el MitM perfecto, es decir, interceptando comunicaciones supuestamente seguras.
  • Existen otras aplicaciones (aún no se sabe cuáles exactamente) y clientes (más de lo mismo) que también están afectadas, con consecuencias impredecibles aunque normalmente algo menos graves.

Y básicamente "sólo" es eso.

¿Por qué hay tantas cosas en el aire? pues porque básicamente no se sabe nada con seguridad, porque aunque existen pruebas que aplicándolas sobre logs de IDS recogidos con anterioridad pueden detectar el fallo, aunque con algún falso positivo, lo que no se va a poder recuperar son los datos que el servidor le envió a los atacantes.

Los datos del número de servidores, que han sido objeto de polémica estos días, también son totalmente estimados, sea cual sea el método que se use para recabar la información.

Unos han usado netcraft, otros zmap, shodan, o una combinación de todo eso, pero los datos siguen siendo estimaciones basadas en los banners que usan los servidores, sin tener en cuenta que el banner puede mentir, o puede haber un proxy en medio que se ocupe de la negociación SSL (es decir, es perfectamente posible que un sitio web alojado en un IIS se vea afectado por usa nginx como proxy inverso), ni han tenido en cuenta el resto de software y appliances que usan la librería.

Pero mi reflexión va un poco más allá, porque realmente los temas de números no me importan demasiado

Voy a hacer una suposición, supongamos que solo tres servidores han sido afectados (que lo han sido): google, facebook y yahoo.

Supongamos también que el bug solo se ha podido usar unas horas (yo lo he podido usar más de un día antes de ver sitios enormes parcheados, pero bueno, supongamos), vamos a poner que se ha podido usar 8 horas, y que solo un grupo reducido de personas ha tenido acceso a el, que tampoco ha sido el caso.

Alguien me podría decir suponiendo todo eso, ¿cual es la probabilidad de que mis usuarios en esos tres servicios hayan sido afectados? ¿el certificado SSL ha sido comprometido? durante ese tiempo ¿he podido ser víctima de un MiTM con ese certificado robado?, si alguien tenía una captura de mi tráfico cifrado ¿ha podido descifrarlo con ese certificado robado?

¿Importa esta probabilidad?

En INTECO hoy, por ejemplo, nos invitan a reflexionar sobre la severidad del bug, con cosas como esta:


A partir del revuelo generado, la preocupación del usuario por el alcance de la vulnerabilidad y cómo podría afectar a su privacidad el riesgo de alguien haya podido capturar sus contraseñas en alguno de los sitios web afectados también requiere cierta reflexión.
Para ello, un aspecto importante a tener en cuenta sobre el grado de exposición de las contraseñas es la ventana temporal del fallo. Es decir (dejando al margen agencias de inteligencia con supuesta información privilegiada o similar), las contraseñas sólo han estado expuestas a posibles ciberdelicuentes desde el 7 de Abril.

Es decir,  supuestamente nadie ha tenido acceso al fallo (o si), y "sólo" han estado expuestas desde el 7 de abril, apenas unas horas (o no, o unos días)

Más, @gallir, el de menéame, subia a portada una noticia con la teoría de la conspiración microsoft y nos dejaba comentarios como este o este diciendo que no era tan automático pillar claves privadas, solo hay que conocer algo sobre gestión de memoria para saber eso
(y yo lo había dicho antes, twitter.com/gallir/statuses/453879009794080769, sin haberlo analizado, pero es conocimiento básico de cómo funciona la gestión de memoria en los sistemas operativos modernos).
Resumen, todo el mundo se apunta rápido al carro de los números y afirmaciones exageradas, pero muy pocos saben el fondo, o se documentan.
Horas después Cloudflare publicaba este reto con una página afectada por heartbleed y horas después dos personas la sacaban, demostrando lo difícil que era
A estas horas ese sitio ya no funciona porque han revocado el certificado del servidor (je je, tiene gracia, y que el certificado sea de COMODO, más)


Así que nada, exactamente no se a que viene esta tendencia de reducirlo todo a números y llamar a la calma-pasividad por la probabilidad supuestamente de que haya pasado algo, pero ¿y si ha pasado?, tampoco entiendo que se hable de "solo X servidores" cuando solo uno de ellos tiene las credenciales de 800 millones de usuarios, solo con que yahoo hubiera sido el único afectado, esto seguiría siendo gravísimo.

Total, que esto debe ser la nueva tendencia, es lo que se llama apostar por la seguridad, es decir, pasen señores y hagan sus apuestas a ver si sus datos están afectados o no en este nuevo bug basándonos en estas nuevas estadísticas que tenemos por aquí fresquitas, bienvenidos a la seguridad probabilística.



lunes, 20 de enero de 2014

Reanimación de datos en memoria para el análisis forense, literal.



La RAM, ¿es volátil?: Si pero.. 

Una de esas máximas que todo usuario un poco avanzado de ordenador da por hecho es que la memoria del ordenador es volátil, esto es, si apago el ordenador todo con lo que estaba trabajando se pierde, y esto es así.. pero no siempre.

Es cierto que por su diseño, los chips de memoria DRAM deben estar siendo constantemente "recargados" con pulsos eléctricos, y si estos pulsos dejan de llegar, el contenido de la memoria se borra, pero esto no es inmediato, sino que pasa después de un tiempo que puede variar entre unos pocos segundos y unos minutos.

En 2008 se publicó un paper de la Universidad de Princeton que habla sobre como recuperar claves de cifrado después de un "cold reboot", es decir, dejar al ordenador sin alimentación y volver a dársela para reiniciarlo. Se puede encontrar el paper aquí

Un ejemplo muy revelador sobre como la información en los módulos de memoria se va deteriorando a medida que pasa el tiempo es el ejemplo de este BMP:

Aquí se muestra una imagen recuperada de la memoria RAM tras 5 segundos, 30, 60 y 5 minutos.

En el resto del estudio se muestran distintas pruebas que, dependiendo de la memoria y otros parámetros arrojan resultados similares.

La conclusión es clara, un reinicio no borra inmediatamente los datos, sino que hay un periodo ventana en el que es posible la extracción de datos de la RAM previos al mismo.

Consecuencias 

En principio este tema técnico no parece de mucha importancia, pero si nos paramos a pensar en las medidas de seguridad física que adoptamos para proteger un dispositivo, la gran mayoría de ellas se basan en :

a) Si un usuario accede al sistema de forma física, el sistema operativo no le dejará realizar operaciones (control de usuarios) y/o se las dejará realizar pero de forma limitada
b) Si existen varios usuarios que comparten un ordenador, un usuario no puede acceder a los datos de otro (protección de memoria)
c) Las herramientas de cifrado pueden proteger de forma adicional los datos de un usuario, por ejemplo BitLocker, Truecrypt, o similares, para que en caso de acceso físico no autorizado, el atacante no pueda acceder a los datos cifrados.

Pues bien, el pequeño detalle de la persistencia de datos en RAM puede hacer que nos replanteemos la veracidad de esas premisas.

Voy a poner un ejemplo para que se entienda a donde quiero llegar.

Un profesor de instituto tiene un ordenador en su mesa, donde guarda los exámenes para los alumnos.
Como es un tipo desconfiado, guarda los exámenes cifrados en una unidad de Truecrypt cifrada con AES128, como contraseña usa una frase 20 caracteres mixtos y cuando se va de clase deja el pc bloqueado o cierra sesión con una contraseña desproporcionadamente compleja, el resto de usuarios del equipo están deshabilitados, el sistema está actualizado, etc.. ¡es un profesor precavido!

De entrada, aunque los alumnos pudieran llevarse el disco a casa, no podrían acceder a los datos que el profesor guarda en el disco, y todo intento de adivinar la contraseña por fuerza bruta fracasaría por cuestiones de tiempo.

Aquí aparece el problema.

Uno de los alumnos se ha leído el paper de Princeton y ha encontrado esta utilidad: msramdmp

En realidad la utilidad no es más que un pequeño kernel, y un sistema que únicamente tiene una utilidad que vuelca el contenido de la RAM en una partición de un disco USB. La utilidad + el kernel tienen un tamaño de apenas unos 5MB, por lo cual, salvando esa zona de memoria y lo que pueda degradarse por el tiempo que tarda en reiniciar el ordenador (ver otra vez el paper, con 1-2 segundos que puede tardar el reinicio, apenas se perderán datos si es que se pierden)

Así que en cuanto el profesor se va de clase el alumno mete el USB en el PC, reinicia, y se puede llevar a casa en su disco una bonita imagen de la RAM que luego puede analizar con calma en casa.

¿Y que puede encontrar ahí?
Pues estas son unas pequeñas pruebas que he hecho con una imagen de RAM obtenida aquí en el lab con un ordenador de pruebas tras un reinicio:

Contraseñas de Truecrypt y otras contraseñas AES, que obviamente, están en memoria cuando se usa rl programa


Búsquedas en google/bing, etc...


Y así, en mis pruebas he recuperado casi 30 MB de información útil, historial, búsquedas, archivos, etc.. que se puede extraer con programas de análisis como bulk_extractor, aesfind, o muchas de las herramientas de análisis de memoria disponibles públicamente


Sería más sencillo el análisis con herramientas como volatility framework, sin embargo en las pruebas realizadas no ha sido posible usarla, porque los plugins de vol.py esperan una estructura en memoria que no se corresponde a ninguno de los perfiles disponibles al estar sobreescrita un área de la memoria con la propia herramienta de volcado y tener algunas zonas con datos degradados debido al reinicio.

De todas formas el profesor puede dar los exámenes por perdidos y de paso su privacidad también,  igual si hubiera apagado el ordenador..

Soluciones.


La solución más simple creo que es bastante evidente: apagar el ordenador cuando no vamos a estar delante durante un tiempo, además tratar de no dejar aplicaciones que manejen datos sensibles abiertas, vamos, tratar el ordenador como si la siguiente persona con acceso físico a el pudiera acceder a todos nuestros datos sin más.

Por supuesto no estaría de más impedir el arranque desde dispositivos extraibles en la BIOS del PC, y después proteger el cambio de los valores de la BIOS con contraseña, aunque esto es fácilmente salvable (por ejemplo quitando la pila de la placa) en este caso en donde cada segundo que el pc esté apagado y cada reinicio juega en contra de la conservación de los datos, es una medida interesante.





jueves, 26 de diciembre de 2013

El timo del h4ckc0nt3st en GSICKMINDS 2013



Ya ha pasado un tiempo prudencial desde que decidí ir con mis alumnos a este evento organizado por el grupo GSIC (Grupo de Seguridad de la Información) de la Universidade de A Coruña, y este tiempo me ha valido para dos cosas, por una parte para ver objetivamente los hechos sin el calentón lógico de esos días y por otra para esperar respuesta a algunas cuestiones por parte de la organización o la universidad, en definitiva, no ha valido para nada. 

Por eso, después de este tiempo voy a publicar esto por aquí, que es la carta al rector que escribí informando de lo ocurrido y que es un resumen perfecto de la super-organización de uno de los supuestos eventos punteros de seguridad en este país, que encaja a la perfección en la mentalidad españistaní que reina por aquí últimamente.

También aprovecho para publicar los writeups de las challenges (que por cierto no eran nada fáciles, no es que hayamos ido de paseo) que algunos estaban esperando, porque me parece que si esperamos por la organización vamos apañados y ha pasado ya un tiempo razonable.

Aquí la prueba 2

Aquí la prueba 4 

Aquí la prueba 6

Y al tema, el correo: 

---


Estimado Señor Rector:


Me pongo en contacto con usted para ponerle al corriente de unos hechos que creo pueden ser de su interés, y que paso a detallar a continuación.


En el transcurso de nuestra participación en GSICKMINDS 2013 organizado por el Grupo de seguridad de la información de A Coruña en el Aula Magna de la Fac. de Informática de A Coruña los días 24,25 y 26 y en donde la FIC es el principal patrocinador y organizador. según anuncian en la información del evento


"GSICKMINDS es un evento organizado por el Grupo de seguridad de la Información de A Coruña (GSIC), nacido en 2009 bajo el patrocinio de la Facultad de Informática de A Coruña y la Universidad de A Coruña, con objeto de fomentar el desarrollo de sistemas de información seguros y proponer soluciones que salvaguarden la integridad y confidencialidad de los activos digitales."


hemos observado y sufrido una falta absoluta de organización y transparencia



En la página web del evento se anuncia una actividad llamada "h4ckc0nt3st" cuya descripción es la siguiente




----
La competición de seguridad y hacking creada por Miguel Gesteiro que celebramos en GSICKMINDS por tercer año consecutivo. Si te gustan las emociones fuertes te lo pasarás en grande porque habrá desafíos de todas las clases: criptografía, ingeniería inversa, programación, esteganografía, forense, análisis de red...


Para participar necesitas:


Apuntarte (tu equipo o tú solo) en el portal web que indicaremos DURANTE LA PRESENTACIÓN DE LA JORNADAS el jueves 24.
Curiosidad por saber cómo funcionan las cosas (¡espíritu hacker!)
Un ordenador (aunque NO para todos los desafíos... ;)
Uno de los objetivos de la actividad es promover la Seguridad Informática de forma práctica y desde un punto de vista ofensivo (tendrás que comportarte como lo haría un atacante real...). Pero nunca estarás solo: podrás hacernos todas las preguntas
que quieras y te daremos pistas.


Happy hacking!


Horario: desde las 10:00 del jueves 24, hasta las 12:00 del sábado 26 (24 h non-stop)
Fechas: jueves 24 , viernes 25 y sábado 26
Lugar: on-line (en la red WiFi de las jornadas)
Plazas: ilimitadas
Precio: gratuita
Premios: 1º 150€ | 2º 75€ | 3º 35€
----


Como formo parte de un grupo interesado en estos temas, y además imparto clase de seguridad informática en un centro privado, decido después de ver la descripción en la página apuntarme con mis alumnos reservando en los respectivos trabajos unas horas para poder asistir al evento.


El Jueves 24 a las 10:00 empezamos el evento, con los siguientes contratiempos:


- El evento empezó a las 18:00 después de numerosos retrasos, lo que es inaceptable, y aún lo es más que no se ofreciera ningún tipo de explicación convincente o al menos una disculpa por parte de la organización después de 8 horas de retraso en las que nos limitamos a esperar en el hall de la facultad.


- Cuando el evento empezó, se nos facilitó una web con unas normas internas del concurso que entre otras cosas especificaban que los no inscritos en las jornadas como asistentes podían participar pero sin derecho a premio, norma que entiendo debería ser anunciada en alguno de los múltiples anuncios previos al evento, y no con posteridad, cuando ya los equipos se han desplazado y apuntado.


- Decidimos continuar a pesar de estar participando ya sin derecho a premio. Dentro del esquema lógico del concurso, había 5 pruebas iniciales que fuimos resolviendo a medida que pasaba el tiempo .A falta de dos horas, se anunció la última prueba, algo del todo irregular y desequilibrante. A pesar de esto, resolvimos ya fuera de tiempo dicha prueba.


- Una de las pruebas, consistente en abrir un candado, es anulada después de que varios equipos la completaran con éxito, entre esos equipos el nuestro.


- Cuando el concurso acaba, a las 12:00 del sábado, detectamos que algún equipo todavía está realizando las pruebas y desde la organización nos contestan que "acabará a las 13:00 porque la hora del ordenador que usamos está una hora retrasado"



A pesar de esto, nuestro equipo ganó el evento con una diferencia de 20 puntos sobre el segundo, y no solo eso, sino que escribimos informes de cómo realizamos las pruebas que reenviamos a la organización, incluso hicimos la prueba del sábado a las 10:00 aunque fuera de tiempo, pero cuando asistimos a la conferencia de clausura, donde se iba a realizar la entrega de premios, no hubo ni una sola mención al concurso excepto que había "dudas razonables" en alguno de los puestos, y tenían que pasar un proceso de revisión, que anunciarían en twitter los ganadores.


Tras varios días y múltiples preguntas en twitter, no hemos obtenido ninguna respuesta por parte de la organización.


Después de estos hechos creemos que la imagen que ha dado la organización del evento ha sido totalmente irrespetuosa con los participantes, opaca y nos genera cierta desconfianza el método utilizado para ir poniendo trabas a determinados equipos en base a reglas no anunciadas con anterioridad.


Nosotros no hacemos esto por dinero, de hecho sólo el desplazamiento de las cinco personas de mi equipo desde Ferrol a Coruña durante tres días, más gastos, no hubiera compensado los 150€ que se anunciaban como premio, nosotros participábamos por poner a prueba los conocimientos adquiridos y por el reconocimiento que implica ganar un evento de estas características, pero el no tener ni una simple mención después de haber ganado es una terrible falta de respeto.


Por eso nos hemos puesto en contacto con usted, porque creemos que los actos que se organicen en la Universidad, con su patrocinio y aprobación, deberían tener cierto grado de control y unos mínimos de calidad que en esta ocasión no se han alcanzado.


Atentamente


David Carracedo Martínez


---

La respuesta llegó bastante tiempo después, desentendiéndose del asunto, porque la UDC pone las instalaciones pero GSIC es un grupo de alumnos y ex-alumnos no relacionado directamente, etc, etc..

Por otra parte, hemos intentado contactar con la organización por twitter, por mail, y las respuestas han sido de lo más graciosas, porque vereis, después de quedar primeros en un concurso de seguridad, que te contesten esto:


estamos analizando la máquina recién llegada: 20GB. Nos va a llevar un poquito :)

¿20 GB de logs de qué? si las pruebas consistían principalmente en binarios, te los descargabas y los hacías en tu propia máquina, ¿que tienen que revisar?, luego dicen que 

¡El server! :) tenemos que revisar logs para ver que no alteramos el ranking al introducir los puntos de

¿El ranking genera 20 GB de logs ? si éramos unos 20 equipos participantes y solo había que entrar ahí para descargar las pruebas y meter los códigos de las puntuaciones, ¿cuántas peticiones puede haber en este log?, 200, 20000, 200000... 20GB???!!

Y nada, después de eso han dejado de contestar básicamente, así que supongo que hasta el año que viene, cuando vuelvan a pedir instalaciones y fondos no se les verá el pelo, así que enhorabuena a la organización por un acto tan desastroso.

---
Edit: Añado algo de información sobre el evento porque claro, en la carta al rector no me metí mucho en el tema técnico porque supuse que no le resultaría muy interesante, así que explico un poco.

Un CTF es una competición de seguridad informática que consiste en capturar una "bandera" (de ahí el nombre, capture the flag) que suele ser una palabra clave escondida detrás de algún tipo de protección que hay que saltarse.

Este en concreto es un CTF de tipo jeopardy, en el que se apuntan equipos y tienen entre 1 y 3 días normalmente para realizar pruebas de varios tipos en distintas categorías que suelen ser (puede variar) network, crypto, forensics, reversing, binary, web, stego, programación, a veces preguntas tipo trivia .. de todo un poco, las pruebas dan puntos según su nivel de dificultad y más o menos es un standard que las pruebas más fáciles den 100 y las más dificiles 400, pero repito, esto depende del concurso y puede variar.

Se puede ver que hay una comunidad bastante activa a nivel internacional en sitios como ctftime.org que intenta llevar un control y un ranking sobre los eventos.

Dicho esto, desde el punto de vista técnico el concurso fue un desastre también, ¿por qué? pues..




----
La competición de seguridad y hacking creada por Miguel Gesteiro que celebramos en GSICKMINDS por tercer año consecutivo. Si te gustan las emociones fuertes te lo pasarás en grande porque habrá desafíos de todas las clases: criptografía, ingeniería inversa, programación, esteganografía, forense, análisis de red...
---

Lo normal, sin embargo cuando abrimos las pruebas nos encontramos 5 pruebas con el siguiente contenido:

Prueba 1: Una pregunta chorra: "de que color es el logo de la organización?"
Prueba 2: Reversing de un binario en arm
Prueba 3: Crypto, una prueba de criptografía mortal puesta por kachakil del equipo int3pids, aún no la hemos descifrado a día de hoy (primero estaba cifrado con XOR, de ahí sacabas un rar, ahí unos números y luego una locura :D divertido, pero no se pudo hacer)
Prueba 4: Reversing de otro binario!!! este demencial (ver el writeup arriba)
Prueba 5: Abrir un candado. Si, un candado físico, porque había un taller sobre eso en las jornadas.. sería divertido también, pero cuando 3 o 4 ya lo habíamos abierto el que organizaba la prueba dijo "uy.. es que es demasiado fácil, así que anulada, la repetimos con otro", y nos puso otro candado que no pudimos abrir, sin embargo la prueba la hizo más gente que la primera vez y no la volvieron a anular.

El CTF duraba 3 días, 72 horas.. y estas fueron las pruebas (decían que iban a poner más, pero nanai), cuando quedaban 3 o 4 horas para finalizar ponen..

Prueba 6: Reversing de otro binario!! que obviamente nadie pudo hacer a tiempo, porque era también bastante difícil, pero que hicimos un rato después de acabar, por cabezonada, y porque el último día no teníamos pensado ir, pero al ver que habían puesto una nueva prueba vía twitter, arrancamos el coche y nos desplazamos a Coruña otra vez, para asegurar el #1 en el ranking, cuando llegamos allí y vimos el panorama, ya nos dimos cuenta de que dificilmente se podría haber hecho a tiempo.


Total, que de las pruebas que prometían nada, la gente que no hace reversing fue de paseo, cada vez que hablábamos con alguien de la organización nos decía "tranquiiilos ahora mismo subimos otra prueba", pero nada, un fracaso total.

Quería añadir esto más que nada para la gente que ya sabe de que va el mundillo este, y para animar a los que no lo saben a que hagan cosas de estas.. fuera de españa :D hay un montón de CTF muy buenos a lo largo del año!









Writeup prueba 2 - h4ckc0nt3st - GSICKMINDS 2013



IWANTTOBELIEVE

El binario está compilado para ARM, se ha usado una Rpi para ejecutarlo.

Cuando se ejecuta, mira el contenido de /proc/cpuinfo y busca el string "MU-TH-R 182", si no lo encuentra, el programa finaliza.


Si se crea un chroot y en el se cambia el contenido de /proc/cpuinfo para que contenga ese texto, el programa continua y saca este texto.


Your token has been written, read it now before it expires.
To validate the token you will need to enter it uppercase with no white spaces.
Thanks.
Temporal token expired.


Si lo ejecutamos con strace, podemos ver que escibe algo en /tmp y luego lo borra


nanosleep({5, 0}, {4, 3936093})         = ? ERESTART_RESTARTBLOCK (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
unlink("/tmp/.muthr_tmp_token")         = 0
write(1, "Temporal token expired.\n", 24Temporal token expired.


Así que ejecutamos gdb para pararlo antes de que borre el fichero:

- break on __libc_start_main
run
- break on unlink
continue


file /tmp/.muthr_tmp_token


.muthr_tmp_token: GIF image data, version 87a, 200 x 250


IWANTTOBELIEVE


token.gif



Writeup prueba 6 - h4ckc0nt3st - GSICKMINDS 2013




El fichero omgdos es un ejecutable ELF 32bit Linux

$ file omgdos
omgdos: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x9b85ac423ba72581a5c483f8a1ed077004bde96e, stripped

El traceado revela llamadas de sistema a vm86, se usa el modo 8086 virtual :


# strace ./omgdos
...
execve("./omgdos", ["./omgdos"], [/* 21 vars */]) = 0
[ Process PID=7405 runs in 32 bit mode. ]
mmap2(NULL, 1048576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0
...
vm86(0x1, 0x804a780, 0x8048db2, 0, 0xfffc) = -1 ENOSYS (Function not implemented)

Para la ejecución en el modo virtual 8086 el programa host tiene que mmap-ear todo el código y los datos usados a la memoria y configurar handlers para los callbacks. La memoria esta en :


if ( alloc_mem(1048576u) == -1 )
 {
   v2 = __errno_location();
   v3 = strerror(*v2);
   fprintf(stderr, "%s: cannot mmap: %s\n", *(_DWORD *)a2, v3);
   exit(1);
 }
 sub_8048E3C(0, 31744u);
 sub_8048EDB(105u);
 v4 = sub_8048940(0, 0x7C00u);
 emulate((int)code, 671, v4, "C:\\WINDOWS\\RUNDLL32.EXE");

Para la interacción con el programa host se usa la interrupción 105 (0x69), el handler se implementa en


.text:08049016 handler         proc near               ; CODE XREF: sub_8048BFF+114#p
.text:08049016

Funciones:

0 – exit
1 – imprimir a stdout
2 – leer de stdin


El modo real se puede obtener interrumpiendo en la llamada de sistema VM86_INIT y volcando la reserva de memoria con la función alloc_mem():


# gdb -q ./omgdos
Reading symbols from /home/user/coruna/omg/omgdos...(no debugging symbols found)...done.
gdb-peda$ catch syscall vm86
Catchpoint 1 (syscall 'vm86' [166])
gdb-peda$ r
Catchpoint 1 (call to syscall vm86), 0xf7fdf430 in __kernel_vsyscall ()
gdb-peda$ generate-core-file core
Saved corefile core

Después se puede extraer el core:

$ cat extract_core
#!/usr/bin/python

f = open('core').read()
open('dmp', 'w').write(f[1600:1600+1000000])

Code is loaded on address 0x7C00 (like MBR):

seg000:7C00                 mov     sp, offset stack
seg000:7C03                 mov     ax, offset aDimeQuICenIElP ; "Dime, -+qu+¬ cen+¬ el pen+¦ltimo d+¡a e"...
seg000:7C06                 call    print
seg000:7C09                 mov     ax, 2
seg000:7C0C                 mov     bx, offset input
seg000:7C0F                 mov     cx, 100
seg000:7C12                 int     69h
seg000:7C14                 mov     ax, offset input
seg000:7C17                 call    near ptr decrypt_compare+1
seg000:7C1A                 test    ax, ax
seg000:7C1C                 jnz     short loc_7C23
seg000:7C1E                 mov     ax, offset winner ; "\x1B[1m-íS+¡!\x1B[0m -+C+¦mo lo has sab"...
seg000:7C21                 jmp     short loc_7C26
seg000:7C23 loc_7C23:                               ; CODE XREF: seg000:7C1C#j
seg000:7C23                 mov     ax, offset nope ; "Pffff pero qu+¬ me est+ís contando.\n"
seg000:7C26
seg000:7C26 loc_7C26:                               ; CODE XREF: seg000:7C21#j
seg000:7C26                 call    print
seg000:7C29                 mov     ax, 0
seg000:7C2C                 int     69h

Imprime la cadena
Dime, ¿qué cené el penúltimo día en el festival de Ortigueira?
comprueba la entrada de usuario, y si acierta imprime
¿Cómo lo has sabido? Venga, pon la solución en la web y luego búscame para explicarme cómo demonios lo has hecho.
y en error
Pffff pero qué me estás contando.

Rutina de descifrado:


seg000:7C2E aLgimijhflyUMns db 'Lgimijhfly+u-mnsp}' ; DATA XREF: seg000:7C47#o
seg000:7C40                 db  7Fh ;  
seg000:7C41 ; ---------------------------------------------------------------------------
seg000:7C41                 jnz     short near ptr aDimeQuICenIElP+24h
seg000:7C43
seg000:7C43 decrypt_compare:                        ; CODE XREF: seg000:7C17#p
seg000:7C43                 cmp     [bp+57h], dl
seg000:7C46                 push    cx
seg000:7C47                 mov     si, offset aLgimijhflyUMns ; "Lgimijhfly+u-mnsp}"
seg000:7C4A                 mov     di, ax
seg000:7C4C                 xor     cx, cx
seg000:7C4E
seg000:7C4E loc_7C4E:                               ; CODE XREF: seg000:7C60#j
seg000:7C4E                 inc     cx
seg000:7C4F                 cmp     cx, 16h
seg000:7C52                 jz      short loc_7C67
seg000:7C54                 mov     al, [di]
seg000:7C56                 xor     al, cl
seg000:7C58                 mov     ah, [si]
seg000:7C5A                 cmp     al, ah
seg000:7C5C                 jnz     short loc_7C62
seg000:7C5E                 inc     si
seg000:7C5F                 inc     di
seg000:7C60                 jmp     short loc_7C4E

Hace un XOR con la posición de cada caracter y lo compara con un string prefijado. La entrada se puede calcular:


t='4C67696D696A68666C792B752D6D6E73707D7F756138'.decode('hex')
s=''
for i in xrange(len(t)):
s += chr(ord(t[i])^(i+1))
print s

Así que la respuesta correcta es “Mejillones y cacaolat.”