EFAIL, ataques sobre implementaciones PGP y S/MIME ¿cómo protegerse?
Los investigadores de varias universidades europeas -en Alemania y Bélgica- han encontrado hace poco una serie de vulnerabilidades críticas en herramientas PGP y S/MIME, que de ser explotadas por un atacante rompería la privacidad y permitiría que los mensajes de correo cifrados con estos estándares fueran leídos. Su nombre es eFail.
La existencia de estas vulnerabilidades ha sido confirmada por la EFF (Electronic Frontier Foundation) que ha recomendado desinstalar los clientes que utilizan estos mecanismos mientras se solucionan los problemas anunciados.
Vulnerabilidades halladas en PGP y S/MIME (eFail)
Cuando se desclasifican vulnerabilidades se corre el riesgo (y esta no es una excepción) de que el hype se dispare. Dicho de otra manera, que en ocasiones una noticia se magnifica demasiado y el alcance es menor del que se presupone.
Acerca de PGP y S/MIME
Antes de continuar veamos a qué se refiere cada uno de estos dos estándares relacionados con el correo electrónico:
- PGP: Pretty Good Privacy. Se trata de un estandar de cifrado desarrollado por Phil Zimmermann que se encarga de proteger la información que viaja por internet mediante criptografía de clave pública. También se utiliza para firmar documentos digitales garantizando el no-repudio.
- S/MIME: Secure / Multipurpose Internet Mail Extensions. Es un estandar que basado en criptografía de clave pública, desarrollado por RSA, cuyo cometido es garantizar la autenticidad de los mensajes entregados telemáticamente.
Tipos de ataques
Los expertos hablan de 2 variantes de EFAIL, estando en una posición de interceptar mensajes cifrados, por ejemplo hackeando una cuenta de correo o realizando un ataque MiTM u «hombre en el medio» para tener éxito.
Exfiltración directa
Estos ataques explotan vulnerabilidades en OpenPGP y S/MIME para revelar el texto plano que se oculta tras los mensajes cifrados. En resumen, EFAIL abusa del contenido activo de tipo HTML del email, por ejemplo mediante la carga de imágenes externas o estilos, para exfiltrar texto plano mediante las URL.
Para crear canales de exfiltración (comunicación al exterior de los datos robados) el atacante necesita contar con acceso previo a los emails cifrados, por ejemplo escuchando el tráfico de red, hackeando cuentas de correo, servidores de email, sistemas de backup o clientes de la red. Estos emails podrían haberse capturado hace años, incluso.
Es decir, que realmente el riesgo potencial de un ataque así no es tan elevado como se ha planteado en ciertas publicaciones.
Dicho de otra manera: si un atacante consigue acceso a nuestro servidor de correo, sistema de backup o se desplaza lateralmente desde un equipo de nuestra red, se me ocurren formas más directas y peligrosas de causar daño que este ataque bautizado como eFail.
Ataque CBC/CFB gadget
El segundo tipo de ataque explotaría vulnerabilidades en OpenPGP y S/MIME (CVE-2017-17688 y CVE-2017-17689). En este caso, la víctima necesitaría estar en posesión de la llave de cifrado privada. En caso de que la clave privada no esté disponible, el ataque no podría llevarse a cabo. Sobre este tipo de ataque, el informe dice lo siguiente:
Entonces enviará un email manipulado a uno de los destinatarios originales, o al emisor original. Podría decidir esconder esto escogiendo nuevos valores para «DESDE», «FECHA» y «ASUNTO» y podría manipular el texto cifrado escondiéndolo tras un iframe invisible. Por eso el email de ataque que recibe la víctima parece inofensivo.
Una vez la víctima abre el email manipulado en su cliente de correo, el texto cifrado será desencriptado -pirmero se usará la clave privada de la víctima para descifrar la clave de sesión «s» y después las claves de sesión son utilizadas para descifrar el texto cifrado «c«.
El texto plano ahora contendrá, tras haberse manipulado, un canal de exfiltración (como podría ser un enlace HTML) que enviará el texto plano descifrado como parte de un ataque.
El ataque CBC/CFB gadget es efectivo contra PGP, con un ratio de éxito de aproximadamente 33%. Los ataques en su conjunto han conseguido éxito en 25 de 35 clientes de email con implementación S/MIME y de 10 de los 28 clientes OpenPGP probados.
¿Son realmente tan graves como parecen estas vulnerabilidades?
Muchos expertos en ciberseguridad han rebajado un poco los ánimos respecto de la criticidad de estos fallos en el mundo real, dejando claro que solo funcionarían en clientes de email con una mala gestión de la seguridad.
Mención aparte merecen los clientes de email de Apple Mail, Mozilla e iOS Mail, donde se han encontrado vulnerabilidades más severas que permitirían una filtración directa del texto plano previamente descifrado.
Además de lo ya dicho -y como señalan muchos investigadores- lo que se está aprovechando en los ataques contra PGP no son vulnerabilidades de este estándar como tales. Lo que se aprovecha aquí es una mala configuración de clientes de correo que no impiden que el contenido suministrado por fuentes ajenas al propio correo sean renderizadas de forma automática (como podrían ser banners de anuncios).
Del mismo modo, tampoco se trata de un problema novedoso esta explotación sobre el estandar S/MIME. Desde 2001 se han documentado problemas al mostrar mensajes corruptos.
Tampoco se trata de un tipo de ataque demasiado difícil de detectar. Por ejemplo, se podría poner en marcha un script que detecte las etiquetas <img> mal formadas en mensajes entrantes, por poner un ejemplo.
Mitigación y soluciones
A corto plazo, es recomendable tener en cuenta lo siguiente:
- No usar descifrado en cliente: para prevenir los peligros de ataques Efail una buena solución es realizar el descifrado de correos con PGP o S/MIME en una aplicación independiente de nuestro gestor de correo. Se podrían eliminar las claves de este tipo de nuestro cliente de email y después realizar el descifrado de estas desde una aplicación independiente, evitando de esta forma que existan canales de filtración. Esta opción es la más apropiada pero también implica un trabajo mayor.
- Desactivar renderizado de HTML: como Efail abusa del contenido activo, principalmente en forma de imágenes, estilos y demás, otrsa opción es desactivar la presentación de mensajes con HTML en nuestro cliente de correo. Seguirán existiendo otros canales aparte del HTML, pero habremos quitado de enmedio el peligro más acuciante.
A medio plazo, las medidas a tomar pasarían primero por parchear los sistemas afectados (algo bastante obvio y que implica poco trabajo en principio) mientras que a posteriori es necesario que se modernicen los estándares PGP y S/MIME para que se vayan haciendo más robustos.
Se ha llegado incluso a sugerir la desactivación de PGP o GPG completamente hasta que exista un parche. Personalmente dudo mucho que -por mucha vulnerabilidad que pudiera haber- sea mejor basarse en un correo sin cifrado alguno que en un estándar de de cifrado correo con alguna vulnerabilidad.
Categories
deweloper View All
Trabajo como consultor de ciberseguridad y me gusta lo que hago. Aficionado a la informática / tecnología en general, me gusta compartir con la gente lo poco que sé. También soy aficionado al deporte y los videojuegos.