¡Nos vemos en España!

Gracias los grandes esfuerzos de Diego el gallego y Chema josemaricariño visitaré España en algo menos de un mes. Las excusas son las jornadas de seguridad organizadas por GSIC y los labs de la RootedCon. Así que vamos por partes.

Qué: Daré un taller sobre seguridad en sistemas Linux
Dónde: En el Campus de Elviña de la Facultad de Informática de A Coruña.
Cuándo: Las jornadas son entre el 24 y el 26 de Febrero.
Qué hay que hacer para asistir: La asistencia es gratuita con previa inscripción, la cual aún no está abierta pero lo estará pronto (posiblemente sea anunciado en @ficsecurity). Hay unas 25 plazas disponibles.
El taller será netamente práctico y será de unas 5 horas, por lo que tengo entendido. Trataremos temas de seguridad básica, como el acceso discrecional, la administración de recursos y PAM. Está orientado a iniciados en la administración de sistemas Linux-like.



Qué: Haré una introducción a la criptografía en uno de los Labs, previos a RootedCon
Dónde: En las Instalaciones Madrid On Rails, en Madrid.
Cuándo: Los Labs son entre 28 de Febrero y el 2 de Marzo. El mío en particular será durante el 1º.
Qué hay que hacer para asistir: La asistencia requiere inscripción previa y tienen un coste de 200 € + IVA. Hay 12 plazas disponibles.
Se puede acceder al temario aquí, aunque puede que dé una incorrecta impresión. En el momento que lo escribí hice demasiado foco en la parte matemática (aburrido!!). Si bien aún lo estoy preparando, el cursillo tendrá un foco mucho más programático. El objetivo es la mejora de decisiones tecnológicas cuando impliquen criptografía. Haremos prácticas en OpenSSL, SSH y PGP.

¿Nos vemos allí?

the root of all mistake: the overgeneralization

Yes, it's me again with this DSA-1571 exploitation issue. The discovery, explanation and exploitation of the bug is now part of my final coursework for my postgraduate degree career. So, yes... sorry.

Some weeks ago I started suspecting about the attack to PFS in SSL with EDH. The key point is: the key space is dependent of the PRNG state. The bug affects the initialization of the PRNG, but the random string has not a pattern by it self. If you ask for many random numbers to the PRNG, you gonna get numbers that differ among them, since they are the output of a hash function of them self. So each random number depends on, besides the PID, the state of the PRNG pool in the moment (in other words, amount of bytes that you already pull from the PRNG pool before)

The explained attack was based in a fixed list of private exponents (which are selected randomly during the DHE handshake), presupposing that all the application call RAND_bytes() the same number of times before get it. To make the list of exponent I ran the openssl s_client with all the possible PIDs, hoping that all the applications behaves the same way.

After more tests I notice that that was an overgeneralization. The proof is in the pudding: wget and cURL, two simple CLI file retrievers, gets different exponent between them, even running with the same PID.

I was working on this when I accidentally found a really nice Eric Rescorla's post which is deeply related with this. The post goes further and analyzes the interaction between how Apache forks off and how it generates SSL handshakes.

So, I made lists of secret exponents for wget, curl, openssl s_client and openssl s_server with a modification version of libssl (appling this messy patch) and running scripts like this:

for i in $(seq $((2**15)));
do
  export MAGICPID=$i;
  LD_LIBRARY_PATH="openssl.broken/" LD_PRELOAD="./getpid.so" \
     wget --no-check-certificate https://localhost/ -q  -O /dev/null ;
  echo $i ;
done

As you can see, I used the HD Moore's GetPID faker shared library and a normal local Apache with mod_ssl. The broken libssl (which is in .openssl.broken/) store up in /tmp/data.key a csv with command name, PID and all the DH components (g, x, y and p).

But this way is farly unconfortable for others SSL deamon servers. Have you got any better idea?

Exploiting DSA-1571: How to break PFS in SSL with EDH

( I love acronyms :-D ) Tal vez quieras leer esto en español.

At this point, all of you should know and see how the H D Moore’s toys work. Those toys attack SSH public-key authentication using clone keys and online brute force.

Furthermore, many of you know that there are other effects produced by a biased PRNG besides this one.

