OpenSSL, GnuTLS, Goto Fail y otros bugs en criptografía

Figura 1: No Lusers 168 - Operación Bullrun en marcha

Cuando en mitad del escándalo se filtraciones de documentos de la NSA por parte de Edward Snowden salió a la luz información sobre la Operación Bullrun del GCHQ y la NSA todos nos quedamos un poco sorprendidos. ¿Cómo iba a poder la NSA inyectar errores en los estándares criptográficos?

Tras hablar unos minutos en aquel entonces con Alfonso Muñoz, uno de los escritores del libro Criptografía Digital: Del cifrado clásico a RSA, especulamos con que lo más sencillo sería meter pequeños errores en las implementaciones que no estuvieran muy auditadas. Al final, es fácil colar un error sutil en el código y que esté años generando números aleatorios que no sean tan aleatorios.

Figura 2: Diapositiva sobre la operación BullRun filtrada del GCHQ

Si has leído el libro del Criptonomicón, esto es algo de lo que se habla largo y tendido cuando se explica en detalle el trabajo de los criptoanalistas o "code breakers" en la segunda guerra mundial. "¿Cómo será de aleatorio el proceso de extracción de bolas para la generación de las tarjetas de números?".

Lo cierto es que si echamos un poco la vista atrás, el número de errores en implementaciones de soluciones criptográficas ha sido grande en los últimos años, por error humano y falta de una auditoría profunda del código.

En el año 2006, el argentino Luciano Bello localizó un error en el código de OpenSSL/Debian que hacía que se generasen claves en un rango muy pequeño, lo que hacía que pudieran calcularse todas las posibles claves en poco tiempo y se pudiese descifrar cualquier tráfico cifrado o localizar cualquier clave privada de autenticación. En este enlace tienes un seminario dictado por Luciano Bello donde lo explica en detalle y en el siguiente vídeo los 10 minutos de la explicación del error en concreto.

Figura 3: El bug de OpenSSL/Debian
En el año 2007, como recoge nuestro compañero Juan Luís en la explicación de cómo se utiliza la aleatoriedad en sistemas de seguridad se descubrió un problema en el generador de números pseudoaleatroios de Windows XP y Windows 2000 que permitía llegar a predecir los números que se iban a generar en un sistema.
En 2010 ya se tenía suficiente conocimiento y potencia como para que se rompieran las claves RSA de 512 y 768 bits, lo que dejaba descubiertos muchos certificados digitales y claves de acceso y ponía en la punta de mira de un futuro cercano las claves de 1024 bits, como explicaba Sergio de los Santos en su artículo sobre la carrera criptográfica entre Microsoft y Google.
En el año 2012 se descubrió The Flame, una ciber-arma creada únicamente para infectar equipos y robar información de ellos que llevaba viva al menos desde 2011, y que había conseguido pasar bajo el radar de todos los sistemas antimalware debido a que se había firmado el software con una certificado roto de Microsoft, lo que obligó a la compañía a cambiar todos los certificados digitales que utilizaba.

Figura 4: El certificado digital usado por TheFlame que Microsoft tuvo que revocar

En el año 2013, se analizan las librerías criptográficas de Java para la generación de aleatoriedad y salen debilidades a la hora de generar entropía necesaria para la generación de claves en determinados escenarios. Ya cuando estábamos en el proceso de creación de DUST RSS vimos que las librerías estándar de Java tenían CVEs reconocidos con problemas de aletoriedad y había que utilizar librerías externas.
En Agosto de 2013 se descubre que la función SecureRandom de Android no utiliza /dev/random - función que garantiza la entropía necesaria para garantizar la aleatoriedad, algo que por defecto, como se explica en detalle en este artículo del blog de Eleven Paths, no hace /dev/urandom.
En Diciembre de 2013 en la CCC, en la presentación de Jacob Applebaum se habla de la posibilidad que se supone que tiene la NSA para saltarse el Code-Signing de Apple en todos los dispositivos iOS e instalar apps sin pasar por la validación de AppStore. Hay que recordar que si no hay que utilizar un Provisioning Profile por cada dispositivo para instalar un troyano en iPhone. Es la Operación DropOutJeep según la NSA.

Figura 5: La Operación DropOutJeep

En Febrero de 2014, Apple saca un parche de emergencia para iOS y OS X para arreglar el bug de Goto FAIL en la verificación de certificados digitales que podría permitir, con un certificado especial, saltarse cualquier comprobación de certificado digital correcto. 

Figura 6: El segundo Goto Fail invalida todas las comprobaciones siguientes

A principios de Marzo de 2014, se confirma en una auditoría de código de GNU/TLS por parte de RedHat que hay una fallo serio en la verificación de certificados digitales que permite saltarse cualquier protección basada en claves generadas con ese software.

Figura 7: El bug de GnuTLS en las funciones de verificación de certificados

También, durante el mes de Marzo de 2014, en la conferencia CanSecWest 2014 se demuestra que el generador de códigos aleatorios de iOS 7 es inseguro, mientras que el de iOS 6 sí que era seguro.
Si a estos pequeños y no tan pequeños errores de implementación se suman los errores no conocidos públicamente, los certificados generados con algoritmos y claves inseguras, las debilidades del protocolo HTTP-s con la implementación de las reglas de confianza, las cada vez más importantes capacidades de cómputo y los exploits para todo el software implicado en cualquier sistema  que use criptografía parece que la Operación Bullrun podría haber sido un éxito.
Saludos Malignos!