16 oct. 2014

Poodle: vulnerabilidad en SSL 3.0 y cómo te podría afectar

Por Josep Albors

Sin duda 2014 está siendo un año muy movido en lo que respecta a vulnerabilidades. Muchas de ellas en los propios cimientos de los sistemas y los protocolos de comunicaciones de la Internet actual.
Si hace unos meses hablábamos de Heartbleed y no hace mucho de Shellshock, hoy toca hablar de Poodle. Esta grave vulnerabilidad afecta al protocolo de comunicación SSL 3.0 que ha sido publicada por investigadores de Google.

Los ingenieros que encontraron a Poodle (nombre que recibió la vulnerabilidad) son Bodo Möller, Thai Duong y Krzysztof Kotowicz, ingenieros del equipo de seguridad informática en Google. El nombre Poodle fue dado por su significado en inglés Padding Oracle On Downgraded Legacy Encryption.

Como la mayor parte de la información publicada hasta el momento es muy técnica, hemos decidido publicar este artículo enfocándolo a todas aquellas personas que se han despertado oyendo hablar de Poodle, pero que no saben qué es ni cómo les afecta en su día a día. Empecemos por el principio:

¿Qué es SSL 3.0?

SSL 3.0 fue la última revisión del protocolo de comunicación seguro SSL (“Secure Sockets Layers” por sus siglas en inglés y “Capa de Conexión Segura” en español) antes de que evolucionara y pasara a denominarse TLS (y de paso, empezar de nuevo con la versión 1.0). Su función principal es permitir el envío de claves de cifrado entre las aquellas aplicaciones que lo implementen, de manera que se establezca una conexión segura entre ellas que no pueda ser espiada.

Por ejemplo, si queremos conectarnos a nuestro banco para realizar operaciones online, lo normal es que nuestro navegador solicite una conexión segura y la web de nuestro banco nos la proporcione. De esa forma, nadie debería poder acceder a nuestro usuario y contraseña mientras estamos conectados, por ejemplo desde una red Wi-Fi compartida con otros usuarios.

Actualmente, la mayoría de aplicaciones (especialmente los navegadores web) están configuradas para utilizar SSL y TLS. No obstante, quien decide si una conexión es segura no es la web o el navegador, sino una entidad certificadora que se encarga de garantizar que esa conexión es segura mediante un certificado de seguridad.

Cuando hablamos de Heartbleed hace unos meses, nuestro compañero Fernando de la Cuadra publicó un artículo explicando de forma sencilla qué es y cómo funciona SSL, por lo que recomendamos encarecidamente su lectura.

A día de hoy, en realidad casi todas las conexiones a sitios "conocidos" o la gran mayoría de servidores y clientes se efectúan en TLS. Ahora depende de los actuales sistemas o software soportar una versión u otra de TLS. SSL, en porcentajes 0.3%, no es un protocolo muy usado, pero está ahí, latente, soportado y preparado para actuar cuando ambas partes no se ponen de acuerdo con TLS. Y ese es el problema que los investigadores proponen como caso de uso de la vulnerabilidad.

¿Cómo funciona Poodle?

La vulnerabilidad descubierta por los investigadores de Google es diferente a Heartbleed, ya que no afecta a la parte servidor (que alojan, por ejemplo, páginas webs), sino a la parte cliente (navegadores de Internet, clientes de correo, etc.), lo que la hace menos grave y fácil de solucionar.

Básicamente consiste en aprovecharse de una característica que hace que, cuando un intento de conexión segura falla, se proceda a intentar realizar de nuevo esa conexión pero con un protocolo de comunicación más antiguo. De esa forma, un atacante podría ocasionar intencionadamente errores de conexión en protocolos seguros como TLS 1.2, 1.1 y 1.0 y forzar así el uso de SSL 3.0 para aprovechar la nueva vulnerabilidad.

Poodle basa su ataque sobre el modo CBC (Cifrado por bloques) lo que hace que este modo sea vulnerable a un ataque variante de Padding Oracle. La alternativa a CBC es usar un cifrado por flujo, RC4, pero este último ya fue condenado al destierro. En marzo de 2013 se publicó un ataque que permitía recuperar componentes de un mensaje cifrado con RC4 si estos componentes se repetían con cierta frecuencia. Pensemos en una cookie de sesión dentro de un mensaje HTTP.

Podríamos decir que Poodle no está orientado a "hackear" nuestro sistema, sino que, a través de ataques MitM busca obtener la información que antes se enviaba cifrada y un atacante no podía descifrar.

¿Cómo se explota esta vulnerabilidad?

Como vemos, es un ataque en dos tiempos. Primero se fuerza el uso de un protocolo no seguro y luego se aprovecha una vulnerabilidad en él. No obstante, para poder realizar este ataque se han de cumplir una serie de condiciones, y es que el atacante ha de estar conectado a la misma red que la víctima, por ejemplo, en una red Wi-Fi pública, para poder realizar lo que se conoce como un ataque de "hombre en el medio" e interceptar así las comunicaciones de la víctima.

Además, para realizar un ataque de este tipo se requiere que JavaScript se esté ejecutando en el navegador, algo bastante común pero que puede desactivarse fácilmente. Esto limita su alcance, ya que si bien la mayoría de navegadores utilizados en sistemas operativos para ordenadores de sobremesa o portátiles incorporan JavasScript, no es el caso en muchos dispositivos móviles y sus aplicaciones.

Imaginemos una red local, una víctima, sus secretos más codiciados y un atacante. La víctima se conecta a su banco, el atacante efectúa un hombre en el medio, se mete en la conversación del cliente con el banco y decide "estorbar" lo suficiente como para que el navegador de la víctima y el servidor del banco se cansen de negociar que versión de TLS y con el lio terminen usando SSL.