Strangely, I could not find more of those toys exploiting these aspects. So, I would like to show you a Wireshark patch which attacks Perfect Forward Secrecy (PFS) provided by Ephemeral Diffie Hellman (EDH).

Introduction to EDH

Let’s put it in plain words (if you know what we are talking about, ignore this and jump to the next heading):
In an insecure communications channel the parties agree a common key to cipher their dialog. This is what happens in SSL (in most of the cases, depending on the cipher suite):

  • The server selects a random prime p and a generator g of the field Z*p (Let’s ignore the mathematical properties of these values). So, the components p and g are public.

  • The server picks a secret random number Xs and calculates Ys=gXs mod p. Ys is public and is sent to the client (just like p and g).
  • The client does something similar, selecting a secret random number Xc and calculating Yc=gXc mod p too. The client makes Yc public by sending it to the server.
  • The shared secret s is the public key of the other part to the exponential of the own private number, all in p modulus. That is, for the client s=YsXcmod p and for the server s=YcXsmod p.
  • With this shared secret the parties can encrypt all the following messages in a secure way.
  • In the Ephemeral Diffie Hellman (EDH), the private numbers are ruled out, so s is mathematically secure and nobody can obtain it even having access to one of the parties after the aforementioned handshake.

The “exploit”

If an eavesdropper can explore the complete private key space (the all possible numbers for Xc or Xs), he/she will be able to get access to the shared secret. With it all the communication can be deciphered. That’s what this patch can do.

A Wireshark with this patch and a list of possible private keys will try to brute force the share secret. If one of the parties is using the vulnerable OpenSSL package the communication is totally insecure and will be decrypted.

  • The patch for Wireshark 1.0.2 can be downloaded from here.

  • Debian packages with the patch applied can be found here.
  • This is a list of all 215 possible 64 and 128 bit DH private keys in systems vulnerable to the predictable OpenSSL PRNG described by DSA-1571.
  • An example of a pcap file can be found here (it was built with a vulnerable client and one of the Moore toys, a hacked getpid by running $ MAGICPID=101 LD_PRELOAD=‘getpid.so’ ./vulnerable-openssl/apps/openssl s_client -connect db.debian.org:443 )

The patch was submitted in order to be committed on the Wireshark trunk. There you can find the patch against the on-develop source revision 25765.

Issues that can be improved

We (the other developers and myself) detected few things to be improved. But we will do nothing for them. So, if you want to contribute with some code, start from these items and submit the patches to the Wireshark’s bugzilla:

  • When the packets are out-of-order the decipher with stop itself.

  • The brute force attack should run in a background process (and with a progres bar)
  • Check the length of the keys before trying to brute force them.
  • The patch also implements the display of public DH parameters in the packet tree. It’s incomplete.

Credits

Paolo Abeni <paolo.abeni at email.it>
Luciano Bello <luciano at debian.org>
Maximiliano Bertacchini <mbertacchini at citefa.gov.ar>

This work was partially supported by Si6 Labs at CITEFA, Argentina.

UPDATE Jul. 21st: See more and updated info here, especially this.

porqué el 'Debian/OpenSSL debacle' no afecta mi creencia de que Debian es el mejor OS del mundo

En estos días escuché cosas como “Seguramente provocaste la mayor migración de usuarios de la historia, ya nadie querrá usar Debian en sus vidas”. Otros párrafos sobre la vergüenza que caía sobre los desarrolladores, sobre nuestros procesos de calidad llovieron de a decenas en mi inbox.

Este tipo de cosas me hizo reflexionar. Y es esta reflexión la que me gustaría compartir con ustedes.

Hace un tiempo ya, cuando casi sin querer y por accidente me encontré con el problema, simplemente me negué a creerlo. No podía ser. Era tan trivial y estuvo ahí, frente a nuestras narices tanto tiempo... parecía ser evidente de que yo estaba haciendo algo mal. Tardé mucho en confirmarlo, y aún con la duda lo reporté.

Junto a mi reporte adjunté un parche ridículo, casi insultante. Consistía en:
-/*
- * Don’t add uninitialised data.
MD_Update(&m,buf,j);
-*/

