Publicidad
Publicidad

RSS OpenSSL

Primero fue Apple con el goto fail, un fallo que permitía interceptar y descifrar tus conversaciones seguras. Después vino GnuTLS, una librería de SSL para Linux, con un fallo que daba por válidos todos los certificados de un tipo concreto. Por si no teníamos suficiente con eso, hoy tenemos otro fallo extremadamente grave (mucho peor que los anteriores) en la librería OpenSSL.

OpenSSL es una librería ampliamente usada en el mundo del desarrollo para implementar SSL/TLS. Por ejemplo, el servidor Apache la usa para establecer conexiones HTTPS sin tener que preocuparse de los detalles de implementación. Servidores de correo, chat o redes privadas virtuales (VPNs) son otros servicios que suelen usar esta librería.

Qué ha fallado

El fallo está en una función encargada de gestionar mensajes Heartbeat. Estos mensajes son llamados keep-alive: es una forma de decirle al servidor que sigues conectado y que no cierre la conexión. El mensaje que mandes puede tener una carga o contenidos (payload), como pueda ser la fecha en la que se ha enviado. El servidor recibe ese mensaje y responde al cliente con esa misma carga. Este tipo de esquema "te paso algo y me respondes con lo mismo" no es exclusivo de TLS: en los paquetes de ping, por ejemplo, también se pueden incluir datos para así calcular cuánto tarda el servidor en responder.

El cliente tiene que decir también qué longitud tiene esa carga, para que el servidor la pueda leer sin tener que adivinar dónde acaba. Y aquí es donde vienen los problemas. ¿Qué pasa si le digo al servidor que le estoy enviando mil bytes y en realidad sólo le estoy enviando uno?

Si habéis programado alguna vez en lenguajes de alto nivel, como Java, C# o JavaScript, pensaréis que eso fallará. Al fin y al cabo, estamos intentando acceder a cosas que no están ahí. Si mi paquete es una lista de bytes de longitud 10 y quiero leer el 20978, no tengo de dónde sacarlo y el programa debería pararse y reportar un fallo.

Pero OpenSSL está escrito en C, y en C las cosas no son tan felices. En este lenguaje, la variable "paquete" no es más que una dirección en la memoria RAM; por ejemplo, la 1076. El primer byte del paquete está en la posición 1076, el segundo en la 1077, el tercero en la 1078 y así sucesivamente.

Cuando se esté ejecutando un ataque, OpenSSL recibe un mensaje de longitud 10 (por ejemplo), que dice que tiene 200 bytes de carga y que almacena en la posición 1076. Cuando tenga que responder, empezará a copiar el byte 1076, el 1077, el 1078... así hasta el 1086. ¿Qué ocurre después? Fácil: OpenSSL sigue. A él le han dicho que hay 200 bytes (el código no verifica si la longitud que aparece en el paquete es incorrecta) y va a copiar sus 200 bytes. Es decir, seguirá leyendo y copiando hasta que llegue a la posición 1276.

¿Y qué hay en esas posiciones? Pues sorpresas. La reserva de memoria no es determinista así que puede haber absolutamente de todo. Quizás sólo hay basura, restos del paquete anterior - así es como se comprueba si un servidor es vulnerable - o la clave privada del servidor.

Repitiendo muchas veces el ataque - cada vez se pueden recuperar hasta 64 KB de la memoria del servidor - es probable que se acaben encontrando cosas de valor. Además, las estructuras más valiosas, como las claves privadas que comentábamos, son relativamente fáciles de encontrar cuando están guardadas en memoria. En resumen, es un fallo muy grave, una ventana abierta a los entresijos confidenciales de OpenSSL.

¿En qué me afecta a mí este fallo?

Vamos ahora a la parte práctica: en qué nos afecta esto a nosotros cómo usuarios. El fallo hace especialmente vulnerables a los servidores, así que en teoría no deberíamos preocuparnos, ¿no?

La realidad es que no. Heartbleed permite a los atacantes conseguir claves privadas de servidores, con las que podrían realizar ataques MITM. Repasemos HTTPS: si un atacante tiene la clave de Google (por ejemplo), podría montar un servidor que se hiciese pasar por legítimo de Google. Tu navegador se conectaría a él y no te darías cuenta, de tal forma que en lugar de enviar tus datos confidenciales (correos, contraseñas, usuarios...) a Google, lo harías al atacante. Fantástico, ¿verdad?

Estaríamos hablando de miles de servidores potencialmente comprometidos. La vulnerabilidad se introdujo hace dos años, y no se sabe si alguien la ha estado explotando en secreto antes de que sea publicada. De hecho, la recomendación es que se revoquen los certificados SSL y se distribuyan otros nuevos por si han sido comprometidos.

Estamos ante uno de los fallos más graves en SSL que se hayan visto.

¿Asusta? Pues todavía queda más. Hemos dicho que el fallo permite ver pedazos de la memoria del servidor. ¿Se puede ver algo más que las claves privadas? ¿Qué pasa si hay otros usuarios conectándose al servidor?

Lo que pasa es que se puede obtener información que permita robarles la sesión directamente. Los servidores de Yahoo!, por ejemplo, filtraban información de usuarios y contraseñas de sus propios usuarios. En texto plano. Sin ningún tipo de protección. Cualquiera podía ejecutar un comando en su ordenador y empezar a ver cómo aparecían contraseñas (ya han arreglado el fallo).

Entre la facilidad para explotar la vulnerabilidad, el número de servicios afectados y el hecho de que el ataque no deja rastros en los registros, este es uno de los fallos más graves que se hayan visto en SSL. Un verdadero caramelo para los black hat hackers. Por nuestro bien, más nos vale que este fallo no lo haya descubierto nadie antes.

¿Cuándo estará arreglado?