Ahora que se está usando CBC como cifrado, debido entre otras cosas porque en una auditoría al banco le dijeron que se abstuviese de soportar RC4, el atacante solo tiene que capturar una buena cantidad de paquetes para que mediante un análisis comience a obtener "piezas" de esa conversación privada y haga trizas la privacidad.

¿Qué puede hacer un atacante que explote esta vulnerabilidad?

Sobre el papel y aún a falta de conocer más detalles en el futuro, se puede utilizar Poodle para realizar una amplia variedad de ataques, pero quizá el más llamativo y que más puede afectar a los usuarios sea el secuestro de nuestras cookies de sesión o, lo que es lo mismo, conseguir registrarse en nuestra cuenta de cualquier servicio online (correo, redes sociales, banca online, etc.) sin necesidad de obtener previamente nuestro usuario y contraseña.

De esta forma se podrían realizar robos de identidad y publicar mensajes en redes sociales en nuestro nombre, enviar correos sin nuestro permiso o realizar transferencias bancarias, aun sin haber obtenido nuestro usuario y contraseña. Este es el peligro más inmediato que se nos viene a la cabeza.

¿Existe alguna solución?

Una vez ya hemos visto en qué consiste Poodle y cómo puede ser utilizada por un atacante, es hora de hablar de las posibles soluciones. Para ello hay que tener en cuenta que Poodle solo afecta a versiones antiguas de SSL (y SSL 3.0 tiene ya 15 años) y por eso trata de forzar este tipo de conexiones aunque tengamos nuestras aplicaciones configuradas para que utilicen la más reciente: TLS 1.2.

Por eso, una de las mejores soluciones pasa por dejar de utilizar SSL 3.0 y todas sus versiones anteriores y usar solo TLS 1.0 y posteriores. De esta forma no se podría forzar que tanto el cliente como el servidor utilicen una versión insegura del protocolo.

Dejar de utilizar SSL 3.0 en los servidores es una tarea que llevará tiempo, debido a que aún quedan muchos usuarios que utilizan aplicaciones que no soportan versiones posteriores a 3.0. Pensemos en los millones de usuarios que aún siguen utilizando Internet Explorer 6.0, por ejemplo. Sin embargo, es algo que se va a tener que hacer tarde o temprano, y algunas de las empresas más importantes encargadas de alojar un buen número de sitios web ya han anunciado que dejarán de soportar SSL 3.0 en breve. Además, Google aconseja habilitar el mecanismo TLS_FALLBACK_SCSV en servidores para evitar que un atacante produzca errores de conexión al usar el protocolo TLS y fuerce el uso de SSL 3.0.

No obstante, como usuarios podemos evitar seguir usando SSL 3.0 en los navegadores de forma sencilla. Es muy probable que la mayoría de navegadores más utilizados saquen una actualización en breve que obligue a utilizar cifrado TLS 1.0 o posterior, pero también podemos forzarlo de forma manual siguiendo estas instrucciones:

Mozilla Firefox: si escribimos about:config en la barra de direcciones de nuestro navegador Firefox, entraremos a un apartado de configuración donde podremos cambiar muchos parámetros de configuración. Es importante no tocar nada si no sabemos lo que estamos haciendo y dirigirnos únicamente a la siguiente línea:
security.tls.version.min
Una vez hayamos localizado esta línea, haremos doble clic sobre ella y cambiaremos el valor de 0 a 1, cerrando esa pestaña una vez hayamos realizado el cambio.

Google Chrome: para forzar el uso exclusivo de TLS en Chrome, deberemos primero cerrar el navegador e ir al icono de acceso directo que tendremos en el escritorio y pulsar el botón derecho del ratón sobre él. Seleccionaremos la opción "Propiedades" y en la pestaña "Acceso Directo" nos colocaremos sobre el campo "Destino". 
Es en ese campo donde deberemos añadir, al final de la ruta donde se encuentra el ejecutable de Chrome, la siguiente cadena:
-ssl-version-min=tls1
Internet Explorer: desactivar SSL en las opciones avanzadas del navegador.
Tras realizar estos cambios no deberíamos observar ningún cambio mientras navegamos, puesto que prácticamente todos los servidores están preparados para utilizar TLS 1.0 o posterior, aunque si no nos vemos capacitados para realizar estos pasos, siempre podemos esperar a que los propios navegadores se actualicen y activen esta opción por nosotros.
Conclusión

Esta vulnerabilidad debería servir como una llamada de atención para dejar de utilizar un protocolo obsoleto que se desarrolló hace 15 años y que no está pensado para hacer frente a los desafíos de seguridad de hoy en día. Es por eso que esperamos una rápida reacción por parte de los desarrolladores de aplicaciones que todavía hacen uso de SSL 3.0 y que implementen el uso exclusivo de TLS, algo que solucionaría este problema de forma efectiva y sencilla.

Más información:


Actualización: Debida a esta vulnerabilidad, Mozilla tiene previsto desactivar la cifrado Secure Sockets Layer en su navegador Firefox 34, que será lanzado el 25 de noviembre.

Fuente: Protegerse e Hispasec

2 comentarios:

  1. ¿La configuracion para chrome si les funciona?

    ResponderEliminar
  2. Buenos dias, veo que aun no agregan la cadena correcta para deshabilitarlo en google chrome.

    ResponderEliminar

Gracias por dejar un comentario en Segu-Info
Si vas a dejar una consulta, procura tener habilitado tu perfil en Blogger o deja una forma de contacto.

Gracias por comentar!