Esto fue el día 5 de Mayo. Al día siguiente tenía una respuesta, con una clara dirección de trabajo. A los pocos días se me informaron la fecha en la que el DSA saldría. Todo fue tan expeditivo, tan admitido, sin subestimaciones, pero con un fuerte sentido de la responsabilidad. Me pareció de una brillante sensatez el desarrollo de dowkd.pl antes del anuncio.

El 14 de Mayo el usuario tenía todos los elementos para defenderse. El paquete openssh-blacklist resultó ser sumamente útil y fue un aliciente entre el caos generado.

En mi vida no he enviado muchos advisories grandes (es el primero que hago totalmente por mi cuenta). Pero me pregunto: ¿Qué hubiese pasado si un problema como este hubiese surgido en algún otro software de alguna empresa? ¿Qué hubiese pasado si, en vez de ser un desarrollador de Debian el descubridor fuese un empleado de esta compañía? El bug dejaría de ser un vergonzoso accidente para convertirse en un devaluador de acciones. La baja de ingresos por clientes perdidos podría hundir la empresa.

En esta caso la historia hubiese sido distinta.

Es por esto que creo que el modelo de software libre es bueno, y en particular Debian es bueno, porque no responde a presiones comerciales, porque no oculta sus problema y porque su prioridad es el usuario.

Sin duda, problemas en el software habrá siempre. Sin duda, este fue un problema de proporciones épicas. Sin duda, la confianza en Debian se ha visto afectada. Pero la lección está aprendida. Y Debian sigue siendo mi sistema operativo favorito.

Esto no es una justificación, sino una profunda opinión personal.

cryptographic apocalypse

Well, maybe I was a little noisy with my first DSA. I will try to be quieter next time :)

I think that many people are being very unfair with the OpenSSL’s maintainers. They made (and are making) a really good job. Was an accident, that things happens.

What we need is a real auditory process of the Debian specific patches. It’s hard, but it’s necessary.

Libros del 2007

Terminó el año y es un buen momento para comentar sobre lo leído durante el mismo. Creo que en orden de finalizado, los libros que leí durante 2007 son:

  • Criptonomicón (II y III), de Neal Stephenson
    Una excelente saga que termina de una excelente manera. Una novela perfectamente geek. Altamente recomendable.

  • Turing y el computador, de Paul Strathern
    Una biografía esclarecedora y entretenida. Con cierto contenido teórico y buena explicación de las bases computacionales que hicieron de Turing el mayor exponente de la computación moderna. Lo leí como bibliografía para la charla Criptografia desde su Aplicación Domestica.

  • El perfume, de Patrick Suskind
    Tuve que leerlo medio por obligación, y resultó ser no tan malo. Aunque no es mi estilo de novela, es entretenida y llevadera.

  • El curiosos incidente del perro a medianoche, de Mark Haddon
    Ingenioso y original. Con lindos giros que alternan entre situaciones de tensión incómoda con los divagues mentales de cualquier chico.

  • El teorema, de Adam Fawer
    Si bien es particularmente fantasiosa, tiene muchos guiños nerdies sobre matemática que lo hace muy llevadero, más allá de algunos errores técnicos. Tiene una excelente explicación del la paradoja del cumpleaños y de otros conceptos de estadísticos. Con respecto al Demonio del Laplace, deforma la teoría hasta llevarla al límite con lo esotérico y ciencia-ficcionario, pero muy llevadero. Me hizo acordar a mis épocas de lector cyberpunk.

  • La matemática del siglo XX, de Piergiorgio Odifreddi
    Un muy buen libro de divulgación científica. Es un recorrido por los mayores avances de la matemática del siglo. Para definir mayores avances el autor se basa en los problemas de Hilbert así como también aquellos descubrimientos y temas galardonados por la medalla Fields.

  • Go, el juego más fascinante.
    Es un pequeño y conciso librito con lo mínimo y necesario para iniciarse en el juego del go. De rápida lectura y entendimiento viene con un tablero de cartón para empezar a jugar inmediatamente.
    Einstein relativamente fácil, de Javier Covo Torres
    Es sorprendente la simpleza y, a la vez, profundidad explicativa de este libro. Con un lenguaje doméstico demuestra que la teoría de la relatividad puede ser entendida por mortales-no-físicos, espantando los demonios de la complejidad que la misma parece inducir.

  • La naranja mecánica, de Anthony Burgess
    Un clásico que merece ser leído. Aunque algo chato de a ratos, tiene frases que son sumamente inteligentes.

  • 1984, de George Orwell
    Uno empieza a ver el mundo con otros ojos después de leer esta novela. Imperdible.

  • Economía para principiantes, de Alejandro Garvie / Sanyú
    Si bien su excesiva compresión y resumen dejan sabor a poco, resulta ser una entretenida introducción a la economía política.

