Cómo terminé tropezando con la vulnerabilidad de claves débiles de Debian

La historia de cómo terminé cayendo en la vulnerabilidad de claves débiles de Debian

• En marzo de 2008, el autor estaba trabajando en Engine Yard (EY)
• En ese momento, EY estaba ayudando a GitHub ofreciéndole infraestructura gratuita
• A medida que GitHub crecía, surgió un problema: los tiempos de inicio de sesión por SSH se volvían lentos
• GitHub estaba administrando las claves SSH usando el archivo estándar ~/.ssh/authorized_keys
• Cuando un usuario se conecta, SSH abre este archivo y busca linealmente una clave que coincida con la que presentó el usuario
• Normalmente no hay problema porque solo hay unas cuantas claves, pero cuando hay muchos usuarios, como en GitHub, se vuelve lento

Se decide usar una base de datos MySQL en lugar del archivo authorized_keys

• Tras revisar varias alternativas, decidieron modificar OpenSSH para que la búsqueda de claves se hiciera en una base de datos MySQL
• Fue una decisión tomada con cuidado, y se hizo un gran esfuerzo para no comprometer la seguridad
• Se aplicó a inicios de abril de 2008 y resolvió el problema de velocidad en los inicios de sesión por SSH

Ocurre algo extraño

• Un mes después, a inicios de mayo, apareció un problema: algunos usuarios podían acceder por SSH a los repositorios de otros usuarios
• La investigación mostró que distintos usuarios estaban usando claves con la misma huella digital
• Esto no debería pasar a menos que estuvieran compartiendo la misma clave
• Los usuarios decían que no se conocían entre sí y que no sabían cómo se había filtrado la clave
• El mismo problema se encontró en otros pares de usuarios
• Lo único que todos tenían en común era que usaban sistemas Debian o Ubuntu

Se identifica la causa

• El 13 de mayo de 2008, con la publicación de DSA-1571-1, todo quedó claro
• Un mantenedor de Debian, mientras limpiaba el código de generación de números aleatorios de OpenSSL, redujo por error la cantidad de claves posibles a unas 32,000
• Muchas personas se registraban en GitHub y, siguiendo las buenas prácticas, generaban claves nuevas, lo que provocó colisiones
• Después, el autor siguió más involucrado con este problema, por ejemplo usando claves débiles ya conocidas para encontrar autoridades certificadoras afectadas

La opinión de GN⁺

• Para descubrir una vulnerabilidad tan importante, hace falta pensar “esto es raro” y tener el tiempo y la energía para investigarlo con persistencia. Normalmente no se dispone de ese margen, así que también hace falta algo de suerte.
• La mayoría de las personas están demasiado ocupadas con el día a día como para llegar hasta la causa raíz del problema. Recuperar ese espacio en nuestra industria es una tarea importante.
• OpenSSL es una de las bibliotecas criptográficas más usadas, así que el impacto de una vulnerabilidad así es enorme. Aquí se ve con claridad tanto la ventaja como la desventaja del open source.
• Para prevenir este tipo de vulnerabilidades, hay que reforzar la revisión de código y las auditorías de seguridad, y examinar con más cuidado los cambios en partes críticas. Aun así, no existe un método perfecto.
• Incluso así, el open source tiene la ventaja de que especialistas pueden revisar directamente el código y encontrar problemas. En los programas cerrados ni siquiera eso es posible.

[GN⁺]

Opiniones de Hacker News

• Luciano Bello descubrió por casualidad la vulnerabilidad CVE-2008-0166, y según los registros de IRC de ese momento, se necesitaban muchos primos pequeños y no se obtenía el mismo número cada vez
• Parece que toda la industria tuvo suerte, porque había alguien con las habilidades, el tiempo y la energía para marcar una gran diferencia en el momento adecuado. Es un caso que hace sentir muy reales las estadísticas de "muchos ojos" y "la luz del sol es el mejor desinfectante". Por más baja que sea la probabilidad de que alguien encuentre un bug por accidente, la gente termina encontrándolo porque eso puede pasar. En cambio, en el código privativo/cerrado, esa probabilidad es 0
• El cambio que provocó esta vulnerabilidad no se hizo a las apuradas. Un mantenedor planteó el problema en la lista de correo de OpenSSL, pidió retroalimentación y propuso una solución, y recibió algunos comentarios, incluso de upstream. El resultado fue una vulnerabilidad terrible, pero parece ser un caso enormemente desafortunado en el que nadie detectó el problema
• GitHub llegó a la conclusión de que la mejor opción era parchear OpenSSH para consultar claves indexadas por huella digital en una base de datos MySQL. Parece que eligieron MySQL en lugar de SQLite porque era el tipo de situación en la que MySQL podía brillar, dado que estaban intentando acelerar el acceso a ~/.ssh/authorized_keys
• Esto hace pensar en la posibilidad de que algo así ocurra en la función de generación de semillas de una billetera física de Bitcoin popular y en las consecuencias que tendría
• También fue un episodio interesante la detección de claves RSA con factores comunes 'p' o 'q' usando GCD
• Se puede ver que un tiempo de inicio de sesión SSH lento es una pista que vale la pena seguir por una u otra razón
• El RNG de OpenSSL se sembraba con memoria de pila no inicializada y el PID, pero incluso sin el parche de Debian, parece que sembrarlo solo con el PID ya era bastante riesgoso
• Me pregunto si GitHub todavía sigue ejecutando ese OpenSSH parcheado
• Es divertida la frase de que Ezra Zygmuntowicz le presentó GitHub al autor y le dio tiempo para investigar el problema junto con el equipo de GitHub. Quizá porque se lee como si el propio equipo de GitHub tuviera un gran problema
• Me pregunto cuánto más tiempo habría pasado sin ser detectado si Luciano no lo hubiera encontrado. Pienso que solo unos pocos lugares que almacenan miles de claves de usuarios, como GitHub o grandes proveedores de nube, podrían haberlo descubierto por casualidad