lappy back & manizales

La noche de 26 de agosto, mi laptop dejó de encender. Para ser estrictos, encendía pero se reiniciaba al segundo, antes de que el video levante. Desde la mañana del 27 ha estado pasando por varias manos de distintos servicios técnicos. Desde ese momento me vi forzado a tratar con soluciones temporales (como la comentada en este post) y lectura de correos en webmails. Finalmente, el viernes pasado decidí, para resolver el problema de cuajo, comprar un motherboard nuevo y ya. Resultó ser mucho más expeditivo y solo costó una fracción del arreglo. Así, el lunes, a solo 4 horas para partir a Colombia, me reencontré con mi amada lappy en perfecto estado de funcionamiento. ¿Y el motherboard viejo?

Después de más de un mes sin bajar correos, la cosa se puso algo espesa.


Ahora tengo cantidad de cosas en mi ToDo List. Y para echar más leña, esta semana tampoco será de lo más productiva. Ponerme al día me llevará un tiempo.

En cuanto al paso por Colombia, aún sigo aquí. La estoy pasando de maravillas, me he encontrado con varios viejos conocidos (incluyendo Chema y Gunnar) y la organización me hace sentir como en casa.

En este 3º Encuentro Internacional de Seguridad Informática me convoca dos temas bizarros, el primer por viejo y el segundo por clásico. Es que volver a hablar de OpenSSL hace que tenga que sacudir el polvo de viejos slides. Pero hablar de Kryptos, es aún más raro y genial. Los slides estarán disponibles en este post, seguramente en estos días. Junto con las fotos.

UPDATE Wed, 14 Oct 2009 12:23:29 -0300: Las diapos, de la charla de OpenSSL y de la de Kryptos. Enjoy them! (las fotos, con un poco más de tiempo)

On tour (bonus stage): 25C3 - Berlín, Alemania

Primero lo primero: Madre, estoy vivo. Y ya no estoy en Berlín, sino en Amsterdam.

Cumplido ello, al foco. Tuve la oportunidad de participar del 25th Chaos Communication Congress (25C3), lo que fue una experiencia realmente increíble. La gente, los anuncios, las mesas de distintos proyectos y todas esas cosas hicieron de CCC uno de mis eventos favoritos.

El año terminó y con él el tema del bug de OpenSSL/Debian. Solo me queda entregar mi informe en el posgrado y defenderlo, pero espero terminarlo cuanto antes y enterrar así el tema. Es hora de cosas nuevas.

En cuanto al resto, pasé un fin de año muy atípico. Con amigos y desconocidos. Raro pero bien. También en estos días me encuentro aplicando para un interesante puesto laboral (como dudo que se concrete, no daré más detalles), con lo que es algo más en mi cabeza. Durante una caída, mi cámara de fotos dejó de funcionar como corresponde, así que pueden ver las fotos de terceros en estos lugares: las de Machu y las de Maxi. Estoy tratando de hacer una subselección para poner en el lugar de siempre, pero no me he hecho del tiempo. En cuanto llegue a casa veré cómo me hago de una nueva cámara.

Como dije, ahora estoy visitando Amsterdam, idea que surgió medio improvisada. El 6 tengo pasaje a casa desde Frankfurt, por lo que tampoco puedo colgarme mucho.

Ahora a dormir, que me estoy cayendo del sueño...

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?

snail mail

Después de varias semanas sin pisar casa (Grand Canyon, Black Hat, DefCon y DebConf) detrás de mi puerta hay correo (del tradicional) en cantidad inusual. De un tiempo a esta parte, el correo no electrónico decantó en una forma de hacer llegar facturas, recibos, muestras gratis y nada más. Los sentimientos en el siglo XXI ya van por otro lado. Sin embargo, esta carta fue distinta:



Se trata del número de Agosto de Linux Magazine. El lector observador notará que no está en inglés, ni en alemán, sino en neerlandés. Me la envió Koen Vervloesem, quien hace poco menos de 3 meses me solicitó vía correo (del electrónico) detalles sobre la falla dsa-1571.

Obviamente lo único que soy capaz de entender es mi propio nombre, pero lo que cuenta es la intención :). Gracias Koen por el detalle, se que entenderás este post tanto como yo la nota :P.

Y hablando de correo físicamente transportado (aunque sin relación con lo anterior, que fue totalmente gratis), uno se da cuenta que vive en las antípodas del mundo donde le gustaría estar cuando recibe facturas de encomienda como esta:


Bizarro... pero cruelmente real.

volviendo de Las Vegas

Es difícil describir la intensidad de los últimos días. Solo a modo de dar una idea, en la última semana hice 5 check-in, vi una veintena de charlas, dí dos y conocí a decenas de personas sumamente inteligentes.

Vamos a lo importante: nuestras charlas :P. Tengo la impresión que hicimos una actuación mas que respetable. En ambos casos nos desenvolvimos muy bien y, creo, con claridad. Mucha gente nos hizo comentarios muy positivos y los asistentes parecieron divertirse. Me siento sumamente contento por ello.

Además de esto, hay cinco millones de cosas más que contar, incluso algunas más importantes y divertidas. Pero trataré de realizar esa tarea durante el avión de regreso a casa. El cual sale en 5 horas, ya que en este momento son las 2am. Ahora estoy realmente cansado y necesito terminar de hacer mi valija...

Ah! Casi me olvido. Para los colgados de siempre que nunca se enteran de nada... las fotos (aunque aún sin comentarios descriptivos) están, casi todas, acá. Enjoy them.

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.

cartoon

Después de pasar más de un mes sin bloguear, uno siente la obligación de tener que hacerlo por una buena causa.

Y ésta me pareció que lo es. Durante mi periódica vuelta por el lado del mal me encuentro una simpática repercusión tardía del ‘Debian/OpenSSL debacle’, siempre desde su peculiar perspectiva el amigo Josemaricariño publicó:


click para agrandar
Una vez más, muchas gracias al maligno por el reconocimiento. Es raro verse en forma de cartoon :oP.

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.