Ha sido un duro golpe el que ha recibido nuestro querido SSL (concretamente su versión 3.0) con el descubrimiento de ésta vulnerabilidad, ya que no existe una solución de verdad al problema salvo la de no utilizar esa versión en concreto.

Ésta vulnerabilidad no provoca una denegación de servicio (DoS), ni otorga acceso de administración a los servidores vulnerables, ni se puede utilizar para eliminar archivos, sino que permite a un atacante (mediante ataques man in the middle) acceder a la información que se transmite en una conexión que hasta ese momento se pensaba que era segura y privada, sin que los interlocutores de dicha comunicación lo sepan.

Aún nos estábamos recuperando del Heartbleed y de algunas otras vulnerabilidades que se han descubierto recientemente, cuando llega Google y (mal que me pese) descubren ésta importante nueva vulnerabilidad que pone en peligro las comunicaciones que hasta ahora creíamos seguras y a salvo.

Ésta vulnerabilidad ha sido bautizada como POODLE (en inglés: caniche) por su acrónimo Padding Oracle On Downgraded Legacy Encryption.

No voy a profundizar mucho en el tema, pero para saber más o menos de lo qué estamos hablamos debemos empezar por el principio:

SSL se creó para dotar a las comunicaciones en Internet de una capa adicional de seguridad que permitiera no solo identificar a los interlocutores de dicha comunicación, sino que mediante la encriptación de esos datos, aportara la privacidad necesaria.

Vamos a poner un ejemplo centrándonos únicamente en la navegación web: si nos conectamos a una página web que NO utiliza SSL, básicamente tecleamos la URL en nuestro navegador y éste se conecta al servidor web de dicha página para mostrarnos el resultado. Toda esa transferencia de datos entre el servidor y nuestro navegador se hace sin protección, por lo que si hubiera alguien más escuchando en la red que estamos utilizando para conectarnos, podría ver lo que estamos haciendo.

Ahí es donde entra SSL, que hace que toda esa comunicación vaya encriptada y firmada mediante el intercambio de claves públicas y certificados (los cuales previamente han tenido que ser firmados por una Entidad Certificadora, lo que hace que no solo la comunicación sea segura y privada, sino que además nos garantiza que nuestro interlocutor es realmente quien dice ser).

El protocolo SSL ha ido evolucionando, como es lógico, y se ha ido revisando con el paso del tiempo, dando lugar a nuevas versiones.

Hubo un momento en el que SSL continuó evolucionando (a partir de la versión 3.0), y dió lugar a un nuevo protocolo que se denominó TLS (mucho más seguro y moderno que SSL). Pero como los grandes cambios necesitan mucho tiempo para llevarse a cabo debido a que no todo el mundo se actualiza a la misma velocidad, y sobre todo para dotar al nuevo sistema de retrocompatibilidad, cuando el servidor y el cliente (en éste caso el navegador) no se ponen de acuerdo en la negociación inicial sobre qué algoritmo utilizar para la codificación TLS o cualquier otra cosa, ambos descartan entonces la utilización de TLS y vuelven al SSL de toda la vida, que es el que ambos conocen...

Ésta vulnerabilidad únicamente afecta a la última versión de SSL (la 3.0, ya que a partir de ahí se denominó TLS), por lo que si todos los servicios en Internet funcionaran con TLS no habría ningun problema... pero como SSL sigue estando presente para aquellos casos en los que la comunicación TLS no sea posible, es muy fácil provocar manualmente uno de éstos conflictos para que la comunicación crea que hay un problema y ambos interlocutores pasen entonces a utilizar SSL v3.0.

El primer paso para explotar ésta vulnerabilidad consiste en aprovechar precisamente ésta característica del protocolo, ocasionando de forma intencionada algun error en la conexion de los protocolos seguros (como TLS 1.2, 1.1 o 1.0) para forzar así el uso de SSL 3.0 (donde está presente la vulnerabilidad).

