Este artículo lo creo para intentar reunir toda la información relacionada con el último grave fallo de seguridad de Debian, obviamente en español, y por supuesto que desde el mismo día que se publicó el fallo, nuestros servidores empezaron a pasar por el aro y se regeneraron todas las putas claves ssl… Correo, Web, ssh, vamos trabajo a saco para quienes tengan muchos sitios; nosotros para nuestra desgracia somos muchos para pocas máquinas… 
Primero de todo el aviso de fallo de seguridad de Debian que abrió la caja de los truenos… En él más o menos nos comentan que el generador de números aleatorios de openssl es predecible… El descubridor, Luciano Bello, revisando código de los fuentes de Debian concretamente el código de openssl; comprobó que no se estaba generando mucha entropía al crear las claves ssl. Y eso en qué nos afecta.
Pues muy sencillo; primero comentar que este pequeño cambio pedido por valgrind ha sido el causante de desatar una tormenta perfecta. Como se puede apreciar aquí todo se inició por el uso de una zona de memoria no inicializada como base para aumentar la entropía a la hora de generar claves ssl. Los de Valgrind se quejaban de que les aparecían demasiados warnings (obviamente este #ifndef PURIFY tiene algo que ver, es del debugger de IBM) y no les parecía correcto por tanto se realizó una pregunta de si comentando esas líneas pasaba algo y se llevó a cabo el cambio.
MD_Update(&m,buf,j);
[ .. ]
MD_Update(&m,buf,j); /* purify complains */
Una vez realizado el cambio, el proceso de OpenSSL PRNG dejó de obtener una fuente de entropía y se redujo el número de posibles semillas para generar operaciones PRNG a 32768, que es por defecto el número de
proceso más alto que genera el sistema. Valor por cierto increíblemente pequeño para algo que necesita mucha entropía, debido a la cantidad de semillas que se suelen generar en un servidor. Para aquellos que quieran profundizar más, esta explicación es bastante completa (english).
Como una imagen vale más que mil palabras dos tiras cómicas son las que mejor definen el resultado de ese pequeño cambio.
Una vez evaluado el fallo y corregido; vinieron los daños colaterales inherentes al fallo.
Todo programa relacionado con openssl está en entredicho, si se habían generado las claves ssl con etch, o algún sistema posterior. Sí, la vieja estable Sarge no está afectada, siempre y cuando las claves se hubieran generado con ella y no se hayan actualizado al hacer el upgrade a Etch. La primera versión vulnerable es la 0.9.8c-1 del 2006-09-17. Los daños se empezaron a extender a través de todo el sistema: SSH keys, OpenVPN keys, DNSSEC keys, certificados X.509 y claves de sesión para SSL/TLS…
En Etch (actual versión estable) el primer paquete correcto es la versión 0.9.8c-4etch3, que obviamente se recomienda instalar antes que respirar. Sid/Lenny tiene la versión 0.9.8g-9, están con la misma porque aún no estamos en frozen.
Por tanto qué hacer si tenemos este problema… muy sencillo en el caso de un sólo servidor ssh en el que no tengamos la entrada via clave sin contraseña:
apt-get update
apt-get upgrade
rm /etc/ssh/ssh_host_*
dpkg-reconfigure -plow openssh-server
Obviamente en el caso de que sólo usemos el ssh como cliente lo único que nos aparecerá es algo parecido a esto:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA1 host key has just been changed.
The fingerprint for the RSA1 key sent by the remote host is
f3:cd:d9:fa:c4:c8:b2:3b:68:c5:38:4e:d4:b1:42:4f.
Please contact your system administrator.
Que viene a decirnos que el administrador del sitio al que nos conectábamos ya ha regenerado la clave problemática…
En el caso de que sí tengamos la clave exportada para poder entrar en ssh remoto sin la contraseña tenemos una problema grave, pues 2^15 intento (32768), son muy pocos y como bien comentan en Phrack esto no le lleva a alguien que sepa lo que hace más de 20 minutos, problema que algún script kiddie podría darnos un susto.
Todo esto ha generado una oleada de cancelaciones de claves: Gnome, Debian, … Muchos grandes proyectos han tenido que cerrar los accesos hasta que los usuarios no envíen una clave que sí sea válida.
Además se ha preparado una Wiki Debian para ayudar a los usuarios realizar todos los pasos correctos a la hora de asegurar sus sistemas. También han puesto un nuevo programa ssh-vulnkey para poder testear la debilidad de nuestras claves.
A estas alturas existen miles de referencias en Google, yo las que he encontrado interesantes son las siguiente (lo peor es que están en inglés):
Este http://etbe.coker.com.au/2008/05/18/debian-ssh-problems/ es el blog de Russell Coker la información más interesante la he encontrado aquí. Habla de la gente de Phrack, del artículo de Metasploit dónde están las viñetas puestas en esta página y más información sobre el tema. La saca de oxtias que se ha repartido la peña en Slasdot y al final la explicación matemática de Steinar H. Gunderson de lo mejorcito.
Para los que prefieran el español dejo estos blogs KBglob y 120% Linux.
