Mostrando entradas con la etiqueta BREACH. Mostrar todas las entradas
Mostrando entradas con la etiqueta BREACH. Mostrar todas las entradas

jueves, 21 de mayo de 2015

Logjam, el hacedor de llaves en el reino de las cerraduras cobardes

Al pilar que sostiene la privacidad de nuestras comunicaciones le ha salido una nueva grieta que vuelve a amenazar la integridad y el secreto que percibimos como seguros. Un golpe a la criptografía bautizado Logjam que demuestra (otra vez) la fragilidad de un sistema vital para la confianza. Veamos en qué consiste Logjam.

https://weakdh.org/
En toda comunicación segura existe un momento crítico al principio de la conexión. Ambas partes han de ponerse de acuerdo en la clave que van a utilizar para el uso de cifrado simétrico. El problema no era sencillo, más teniendo en cuenta que el medio por el que iban a viajar los mensajes para coordinar la elección de dicha clave era y es hostil: Internet.

A mediados de los años setenta, aparte del éxito de las patillas de hacha y los pantalones de campana, unos científicos propusieron un método de intercambio de claves, aunque sería más apropiado decir "método de acuerdo de clave compartida", para solucionar el problema de intercambio inicial de mensajes entre dos partes a través de un canal inseguro. El método se conoce popularmente como Diffie-Hellman (si, suena a dúo de folk rock de los años 60), nombre derivado de sus autores: Whitfield Diffie y Martin Hellman. Según este último habría que añadir a Ralph Merkle como coautor del protocolo.

La base de este protocolo se basa en la dificultad de cálculo del logaritmo discreto de la forma g^a mod p, es decir, averiguar 'a'. Su análogo sería el problema de factorización de números primos que forma la base del algoritmo de clave pública RSA.

Diffie-Hellman se asienta en la forma que hemos visto: g^a mod p. Donde g y p son valores conocidos por ambas partes, es decir, no son valores secretos y pueden ser conocidos por todos. p es un número primo relativamente grande y g es una base matemáticamente relacionada con p (no vamos a profundizar en detalles). Pues bien, aun conociendo g y p, existe una dificultad computacional en hallar el exponente 'a', que es el secreto que va a añadir cada una de las partes.

La parte Alfa enviará a Bravo un valor que será A = g^a mod p. De manera correspondiente Bravo enviará a Alfa su contraparte: B = g^b mod p.

Ahora cada una de las partes tiene un valor que contiene el componente secreto de la otra.

La "magia" de todo esto es que volviendo a aplicar la fórmula sobre los valores intercambiados, ambos tendrán el mismo número, que llamaremos S:

Alfa hará esto:

S = B^a mod p

Bravo por su parte:

S = A^b mod p

Ese número 'S' será la clave "elegida" por ambos. Observemos que en ningún momento 'S' ha sido enviado por el canal, se trata de una derivación que ambas partes pueden hallar de manera común aplicando sus respectivos secretos sobre resultados "imposibles" de computar…hasta hoy…

Entonces llegó un grupo de investigadores de varias universidades junto con gente de la división de investigación y desarrollo de Microsoft. Pensaron que sería buena idea echarle un vistazo a esa tecnología setentera y ver como aguanta los avances en potencia de cálculo y algoritmos de 2015.

En primer lugar se las ingeniaron para lograr un nuevo ataque que degrada las conexiones TLS al uso de Diffie-Hellman en su versión "exportable" (DHE_EXPORT). Esta versión era la que estaba autorizada en los años 90 por la administración Clinton para productos que usaran tecnología de cifrado. Cómo no, esta versión usa primos de hasta 512 bits, una longitud que veremos es insuficiente. Con este ataque, que recuerda poderosamente a FREAK, se aseguraban que las conexiones seguras de una gran mayoría de clientes y servidores usarán Diffie-Hellman con 512 bits.

El siguiente paso era obtener una "base de datos" de cálculos ya efectuados de los primos más usados de 512 bits para esa versión descafeinada de Diffie-Hellman. Con los recursos de cálculo de una universidad, tardaron un par de semanas en obtener estas tablas precalculadas para los dos primos de 512 bits más usados.

Esos dos primos de 512 bits por cierto, son los usados por el servidor Apache y su módulo SSL (mod_ssl). Como ponen de ejemplo, el 8% del índice Alexa del top 1M HTTPS permite o soporta el uso de DHE_EXPORT y usan uno de estos dos primos de 512 bits en un 92% de casos.

Ahora ya solo les queda "escuchar" el resultado de g^a mod p, preguntar en su base de datos y calcular 'a'. Cuando obtienen la forma derivada g^ab mod p, donde 'ab' es la clave usada ya poseen el secreto para descifrar las comunicaciones.

Esto es un resumen a muy alto nivel del ataque. Os invitamos a leer la publicación del grupo de investigadores disponible aquí.