Seguramente ésta vulnerabilidad va a ser definitiva a la hora de dar por concluido el ciclo de vida de SSL (que ya tiene más de 15 años) ya que si bien es cierto que Poodle afecta únicamente al modo CBC (cifrado por bloques), y SSL permite también el cifrado por flujo (RC4), precisamente el año pasado se demostró que éste último método era vulnerable y un atancante podía obtener partes de un mensaje cifrado con éste método si éstas partes se repetían con cierta frecuencia (por ejemplo, una cookie de sesión en una cabecera HTTP). Por lo tanto, ya no quedan excusas para dar el salto definitivo a TLS y abandonar el uso de SSL (que ya se ha ganado de sobra la jubilación).

¿Cómo se podría aprovechar ésta vulnerabilidad?

Para efectuar un ataque aprovechando ésta vulnerabilidad lo primero sería forzar a los interlocutores de la comunicación que queremos espiar a utilizar un protocolo no-seguro en lugar de uno seguro. Como ya he comentado, para ésto bastaría con estar en la misma red que uno de los 2 interlocutores, y mediante la técnica del hombre en el medio, introducir algunos errores en la comunicación para que ambos decidan (de forma automática, obviamente) dejar de usar TLS y comenzar a utilizar SSL en dicha comunicación.

Dado que ya he dicho que el método de cifrado por flujo se considera inseguro desde hace más de 1 año, podemos suponer que el sysadmin del servidor web al que se está conectando nuestra víctima ya ha configurado dicho servidor para que no utilice ese método, por lo que lo normal será que la conexión esté utilizando el cifrado por bloques, que es precisamente el afectado por Poodle (y sino, tampoco hay problema... porque entonces podemos utilizar la otra vulnerabilidad ya conocida del cifrado por flujo).

En cualquiera de los 2 casos, el atacante podría entonces obtener partes de la conversación... lo cual es especialmente peligroso si esa parte es (por ejemplo) la cookie de sesión (o el usuario/contraseña) del servicio que está utilizando nuestra víctima en ese momento ya que podríamos suplantar su identidad, entrar en su cuenta, etc, etc.

¿Cómo podemos protegernos?

Por desgracia en éste caso el método más efectivo para no tener problemas con éste protocolo inseguro es no utilizarlo, y para eso basta con que los sysadmins configuren sus servidores para que NO utilicen el protocolo SSL si hay algun error en la comunicación TLS. De esa forma, un atacante no podría forzar nuestra comunicación segura para que utilice un protocolo inseguro.

Pero como no podemos esperar a que todos los sysadmins del mundo hagan su trabajo inmediatamente (porque algunos de nosotros estamos MUY ocupados con cosas mucho más importantes, como por ejemplo escribir éste artículo en éste grandioso blog), podemos tambien como usuarios configurar nuestros navegadores igualmente para que tampoco utilicen SSL si la comunicación con TLS falla (al fin y al cabo, la comunicación es cosa de 2: servidor y cliente).

Vamos primero a ver cómo configurar nuestro servidor web para hacer eso:

Lo primero de todo es comprobar que estamos afectados, ya que quizás el servidor web que estamos utilizando YA está configurado de forma que no permite la utilización de protocolos anteriores a TLS, por lo que podemos utilizar cualquiera de éstas 2 webs para comprobarlo:

  • http://poodlebleed.com/server.php
  • https://www.tinfoilsecurity.com/poodle

Solo tenemos que poner la URL de nuestro servidor, y nos dirá si podemos estar afectados por Poodle o no.

Y no os preocupeis si lo estais, ya que es MUY sencillo solucionarlo:

Apache HTTPd server

Basta con incluir ésta linea en la configuración del servidor para obligar a Apache a NO utilizar las versiones antiguas del protocolo:

SSLProtocol All -SSLv2 -SSLv3

Y reiniciar el servicio (sudo service apache2 restart).

Nginx

También es muy sencillo hacerlo en Nginx, basta con incluir ésta linea en su configuración:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Y reiniciar el servicio (sudo service nginx restart).

Lighttpd

