¿SSL y TLS en peligro? (Ataque Lucky Thirteen)

Investigadores británicos descubrieron un fallo en el protocolo de cifrado más usado en la Red, y que pondría en peligro las transacciones bancarias y otros sistemas. De todos modos aclaran que ya trabajan en una solución y que en su estado actual el ataque sería difícil de llevar acabo.

"Sí, todas esas operaciones están en peligro", dice el profesor de seguridad de la información de la Universidad de Londres, Kenneth G. Paterson. Junto a uno de sus estudiantes, Nadhem AlFardan, Paterson ha descubierto una serie de graves debilidades en el protocolo de seguridad más usado para proteger las comunicaciones por internet, el Transport Layer Security (TLS, o seguridad de la capa de transporte, en español).

En SSL/TLS el emisor y el receptor de una comunicación comparten un algoritmo de cifrado y unas claves con las que el primero cifra el contenido que va a enviar y el segundo las descifra. La práctica totalidad de las empresas y comercios de la red usan programas de cifrado que se apoyan en el protocolo TLS, como OpenSSL, GnuTLS, PolarSSL, CyaSSL, Opera y BouncyCastle. De esta manera, un tercero que "pinchara" cualquiera de las máquinas por las que pasa esa información sólo vería un mar de datos sin sentido.

Lo que han demostrado estos investigadores británicos, en un estudio publicado ayer [PDF], es que TLS tiene un fallo en su diseño, es decir, que no depende de la implementación que cada software o empresa haga de él, que permite capturar la información cifrada en formato de texto plano, es decir, legible para los humanos. El riesgo es aún mayor con la variante del protocolo conocida como DTLS, donde el número de ataques necesarios para conseguir los datos es aún menor. En la jerga de la seguridad informática este tipo de ataques se llaman de Man-in-the-Middle (MitM, o el hombre en el medio, en inglés).

¿Cómo funciona el ataque Lucky Thirteen?

En la cultura occidental, el 13 se considera un número de mala suerte. El hecho de que el cálculo TLS MAC incluye 13 bytes en la cabecera (5 bytes de cabecera y 8 bytes de secuencia) es, en parte, lo que hace posible el ataque. ¡Humor de criptógrafos!.

El Lucky Thirteen Attack es un nuevo ataque criptográfico y se trata de una nueva variante del Padding Oracle Attack (ya solucionado) en la momento de la verificación de integridad MAC. La mayoría de las implementaciones de TLS son vulnerables al ataque. Todos los conjuntos de cifrado TLS y DTLS que incluyen el modo de cifrado CBC (Cipher-Block-Chaining) son potencialmente vulnerables a los ataques.

Lucky Thirteen utiliza una técnica conocida como Padding Oracle en el motor de cifrado principal en TLS, responsable de realizar el cifrado y garantizar la integridad de los datos. Los datos se procesan en bloques de 16 bytes utilizando una rutina conocida como MEE (MAC-then-Encode-then-Encrypt), que pasa los datos a través de un algoritmo MAC (Message Authentication Code); a continuación, los codifica y los cifra. La rutina añade "relleno" (Padding) al texto cifrado para que los datos resultantes queden perfectamente alineados al límite de 8 o 16 bytes. Este relleno más tarde se extrae al momento de descifrar TLS.

El ataque comienza con la captura de texto cifrado a medida que viaja a través de Internet. Usando una debilidad antigua de CBC (modo de cifrado en bloque) en TLS, los atacantes reemplazan los últimos bloques con varios bloques escogidos y observan la cantidad de tiempo que le toma responder al servidor. Los mensajes que contienen un relleno correcto tardarán menos tiempo en procesarse. Un mecanismo en TLS hace que la transacción falle cada vez que la aplicación se encuentra con un mensaje que contiene datos alterados. Mediante el envío de grandes cantidades de mensajes TLS y el muestreo estadístico de tiempos de respuesta, se puede "adivinar" el contenido del texto cifrado.

TLS en modo CBC ha sido objeto de varios ataques durante los años, los ataques sobre todo Padding Oracle y BEAST. Sin embargo, existen contramedidas para estos dos ataques, y se cree que TLS (CBC) es seguro aplicando estas medidas.

Aproximadamente toma 2^23 sesiones extraer todo el contenido de una cookie en una autenticación TLS normal, y si las cookies están codificadas en Base64, se podría extraer en 2^19 sesiones. Ya que el acercamiento al problema es similar, para hacer los ataques más eficientes, se pueden incorporar métodos como BEAST y CRIME utilizando JavaScript.

De la seriedad del peligro para las comunicaciones por Internet da prueba el hecho de que Microsoft, Apple, Opera, Oracle, Cisco, Google, F5 y las principales empresas y grupos que han desarrollado software de cifrado basado en TLS/DTLS han sido avisados por los investigadores y ya están creando parches de seguridad.

Prevención

En primer lugar, ya se liberaron las versiones OpenSSL 1.0.1d, 1.0.0k or 0.9.8y que solucionan esta vulnerabilidad por lo que es recomendable actualizar a esa versión. En segundo lugar, se debe priorizar el cifrado RC4 en el servidor web por encima de otros, ya que no es vulnerable.

Configuración recomendada de cifrado SSL en Apache :

SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
SSLHonorCipherOrder on


Configuración recomendada de cifrado SSL en NGIX:

ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH;
ssl_prefer_server_ciphers on;


Mozilla se encuentra trabajando en su módulo NSS. Microsoft afirma que sus aplicaciones no se ven afectadas. Apple se ha negado a comentar.

Otras aplicaciones que están actualizando:

• OpenSSL: versiones 1.0.1d, 1.0.0k and 0.9.8y, 05/02/2013.
• NSS: en desarrollo.
• GnuTLS: versiones 2.12.23, 3.0.28 and 3.1.7, 04/02/13.
• PolarSSL: version 1.2.5, 03/02/13.
• CyaSSL: version 2.5.0, 04/02/2013.
• MatrixSSL: version 3.4.1, 06/02/13.
• Opera: version 12.13, 30/01/2013.

Garantía imposible

"Hemos trabajado con la mayoría de ellos para ayudarles a comprender nuestro trabajo y su importancia y, en algunos casos, para desarrollar y probar parches", explica el profesor Paterson. Muchos de esos vendedores lanzarán soluciones en los próximos días, por lo que los investigadores esperan que el problema esté solucionado pronto en las principales implementaciones. "Sin embargo, la extensión del uso de TLS es tanta que es imposible garantizar que todas lo arreglen enseguida", añade.

Por fortuna, aprovechar esta debilidad no está al alcance de cualquier pirata informático. "Necesitarán hacer un concienzudo trabajo de codificación antes de crear una herramienta de ataque útil. No es sencillo, a nosotros nos ha llevado meses de desarrollo y experimentación", asegura Paterson. Su ataque se basa en aprovechar mensajes de error en una sesión o conexión. "Pero, como las diferencias de tiempo son muy pequeñas, el atacante necesita poder situarse muy cerca del servidor TLS para obtener esa información de forma fiable. Esto limita la ventana de oportunidad de llevar a cabo el ataque", explica.

Pero esa cercanía al servidor objetivo no significa que el atacante deba tener un acceso directo a la máquina, le basta con entrar en la red de área local (LAN) donde se encuentre su víctima, por ejemplo a través de una red WiFi, y esto se puede conseguir desde cualquier parte del mundo.

Fuente: La Nación, Imperial Violet y Paper publicado por la Universidad de Londres

Suscríbete a nuestro Boletín