Algo que no pasó por alto al grupo era preguntarse hasta que punto era posible utilizar la misma técnica para valores de 768 y 1024 bits. Básicamente admiten que 768 bits puede alcanzarse de manera realista con una potencia de cálculo distribuido disponible en empresas y universidades y dejan los 1024 bits para organizaciones con muy buenos recursos y dedicados a estos menesteres de manera profesional, léase, la NSA por ejemplo.

No solo lo mencionan en la publicación que describe Logjam. El grupo de investigadores correlacionan directamente las filtraciones de Edward Snowden con la capacidad de la NSA para descifrar comunicaciones VPN usando este tipo de ataque. Casi nada.

¿Qué hacemos ahora? No nos queda otra opción. Es siempre la misma. Parchear y seguir adelante. Este no va a ser el último ataque a la criptografía, al secreto de las comunicaciones y a nuestra privacidad. Esto es una piedra más en el camino como tantas otras piedras llamadas FREAK, CRIME o POODLE y las que quedan por venir.

Por cierto, a los descubridores se les ha olvidado algo "importantísimo". Logjam no tiene un logo molón.

Más información:

Logjam

Imperfect Forward Secrecy:How Diffie-Hellman Fails in Practice

una-al-dia (03/03/2015) FREAK, un nuevo ataque a SSL/TLS

una-al-dia (15/10/2014) SSL tocado y hundido

una-al-dia (07/08/2013) Ataque BREACH, la seguridad HTTPS comprometida en 30 segundos



David García
Twitter: @dgn1729

miércoles, 7 de agosto de 2013

Ataque BREACH, la seguridad HTTPS comprometida en 30 segundos

Dentro de la Black Hat USA 2013, sin duda una de las conferencias de seguridad más prestigiosas, un grupo de investigadores demostraron cómo es posible obtener información sensible del texto cifrado https en menos de 30 segundos.

El ataque recibe el nombre de BREACH que no solo puede traducirse como "brecha" sino que además atiende a las siglas de "Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext" (Reconocimiento y Exfiltración del navegador a través de compresión adaptativa del hipertexto).

Los investigadores Angelo Prado, Neal Harris y Yoel Gluck demostraron el ataque en la Black Hat contra la aplicación web Outlook Web Access (OWA). Una vez abierta la aplicación web y lanzado el ataque BREACH, en tan solo 30 segundos habían conseguido extraer la información del canal seguro. El ataque se basa en la inyección de texto plano en una petición https y medir los cambios en las respuestas comprimidas.



El ataque BREACH es un tipo de vulnerabilidad y no una instancia específica que afecta a una parte específica del software. Para ser vulnerable, una aplicación web debe:
  • Ser servida desde un servidor que utilice compresión a nivel http (la mayoría lo hacen).
  • Reflejar entradas del usuario en el cuerpo de la respuesta http.
  • Reflejar un secreto (como un token CSRF) en el cuerpo de la respuesta http.

El atacante necesitará realizar peticiones estratégicamente construidas al sitio atacado para recuperar un secreto concreto en el cuerpo de una respuesta https (incluyendo IDs de usuarios, direcciones de correo electrónico e incluso tokens de autenticación). Será necesario enviar un par de peticiones para cada carácter del secreto a adivinar.

Para un token de una longitud de 32 caracteres y un espacio de caracteres (alfabeto) de 16 (en hexadecimal), el atacante necesitará una media de aproximadamente 1.000 peticiones si no se necesitan mecanismos de recuperación adicionales (en caso de obtener múltiples respuestas posibles). En la práctica, se ha comprobado que es posible recuperar tokens CSRF con menos de 4.000 peticiones. Navegadores como Google Chrome o Internet Explorer son capaces de realizar esas peticiones en menos de 30 segundos (de ahí el titular), incluyendo las llamadas de vuelta al centro de comando y control del atacante (que puede ser un sitio controlado por el atacante con un iframe apuntando al servidor vulnerable, o directamente con la intercepción y modificación del tráfico no asegurado).

Actualmente no se conoce una solución práctica y global a este problema. Sin embargo se ofrecen diversas contramedidas, algunas de ellas pueden proteger aplicaciones completas mientras otras solo sirven ante páginas web concretas. Entre las contramedidas se describen el desactivar la compresión http, separar secretos de las entradas del usuario, que los secretos en cada petición cliente sean aleatorios, enmascarar secretos, proteger páginas web de ataques CSRF y ofuscar la longitud de las respuestas web añadiendo cantidades aleatorias de bytes arbitrarios.

Más información:

BREACH

BREACH: REVIVING THE CRIME ATTACK

SSL, gone in 30 seconds - a BREACH beyond CRIME

Vulnerability Note VU#987798
BREACH vulnerability in compressed HTTPS

Antonio Ropero
Twitter: @aropero