Vulnerabilidad POODLE SSLv3

Esta semana toca escribir sobre la vulnerabilidad de SSLv3 llamada POODLE (Padding Oracle On Downloaded Legacy Encryption). Existe muchísima información en Internet de cómo se puede llegar a descifrar una sesión SSL utilizando la vulnerabilidad del protocolo que aprovecha la manera que el cifrado por bloques CBC es implementado dentro de SSLv3.

El protocolo de cifrado SSLv3 fue diseñado hace 18 años para proporcionar comunicaciones seguras en Internet. Aunque la mayoría de aplicaciones soportan el protocolo TLS, siendo este mucho más robusto, aún muchos servicios y navegadores soportan SSLv3.

¿Qué dispositivos son vulnerables?

Todas las aplicaciones, navegadores y servidores que soporten SSLv3.

¿Cuál es exactamente la vulnerabilidad?

La vulnerabilidad está basada principalmente en dos fallos de SSLv3:

• SSLv3 genera bytes de relleno de manera aleatoria.
• El Message Authentication Code (MAC) calculado para comprobar la integridad de cada mensaje después del cifrado no incluye estos bytes de relleno.

Por lo tanto, estos bytes de relleno pueden ser modificados mediante un ataque Man In The Middle sin ser detectado por el cliente ni el servidor.

¿Es una vulnerabilidad importante?

Aunque se necesita realizar un MITM para explotar la vulnerabilidad, sí que se considera importante por la cantidad de aplicaciones y servicios que están expuestos, ya que la mayoría de navegadores (Chrome, Firefox, IE) soportan SSLv3, además de que la mayoría de sitios web HTTPS también soportan SSLv3.

¿Debería estar preocupado?

Teniendo en cuenta que para explotar la vulnerabilidad el atacante debe encontrarse en la misma red que la víctima, la ejecución satisfactoria del ataque tiene unas necesidades muy específicas que sitúan la vulnerabilidad por detrás de otras, como por ejemplo Heartbleed.

¿Cómo puedo prevenir el ataque?

Hay dos maneras para prevenir el ataque. Es suficiente con deshabilitar el soporte de SSLv3, o los modos de CBC con SSLv3, en los servidores web y en los navegadores y aplicaciones de clientes, sin embargo esto puede presentar problemas de compatibilidad. La otra alternativa es soportar TLS_FALLBACK_SCSV. Este último mecanismo resuelve el problema de los re-intentos de conexión fallidos que puede provocar un atacante para forzar a los navegadores a utilizar SSLv3. Y por tanto también previene el downgrade de TLS 1.2 a TLS 1.1, además de que puede ayudarnos a prevenir futuros ataques.

Esta última vulnerabilidad, además de hacernos trabajar a todos los ingenieros de seguridad para mitigarla lo antes posible, parece ser que puede ser la punta del iceberg tras Heartbleed para que fabricantes de software dejen de soportar el protocolo SSLv3 y trabajen exclusivamente con TLS.

Un saludos amigos!