Se descubren todavía más vulnerabilidades graves en OpenSSL

Resulta curioso como, en cuestión de meses, la imagen que teníamos de OpenSSL como un producto que garantizaba nuestra seguridad en Internet se ha desvanecido. Después de Heartbleed surgieron varias iniciativas para "asegurar" la librería. El equipo de OpenBSD, por ejemplo, se puso a trabajar en el _fork_ LibreSSL para tratar de purgar todos los fallos de la librería original. Otros investigadores han buscado más fallos directamente en el código, y han descubierto varias vulnerabilidades más que acaban de ser corregidas.

La primera, la más grave, permitiría a un atacante ejecutar un ataque _man-in-the-middle_ y leer los datos de una conexión segura. Lo único que necesitaría es inyectar un mensaje durante el proceso de apretón de manos o presentación (_handshake_) entre los dos clientes que estén estableciendo una conexión segura.

¿En qué consiste la vulnerabilidad?

El _handshake_ es el proceso que llevan a cabo los clientes para establecer una conexión segura. Como vimos cuando hablamos de HTTPS, primero se intercambian las claves públicas, cifrado a usar y algunos números que se usarán después para generar las claves de cifrado de la conexión. Casi al final del _handshake_, cada cliente envía un mensaje de tipo _ChangeCipherSpec_ (CCS), que a grandes rasgos significa "Ahora todo va cifrado".

Cuando OpenSSL recibe ese mensaje, calcula las claves de cifrado a partir de las preclaves que se hayan intercambiado servidor y cliente. Por aquí ya podéis intuir por dónde viene el problema: ¿qué pasa si el mensaje CCS se envía antes de tiempo, antes de que los clientes se han intercambiado las preclaves?

Un mensaje antes de tiempo provoca que OpenSSL use una clave débil para cifrar los datos

Lo normal sería que fallase y se rechazase ese paquete, o incluso se cerrase la conexión entera. Pero eso no es lo que ocurre. OpenSSL recibe el mensaje sin problemas y calcula la clave de cifrado. Esa clave tiene dos peculiaridades: está calculada únicamente a partir de datos públicos y además no se modifica cuando el cliente reciba por segunda vez el mensaje CCS. En resumidas cuentas: el atacante puede calcular también la clave de cifrado y ver qué se está transmitiendo.

Lo más peculiar de todo es que el fallo lleva 16 años en OpenSSL y no se ha corregido a pesar de que ya se descubrieron y corrigieron vulnerabilidades relacionadas con el orden en el que se recibía el mensaje CCS, según el descubridor de la vulnerabilidad Masashi Kikuchi.

Esta no es la única vulnerabilidad que se ha corregido, pero sí la más grave. Hay varias vulnerabilidades de denegación de servicio (el cliente OpenSSL se cuelga y deja de responder, o directamente se cierra inesperadamente) y dos que permitirían a un atacante ejecutar código aleatorio.

¿Cómo me afecta a mí el fallo?

Por suerte, para el usuario normal este problema no es especialmente grave. Para que se pueda llevar a cabo el ataque, es necesario que tanto servidor como cliente usen una versión de OpenSSL vulnerable. Sin embargo, la mayoría de navegadores web no usan OpenSSL, salvo Chrome para Android (y ya hay una actualización disponible en Play Store).

Sí podrían ser vulnerables conexiones entre servidores, o conexiones con clientes de VPN que usen OpenSSL. Por suerte, el parche ya ha sido distribuido y ya se puede actualizar en la mayoría de distribuciones Linux.

Más información | OpenSSL Advisory | How I Discovered CCS Injection Vulnerability | Análisis Adam Langley
Imagen | Intel Free Press