Generalmente cuando uno visita un sitio como el del banco, o alguno otro donde uno requiera hacer una operación comercial con tarjetas de crédito o entregue información personal, uno debería verificar que el certificado SSL del sitio visitado es auténtico.
Aunque la realidad de que la mayoría de la gente no se molesta, ni sabe qué es o cómo se hace, es fácilmente comprobable, no le quita importancia; al contrario, entrega una cárga mucho más alta a los aparatos que existen para que esos sitios sean realmente seguros para sus clientes: Las Autoridades Certificadoras, y los productores de software.
Bien, en la última BlackHat, que tiene lugar en la famosa ciudad de Las Vegas, Dan Kaminsk, investigador de IOActive, y Moxie Marlinspike, investigador independiente, presentaron dos charlas separadas cubriendo prácticamente el mismo tema.
Es un serio problema en el sistema de emisión de certificados SSL sumado a la manera en que Secuer Socket Layer está implementado en los navegadores.
“Esta es una vulnerabilidad que afecta todas las implementaciones de SSL,” dijo Marlinspike, “porque casi todos los que alguna vez han intentado implementar SSL han cometido el mismo error.”
La cosa funciona así:
Digamos que tenemos un tipo con malas intenciones que tiene su propio dominio: "tevoyahacercagar.com.ar". Este solicita un certificado a alguna CA, como VeriSign o Thawte. La CA, usando la información de Whois, le envía un eMail para que confirme que ese dominio es suyo. Ahora bien, digamos que este tipo solicita un certificado para un subdominio -cosa que es perfectamente normal y posible-, pero usando el caracter nulo \0 en la URL, como por ejemplo: "santanderrio.com.ar\0.tevoyahacercagar.com.ar". La CA le va a dar el certificado para ese subdominio porque efectivamente el tipo es dueño legítimo de "tevoyahacercagar.com.ar"
Hasta acá, todo bien. El tipo pidió un certificado para un subdominio bastante raro, poco común, y sospechoso, pero inofensivo hasta este momento.
Ahora bien, ¿qué pasa del lado del usuario? Bueno ese es el problema.
Resulta que existe una falla en l manera en que el SSL ha sido implementado en la mayoría de los navegadores. Este atacante que obtuvo el certificado para "santanderrio.com.ar\0.tevoyahacercagar.com.ar" puede engañar a los navegadores haciéndoles creer que es un certificado válido para el sitio "santanderrio.com.ar". Lo que pasa es que estos navegadores volnerables paran de mirar cualquier caracter que sige a "\0" cuando verifican el nombre de dominio que contiene el certificado del atacante.
El tema se vuelve aún más grave (sí es posible) porque un atacante puede solicitar un certificado comodín (wildcard domain), como por ejemplo:"*\0.tevoyahacercagar.com.ar". Lo cual le habilita poder fraguar cualquier sitio en internet, facilitándole un espectro casi infinito de ataques.
Respecto al tema del caracter nulo, Marlinspike dice que no habiendo una razón válida para que haya caracteres nulos en un dominio, es un misterio que las Autoridaddes Certificadores los acepten. Pero que haciendo que dejen de hacerlo no dentendrá a los que ya fueron emitidos. La unica solución es que los productores de software arreglen sus implementaciones de SSL para que verifiquen el dominio completo, sin detenerse en los caracteres nulos.
También dijo, Marlinspike, que va liberar una herramienta para aprovechar este error. Que en relidad es una versión mejorada de una herramienta que ya había publicado: SSLSniff. Lo que hace es permitir el sniffing del tráfico en un canal seguro protegido con SSL (generalmente una URL con https), de manera que pueda implementarse un ataque de man-in-the-middle. El navegador del usuario verifica el certificado enviado por SSLSniff, y creyendo que el atacante es un sitio legítimo, empieza la transmisión "segura" de datos -que pueden ser nombres de usuarios, password, números de tarjetas de crédito, detalles bancarios, o cualqueir otro dato que el usuario esté enviando-, a traves del atacante, hacia un sitio legítimo. De esta manera el atacante puede ver los datos desencriptados.
Un ataque así también puede implementarse para tomar control de las actualizaciones de Firefox o cualqueir otro software que utilize la lirería de actualización de Mozilla. Cuando la PC del usuario busca updates, SSLSniff lo intercepta y puede devolver código malicioso que es ejecutado con toda confiaza en la PC del usuario.
Firefox 3.5 es el unico navegador no vulnerable a este ataque, por ahora. Mozilla está trabajando en los parches para la rama 3.0.
Consejos para mitigar problemas:
- Migrar a Firefox 3.5 lo antes posible.
- Mantener siempre actualizado el software que se utilize.
- Siempre verificar exhaustivamente el certificado de los sitios seguros que se utilizen.
- Nunca aceptar certificados desconocidos o vencidos.
- ¡Mucha suerte!
¡Hasta la próxima!
Si te gustó esta nota, podés invitarme una cerveza en agradecimiento. Y algún día quizá pueda yo invitarte una :D