En versiones posteriores a la 1.4.28, no hay problema en configurar Lighttpd para que NO utilice SSLv2 ni SSLv3, pero en las versiones anteriores únicamente se puede deshabilitar el uso de SSLv2.

Por tanto, en éste servidor habría que editar el archivo /etc/lighttpd/lighttpd.conf y añadir las siguientes lines después de la directiva ssl.engine = "enable":

ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"

Y reiniciar el servicio (sudo service lighttpd restart).

Todos los servicios que usen SSL se ven afectados por éste problema, por lo que aparte de los servidores web se puede explotar ésta vulnerabilidad (aunque es más complicado) en muchos otros servicios, como Postfix, Sendmail, Courier, Dovecot, OpenVPN, etc. Si quieres ver cómo securizar también éstos servicios, aquí puedes ver detalladamente varios de ellos.

Pero, ¿y si los sysadmins de los servidores web a los que os conectais habitualmente NO han leído aún éste maravilloso artículo de pornoHARDWARE.com, y aún no han actualizado sus servidores? No hay problema, ya que como dije antes, la comunicación es cosa de 2, así que si no tenemos control sobre el servidores al que nos conectamos, debemos configurar el cliente que se va a conectar a ese servidor (es decir, nuestro navegador):

Firefox / Iceweasel

Si usais éste genial navegador, solo teneis que acceder a la configuración avanzada de propiedades. Para hacer ésto, basta con abrir una nueva pestaña del navegador, y teclear about:config en la barra de direcciones.

Una vez hayamos hecho eso, solo tenemos que buscar la propiedad security.tls.version.min y poner su valor a 1.

Hay que reiniciar el navegador para cerrar las conexiones SSL que tuviéramos abiertas en ese momento, para que al abrirse de nuevo lo hagan utilizando el valor de la propiedad que acabamos de configurar.

Google Chrome / Chromium (Linux únicamente)

Tanto si usais Chromium como si utilizais el asqueroso, intrusivo y deleznable (aunque rápido, hay que reconocerlo) navegador de la empresa cuyo nombre no diré aquí, debeis editar el archivo que se usa para lanzar la aplicación, y editar todas las lineas que comiencen por Exec= para incluir la opción --ssl-version-min=tls1.

Dependiendo de su usais Chrome o Chromium éstos archivos pueden ser:

  • /usr/share/applications/google-chrome.desktop
  • /usr/share/applications/chromium.desktop

Por ejemplo:

[Desktop Entry]
Version=1.0
Name=Chromium Web Browser
GenericName=Web Browser
Comment=Access the Internet
Exec=/usr/bin/chromium --ssl-version-min=tls1 %U
Terminal=false
X-MultipleArgs=false
Type=Application
Icon=chromium
Categories=Network;WebBrowser;
MimeType=text/html;text/xml;application/xhtml_xml;x-scheme-handler/http;x-scheme-handler/https;
StartupWMClass=Chromium
StartupNotify=true

Al igual que antes, debemos reiniciar el navegador para cerrar las conexiones SSL que tuviéramos abiertas en ese momento.

Apple Safari

Según leo en Internet, el nuevo sistema operativo de Apple lanzado la semana pasada (Yosemite) ya está protegido contra ésta vulnerabilidad, y para las versiones anteriores (Mavericks y Mountain Lion) el problema está también solucionado si aplicais la actualización 2014-005 que salió hace 3 dias (17/Oct/2014), así que es bastante sencillo solucionar el problema si sois usuarios de la manzana...

Internet Explorer

Estás de coña, no? Obviamente ni se cómo solucionar éste problema en Explorer, ni me importa lo más mínimo! ;)

Así que lo dicho, esto es todo, amigos... espero que éste artículo os haya resultado útil, y todos podamos seguir disfrutando de la poquita privacidad que nos queda...

Alaaaaaaaaaaaaaaaaaaa

Edito el 12/Dic/2014: Parece que POODLE no solo afecta a SSL, sino que se ha descubierto que hay versiones de TLS que también se ven afectadas por ésta vulnerabilidad!

Referencias