SMACK TLS y el ataque FREAK

jueves, 12 de marzo de 2015

Últimamente, las vulnerabilidades sobre TLS/SSL están dando mucho de qué hablar. El pasado 23 de febrero realizábamos un repaso de las incidencias que pueden catalogar el servicio SSL/TLS de inseguro según su implementación y configuración.

En esta ocasión, os explicaremos la vulnerabilidad FREAK (Factoring RSA Export Keys) haciendo hincapié en el impacto que ha tenido, destacando la implicación de miTLS con el proyecto y la investigación de SMACK.

SMACK: State Machine AttaCKs
El proyecto de los investigadores de miTLS, se basa en analizar los comportamientos de las distintas implementaciones de SSL/TLS, gracias a esa investigación se han descubierto vulnerabilidades como SKIP-TLS o FREAK, que se explicarán más adelante.

Dado que el control del momento de la conexión se gestiona a través de una máquina de estados, este ataque se ha denominado state machine attack.

Ilustración 1: Logotipo del proyecto SMACK

La vulnerabilidad SKIP-TLS se sostiene en la mala implementación de TLS, que permite omitir algunos pasos o campos durante el saludo e intercambio de información entre cliente-servidor.

Un ejemplo de esta vulnerabilidad es la implementación en cliente de JSSE, la cual permite abreviar el saludo SSL/TLS y omitir algunos pasos esenciales para la selección del cifrado, permitiendo al atacante enviar únicamente el certificado y omitir el resto de pasos de la comunicación. En caso de que el cliente acepte la conexión, esta se realizara sin cifrado alguno, por lo que la conexión no posee autenticación, integridad ni confidencialidad.

FREAK (Factoring RSA Export Keys)
FREAK afecta a diferentes productos y está siendo más común de lo que en un principio se esperaba, a día de hoy posee múltiples CVE para los productos más conocidos como OpenSSL (CVE-2015-0204), Schannel(CVE-2015-1637) en el caso de Microsoft y la implementación de TLS de Apple(CVE-2015-2235). Dicha vulnerabilidad surgió con el miedo de EEUU de exportar cifrados que no pudiesen ser descifrados por ellos, por lo que se forzó que los cifrados EXPORT se usasen con una clave RSA igual o inferior a 512, lo que en la década del 90 era considerada una longitud robusta y suficiente.

Por otro lado, a día de hoy, se puede obtener la clave en un tiempo razonable con servicios de cloud computing, los cuales, son capaces de extraer la clave en menos de 12 horas. Un tiempo más que asumible ya que generar una clave RSA es un proceso relativamente costoso y por ejemplo mod_ssl en Apache no genera la clave RSA por cada conexión, únicamente la genera al iniciarse, lo que significa que un atacante recupera la clave RSA y una vez descifrada, puede usar la clave con todas las sesiones que quiera y suplantar la identidad del servidor hasta que este se reinicie y genere una nueva clave.

¿Cómo puede afectar esto a nivel de servidor?
Esta vulnerabilidad se resume en que si el servidor implementa alguno de los cifrados EXPORT comentados, un posible atacante podrá recuperar la clave RSA para a posteriori interceptar la comunicación entre cliente y servidor usando técnicas de tipo Man in the Middle, y dado que, el atacante es capaz de cifrar y descifrar toda la conversación, el cliente no será advertido en ningún momento, perdiendo la integridad y la confidencialidad de la información.

Comprobar el soporte de los cifrados EXPORT en el servidor se puede realizar de forma sencilla con el cliente de OpenSSL:

openssl s_client -connect domain.com:443 -cipher EXPORT

Este proceso se puede ejecutar con diferentes herramientas y scripts, por otro lado si eres cliente de Faast, en el próximo escaneo aparecerán los servidores vulnerables y a través de la evidencia podrás observar que conjuntos de cifrados se deben deshabilitar.

Ilustración 2: Evidencia de la vulnerabilidad FREAK a través de la interfaz web de Faast

¿Cómo me afecta esto como usuario?
Es importante tener claro que, a pesar de que el servidor sea vulnerable, el cliente debe tener implementados los cifrados EXPORT para poder conversar con el servidor e intercambiar la misma clave RSA que el atacante ya tiene descifrada. Si utilizas un navegador antiguo, es altamente recomendable actualizar a la última versión tanto en las aplicaciones de escritorio como en los dispositivos móviles para evitar que toda la información enviada pueda ser interceptada por un atacante.


Ilustración 3: Comprobación de FREAK en la aplicación de Google Chrome de escritorio

Ilustración 4: Google Chrome 40 en Android 5.0.1 se muestra vulnerable

Sin olvidar que, como desarrolladores, las librerías que se utilizan para hacer peticiones como wget o curl, también deben ser actualizadas para evitar ser afectadas por este tipo de problemas de seguridad.

En resumen...
En este momento el sitio web de FREAK recopila información del avance de esta vulnerabilidad en la red. En el momento de publicarse el CVE, el 12.2% de los dominios de Alexa se veían afectados, ese porcentaje va descendiendo progresivamente, aunque según las estadísticas el 36.7% de los servidores HTTPS con certificados validos tienen cifrados RSA_EXPORT y por tanto son susceptibles al ataque FREAK.

Para mitigar la vulnerabilidad al igual que paso con Poodle y los cifrados de bloques CBC y otras similares, es recomendable actualizar la versión del servidor/cliente y dejar de implementar los cifrados EXPORT.


Óscar Sánchez
oscar.sanchez@11paths.com

No hay comentarios:

Publicar un comentario en la entrada