En este momento estoy leyendo, como continuando la saga de novelas distópicas británicas, Un mundo feliz de Aldous Huxley.
Otro viento proveniente de Mountain View trajo dos nuevos libros. En este caso, con el objetivo de mejorar un poco mi go:The Second Book of Go, de Richard Bozulich y Lessons in the Fundamentals of Go, de Kageyama Toshiro. Ambos quedarán para las vacaciones, junto con El último teorema de Fermat de Singh Simon.

UPDATE January 17th
Me quedaron en el tintero dos libros de los que prefiero olvidar que pagé por ellos. Los compré cuando estaba escribiendo un resumen sobre Kryptos y criptografía clásica, pero no llegaron a cumplir mis expectativas:

  • Codes, Ciphers and Secret Writing, de Martin Gardner
    Aburrido, excesivamente clásico, básico y chato.

  • Cryptography, de Laurence D. Smith
    Idem, anterior. Tal vez levanta un poco porque tiene desafíos y explicaciones sobre técnicas de criptoanálisis clásico. Tampoco rocket science.

Esteganografía en Audio

¿Qué tienen en común estos libros?

Son todos referencias del informe de Procesamiento de Señales en el que estoy trabajando este fin de semana: Análisis y Detección de Esteganografía en Audio. Incluye un pequeño programita (mitad en R, mitad en C) para analizar como se deforma el audio cuando es manipulado esteganográficamente. Tengo pensado colgarlo acá en un par de semanas, cuando tenga mejor forma, pero ya afloran algunas conclusiones:

  • Las grandes amplitudes favorecen el ocultamiento
  • Las altas frecuencias también
  • No hay ganancia real en modificar solo un porcentaje de las muestras

¿Interesado en el tema? Estoy a la escucha de sugerencias e ideas, sientete libre de pedir más información.

UPDATE August 6th: El informe y los archivos relacionados ya está publicados.

adquisiciones

Por razones relacionadas con exámenes parciales, no he comentado algunas de mis últimas adquisiciones:
En primer lugar, libros. Gracias a Ben y Nattie compré en amazon.uk los siguientes títulos:

Por otro lado, el plato fuerte: compré una nueva portátil, una X60, con UltraBase y todo. Todavía está en proceso de instalación y de hacerle andar todos los chices. Supongo que tendré que dedicarle tiempo durante las próximas semanas.

/* Mi antigua T42 busca dueño. Si estás interesado envíame un correo o deja un comentario */

new/old challenges

Desde hace unos meses, he sumado dos elementos al unitario conjunto de hobbies en mi vida (me refiero a los hobbies extra-computacionales), que estaba compuesto, únicamente, por eventuales apariciones de mi vulgar fotografía. Si bien gusto de leer, no lo considero tanto un hobby, sino algo necesario, con lo que lo excluyo del conjunto. Estos dos nuevos elementos son: el juego del go y el baile de la danza rioplatense. Ambos, en una evidente condición de neófito pero sin duda muy disfrutables, me ayudan a despejarme en los cada vez menos disponibles espacios de ocio.

La razón de esta reducción de idle time es provocada por:
a) La vida universitaria, la pila de materias que estoy cursando para recibirme rápido y la cantidad de trabajos prácticos que implican estas materias.
b) El cursado de un posgrado en Criptografía y Seguridad Teleinformática que empecé recientemente.
c) Algunos trabajos que estoy empezando a hacer para una empresa de seguridad local, llamada Shellcode y en la que espero divertirme mucho. (Esto se suma a mi actual trabajo, no lo reemplaza).
d) Retomar el mucho trabajo pendiente que tengo en Debian.

Empiezo nuevos desafíos. Continúo los pendiente. Y eso está bueno :).