La corrección en OpenSSL ya está lista, y varias distribuciones de Linux tienen los paquetes listos para actualizar. La versión con el fallo corregido es OpenSSL 1.0.1g. Las versiones vulnerables van desde la 1.0.1 hasta la 1.0.1f (versiones anteriores no tenían Heartbeat implementado).

Servicios como Heroku, Amazon Web Services o Lastpass han anunciado la corrección del error en sus servidores. Podéis probar qué servidores son vulnerables con un simple test disponible en la web.

Más información | Existential type crysis | Heartbleed | Corrección del fallo en Git | OpenSSL Advisory

BoringSSL es otro fork de OpenSSL, pero este viene de la mano de Google

9 Comentarios
BoringSSL es otro fork de OpenSSL, pero este viene de la mano de Google

Hace un par de meses, a raíz del descubrimiento de todo el asunto de Heartbleed os hablamos de LibreSSL, todo un borrón y cuenta nueva que nació por pérdida de confianza en OpenSSL el proyecto original. Pues a LibreSSL ahora se une BoringSSL, un fork de OpenSSL iniciado por Google, que parece también querer aportar su granito de arena.

La intención de Google, en principio, no es competir con OpenSSL ni con LibreSSL, y de hecho Google ha aportado el sueldo de dos desarrolladores a tiempo completo para trabajar en corregir los errores en OpenSSL. En términos de desarrollo, a la larga les resulta más cómodo mantener su propio fork de OpenSSL (e importar cambios de OpenSSL y LibreSSL) que estar reaplicando sus parches para cada nueva versión del proyecto original.

Leer más »

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

18 Comentarios
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.

Leer más »
Publicidad

Los gigantes tecnológicos financiarán a OpenSSL para que algo como Heartbleed no se repita

6 Comentarios
Los gigantes tecnológicos financiarán a OpenSSL para que algo como Heartbleed no se repita

Tras todos los problemas que ha acarreado el fallo crítico de seguridad en OpenSSL llamado Heartbleed, hay una cosa que ha quedado clara en los consejos de administración de todas las compañías: algo así no puede volver a ocurrir. Y es por eso que los principales gigantes tecnológicos han decidido financiar el proyecto OpenSSL.

The Linux Foundation, por ejemplo, dedicará 3,9 millones de dólares durante tres años a varias iniciativas de código abierto con OpenSSL en primer lugar. Otras compañías (Amazon, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Qualcomm, Rackspace y VMWare) han prometido donar cien mil dólares al año como mínimo.

Teniendo en cuenta que hasta ahora OpenSSL lo ha estado manteniendo un sólo programador trabajando a jornada completa y con un apoyo en donaciones de 2.000 dólares al año, estas aportaciones mejorarán con toda seguridad la fiabilidad de OpenSSL. O como mínimo liberar de trabajo a ese pobre programador con más personal de apoyo. De todas formas, las donaciones han empezado a aumentar por sí solas en cuanto todo el mundo se ha dado cuenta de la gravedad de Heartbleed.

Vía | Ars Technica
Imagen | Stephan Van Es
En Genbeta | LibreSSL, borrón y cuenta (casi) nueva para mejorar la seguridad de OpenSSL

Leer más »

LibreSSL, borrón y cuenta (casi) nueva para mejorar la seguridad de OpenSSL

16 Comentarios
LibreSSL, borrón y cuenta (casi) nueva para mejorar la seguridad de OpenSSL

Un fenómeno habitual en el mundo de la seguridad, especialmente en el software libre, es el del descubrimiento en cascada de vulnerabilidades. Pasó hace un tiempo con Rails (un framework de desarrollo web) y ha pasado ahora con OpenSSL. Se descubre una vulnerabilidad grave que llevaban meses o incluso años ocultas, lo que llama la atención de investigadores que exploran más a fondo ese software y acaban descubriendo vulnerabilidades adicionales.

Después del descubrimiento de Heartbleed, los desarrolladores de OpenBSD, un sistema operativo tipo Unix, empezaron a explorar el código de OpenSSL. Lo normal suele ser que se descubran más vulnerabilidades y se reporten. En este caso no ha sido así: han visto fallos tan flagrantes y un código tan malo que han decidido directamente hacer un fork: LibreSSL.

Leer más »

Heartbleed, otro fallo extremadamente grave en una librería SSL

24 Comentarios
Heartbleed, otro fallo extremadamente grave en una librería SSL

Primero fue Apple con el goto fail, un fallo que permitía interceptar y descifrar tus conversaciones seguras. Después vino GnuTLS, una librería de SSL para Linux, con un fallo que daba por válidos todos los certificados de un tipo concreto. Por si no teníamos suficiente con eso, hoy tenemos otro fallo extremadamente grave (mucho peor que los anteriores) en la librería OpenSSL.

OpenSSL es una librería ampliamente usada en el mundo del desarrollo para implementar SSL/TLS. Por ejemplo, el servidor Apache la usa para establecer conexiones HTTPS sin tener que preocuparse de los detalles de implementación. Servidores de correo, chat o redes privadas virtuales (VPNs) son otros servicios que suelen usar esta librería.

Leer más »

Lanzado OpenSSL 1.0.0

3 Comentarios
Lanzado OpenSSL 1.0.0

OpenSSL es una herramienta básica para aquellas aplicaciones que utilizan funciones criptográficas. El pasado lunes, casi 11 años después de iniciarse el proyecto vió la luz la versión 1.0.0.

El proyecto OpenSSL es una iniciativa open source que ha dado lugar a un completo paquete de herramientas de administración y librerías con funciones criptográficas que son utilizadas por distintos programas: navegadores web, servidores con certificados digitales como Apache o el software OpenSSH.

Leer más »
Publicidad
Publicidad
Inicio
Inicio

Ver más artículos