EFAIL – ¿Está PGP realmente muerto?

 

Se ha publicado recientemente una vulnerabilidad (https://efail.de/) que afecta a PGP y S/MIME, dos mecanismos utilizados para el cifrado de correos. Como forma de mitigar esta vulnerabilidad, se recomienda deshabilitar los plugins de descifrado de mensajes incluidos en los gestores de correo, y sobre todo no utilizarlos para leer mensajes cifrados en los propios gestores de correo.

Pero, un momento… ¿No leer mensajes cifrados? ¿No tendría más sentido decir que no escribamos mensajes cifrados? En este post vamos a intentar entender en qué consiste esta vulnerabilidad, por qué se produce y sobre todo, cuál es la lógica detrás de que el problema consista en leer mensajes cifrados.

Esta vulnerabilidad afecta al cifrado de correos mediante dos mecanismos diferentes, aunque los dos se basan en un concepto similar. Para entender la vulnerabilidad, comenzaremos viendo la versión más sencilla, aunque a su vez es la menos extendida ya que implica un procesamiento incorrecto de los mensajes por parte del gestor de correo.

PGP y S/MIME son dos mecanismos muy parecidos entre sí. Se basan en un mecanismo de criptografía asimétrica, aunque el cifrado real es simétrico. Como esta vulnerabilidad afecta a la parte simétrica, trataremos PGP y S/MIME como si usaran criptografía simétrica.

En este ejemplo, Alice quiere enviar una contraseña a Bob. Como sabe que Eve anda detrás de la contraseña y que es posible que intercepte la comunicación, envía la contraseña dentro de un mensaje cifrado. Encripta el mensaje y se lo envía a Bob, que es capaz de descifrarlo correctamente. Eve intercepta el mensaje, pero al estar cifrado con una clave que ella desconoce, no es capaz de descifrarlo y obtener la contraseña.

Ahora bien, Eve sabe que Bob utiliza un gestor de correo vulnerable a la versión más sencilla de esta vulnerabilidad. Lo que hace es enviar un correo HTML a Bob compuesto de tres secciones (multipart). La primera y la última van en claro y las genera Eve, con lo que puede controlar su contenido. Como segunda sección envía el mensaje original generado por Alice, que había conseguido interceptar (aunque no puede leerlo). Cuando le llega el correo, Bob lo abre. Su gestor de correo detecta las tres secciones y que la segunda está cifrada. Por tanto, la descifra y le muestra a Bob el contenido.

¿Y cuál es el contenido? Eve ha construido el mensaje de tal modo que la primera sección contiene una etiqueta <img> que indica que se debe descargar una imagen especificada por la URL que viene en dicha sección. Sin embargo, podemos ver que el atributo “src” no está terminado, ya que le faltan las comillas. La terminación de este atributo se realiza en la tercera sección, donde están las comillas y el cierre de la etiqueta <img>. Con esto Eve ha conseguido que el contenido enviado por Alice quede dentro de la URL de la imagen. Como Eve controla totalmente la primera parte del mensaje, puede indicar que la imagen se encuentra en un servidor controlado por ella. El contenido del mensaje descifrado se incluirá en la URL y Eve no tiene más que mirar la petición que realiza Bob para obtener el mensaje de Alice descifrado.

Esta es la razón por la que el peligro reside en leer correos cifrados. Leer un correo malicioso puede provocar que el gestor de correo accede a un recurso externo, enviando en claro y de forma silenciosa el contenido en claro de cualquier otro mensaje cifrado a Eve. Por ejemplo, Eve podría haber preparado el mensaje para que la imagen se cargara en un iframe oculto, de modo que a priori no se despertaran sospechas.

En este caso, la vulnerabilidad consiste en que el gestor de correo ha cogido tres secciones independientes del mensaje y las ha juntado, generando una sola etiqueta HTML. Un gestor de correo correcto debería mostrar las tres secciones de forma independiente, de modo que nunca se conseguiría una etiqueta <img> que contuviera el mensaje original de Alice.

Esto en cuanto a la forma “sencilla” de explotar la vulnerabilidad. Ahora bien, asumiendo que tenemos un gestor de correo que no es vulnerable, sino que muestra las tres secciones de forma independiente… ¿Podemos seguir explotando esta vulnerabilidad?

Para entender mejor la otra vertiente de la vulnerabilidad hay que saber que PGP y S/MIME utilizan cifrado por bloques. Esto implica que el mensaje original se divide en bloques de tamaño fijo. Cada bloque de entrada da como resultado un bloque de salida del mismo tamaño. Relacionado con este mecanismo, el cifrado simétrico de PGP y de S/MIME plantea dos problemas.

Por un lado, utilizan algoritmos (técnicamente, modos de cifrado) “maleables”. Esto quiere decir que es posible reordenar o repetir los bloques del mensaje y salvo ciertos bloques que se descifrarán de forma incorrecta, los bloques reordenados seguirán descifrándose correctamente.

Por otro lado, si un atacante conoce perfectamente el contenido original (sin cifrar) de dos bloques consecutivos, puede generar pares de bloques cifrados que, al descifrarse, darán como resultado un bloque con contenido aleatorio (que no le sirve para nada al atacante) pero el otro bloque contendrá texto que puede controlar el atacante. Como la mayoría de mensajes PGP y S/MIME empiezan con una serie de cabeceras fijas, el atacante conoce el contenido descifrado de los primeros bloques y es capaz de inyectar texto controlado por él en el contenido que descifrará el usuario.

Sabiendo estos dos problemas, Eve puede derivar a partir del mensaje cifrado original de Alice (e incluso sin conocer la clave de cifrado) un mensaje malicioso que al descifrarse contiene:

  • Secciones de contenido aleatorio
  • Secciones de contenido controlado por Eve
  • Secciones del mensaje original de Alice

Y después de visto el ataque anterior podemos hacernos una idea de qué contenido tendrá el mensaje malicioso generado por Eve…

Donde las secciones “XXXX” indican partes del mensaje que Eve no puede controlar y tampoco provienen del mensaje original de Alice. Realmente el mensaje no tiene exactamente esta forma. Las partes que Eve controla tienen un tamaño fijo, al igual que las aleatorias, lo que dificulta en gran medida el trabajo a Eve. Sin embargo, la imagen anterior ilustra el concepto del ataque.

Esta vertiente de la vulnerabilidad afectaría a cualquier gestor de correo que descifre mensajes PGP o S/MIME y que descargue información externa asociada a estos correos (en este caso, la “imagen” maliciosa).  La vulnerabilidad es debida a que los modos utilizados por PGP y S/MIME son maleables como hemos visto, ya que estamos hablando de tecnologías que ya tienen muchos años. A día de hoy existen modos que proporcionan una característica llamada AEAD (Authenticated Encryption with Associated Data), como puede ser GCM. Estos modos detectan modificaciones del flujo de datos, lo que impediría que Eve pudiese generar un mensaje válido sin conocer la clave simétrica de cifrado. El gestor de correo de Bob detectaría que el mensaje ha sido modificado y no lo mostraría. Sí es cierto que PGP incluye un mecanismo llamado SEIP que proporciona un cierto nivel de protección frente a modificaciones, pero en el propio artículo de EFAIL indican que es posible sortearlo realizando un “SEIP downgrade”.

En resumen, a pesar de todo el revuelo que se ha montado, no sería justo tampoco decir que PGP como tal ha sido comprometido (hay muchas discusiones sobre si esto es técnicamente una vulnerabilidad de PGP o de los clientes de correo). Tiene sus problemas, lógicamente (como el hecho de la maleabilidad de sus mensajes y la posibilidad de esquivar la protección SEIP) pero hasta cierto punto PGP sigue siendo perfectamente válido. El problema en este caso surge a partir de la posibilidad de “exfiltrar” los datos en claro de mensajes cifrados a partir de funcionalidades incluidas en gran parte de los gestores de correo.

Es por ello que se recomienda deshabilitar los plugins de PGP y S/MIME en los gestores de correo, para evitar que el descifrado de un mensaje malicioso proporcione a un atacante el contenido en claro de un mensaje cifrado legítimo. Sin embargo, sabiendo estas limitaciones y entendiendo el alcance de esta vulnerabilidad, es perfectamente posible seguir utilizando estos sistemas de cifrado, teniendo cuidado de utilizar herramientas externas para su descifrado, y comprobar que en el mensaje descifrado no aparezcan secciones con datos “erróneos” que puedan sugerir que es un mensaje malicioso.

Deshabilitar la visualización de HTML en los mensajes recibidos también puede dificultar que un atacante pueda explotar esta vulnerabilidad de forma sencilla. Sin embargo, la extracción de datos mediante etiquetas <img> no es la única vía abierta para un atacante, por lo que esta operación no implica seguridad al 100%.

Recent Posts

Leave a Comment