Ya tenemos entre nosotros la publicación de una nueva vulnerabilidad de impacto alto, en algunas implementaciones del protocolo SSL/TLS.
Según leo en ArsTechnica, investigadores del Microsoft Research y del French National Institute for Research in Computer Science and Control, han descubierto una vulnerabilidad que afectaría entre otros a los dispositivos cliente basados en IOS y Android, entre otros.
Según leo en ArsTechnica, investigadores del Microsoft Research y del French National Institute for Research in Computer Science and Control, han descubierto una vulnerabilidad que afectaría entre otros a los dispositivos cliente basados en IOS y Android, entre otros.
Para la explotación de dicha vulnerabilidad, el atacante necesita estar en una posición que le permita situarse en medio de la comunicación entre cliente y servidor.
Para ello el atacante intercepta el handshake inicial entre cliente y servidor, e inyecta cierta información que fuerza al servidor (si es que este lo permite) a hacer un downgrade de la seguridad de la comunicación, utilizando una clave de sesión RSA de 512 bits de longitud. El contenido de la comunicación, al poder ser interceptada, podrá ser descifrada offline, crackeando la clave en unas 7 horas y media con el hardware adecuado.
Esta vulnerabilidad se ha llamado FREAK por las siglas de "Factoring Attack on RSA- Export Keys” y acompañan a otras tantas vulnerabilidades, como Heartbleed o Poodle, que han desmitificado las comunicaciones cifradas por uno de los protocolos más utilizados en Internet. Se ha asignado el identificador CVE-2015-0204
¿Por qué es posible hacer este downgrade para usar longitud de claves consideradas débiles?
En los 90, la administración Clinton, decidió regular la robustez del cifrado utilizado para software y hardware exportados fuera de Estados Unidos, para que se utilizasen longitudes de clave más débiles.
En el inicio de la comunicación cifrada entre cliente y servidor, se establece un intercambio de algoritmos a utilizar en la misma, dependiendo de las capacidades y configuración de ambas partes. Normalmente, se suele utilizar (si así está configurado) el algoritmo más seguro soportado por ambas partes, pero por compatibilidad con sistemas más antiguos (tanto de cliente como de servidor) queda la puerta abierta a utilizar el cifrado que exija menor rendimiento (muchas veces, como en este caso, la necesidad no es técnica, sino legal!)
Básicamente, si el servidor soporta el algoritmo TLS_RSA_EXPORT_WITH_DES40_CBC_SHA, el servicio es vulnerable.
¿Quién es vulnerable?
Por las estadísticas que se han obtenido, y aunque van disminuyendo el número de servidores afectados por la misma, en el momento de redacción de este post, hay un 10% de servidores afectados del Top 1 Millón de dominios de Alexa (según la web https://freakattack.com/), aunque ha disminuido del 12,2% anterior.
Desde el punto de vista del cliente, Android, IOS y Chrome sobre cualquier plataforma, lo es. Puedes comprobar si tu navegador es vulnerable a este fallo en: https://freakattack.com/clienttest.html
Como se puede ver la última versión de Google Chrome, sobre Mac OS X, es vulnerable
Como se puede ver la última versión de Google Chrome, sobre Mac OS X, es vulnerable
Ojo, recordamos que esta situación sólo aplica en entornos donde sea posible MiTM, y en los que el servidor y cliente sean vulnerables, por lo que aunque tendrá su quota de explotación, es algo a tener en cuenta. Desde mi punto de vista, los dispositivos servidores más afectados, serán aquellos que no permitan actualización sencilla y que implementen SSL/TLS como OpenSSL. Me refiero a dispositivos con servidor web embebido como sistemas de gestión de alarmas, cámaras, etc,...
Como siempre, no fiarse de redes inalámbricas, tener grabada a fuego la correspondencia entre las direcciones MAC e IP de vuestro gateway en el PC y utilizar conexiones 3G (para sólo desconfiar del ISP), son medidas más que interesantes.
Como siempre, no fiarse de redes inalámbricas, tener grabada a fuego la correspondencia entre las direcciones MAC e IP de vuestro gateway en el PC y utilizar conexiones 3G (para sólo desconfiar del ISP), son medidas más que interesantes.
Desde el punto de vista del servidor, en aquellos que se pueda, recomendamos la utilización de algoritmos de cifrado fuertes, como hicimos Yago y yo en el Curso de "Attack & Hardening de GNU/Linux”, cuando hablábamos de securización de servidores Apache.
0 comments :
Publicar un comentario