Vulnerabilidades y divulgación del correo electrónico

eail

La semana pasada, investigadores revelaron vulnerabilidades en una gran cantidad de clientes de correo electrónico cifrados: específicamente, aquellos que usan OpenPGP y S / MIME, incluidos Thunderbird y AppleMail. Estas vulnerabilidades son graves: un atacante que puede alterar el correo enviado a un cliente vulnerable, puede engañar a ese cliente para que envíe una copia del texto sin formato a un servidor web controlado por ese atacante. La historia de estas vulnerabilidades y la historia de cómo fueron reveladas ilustran algunas lecciones importantes sobre las vulnerabilidades de seguridad en general y la seguridad del correo electrónico en particular.


Si usa PGP o S / MIME para cifrar el correo electrónico, debe verificar la lista en esta página y ver si es vulnerable. Si es así, verifique con el proveedor para ver si han solucionado la vulnerabilidad. (Tenga en cuenta que algunos parches iniciales resultaron no corregir la vulnerabilidad). De lo contrario, deje de utilizar el programa de correo electrónico encriptado por completo hasta que se solucione. O bien, si sabe cómo hacerlo, desactive la capacidad de su cliente de correo electrónico para procesar el correo electrónico HTML o, incluso mejor, deje de descifrar los correos electrónicos desde el cliente. Hay consejos aún más complejos para usuarios más sofisticados, pero si eres uno de ellos, no necesitas que te explique esto.

Considere su correo cifrado inseguro hasta que esto se solucione.

Todo el software contiene vulnerabilidades de seguridad, y una de las principales formas en que todos mejoramos nuestra seguridad es que los investigadores descubran esas vulnerabilidades y los proveedores las corrijan. Es un sistema extraño: los investigadores corporativos están motivados por la publicidad, los investigadores académicos por credenciales de publicación, y casi todos por la fama individual y las pequeñas recompensas de errores pagadas por algunos proveedores.

Los proveedores de software, por otro lado, están motivados para corregir vulnerabilidades por la amenaza de divulgación pública. Sin la amenaza de una posible publicación, es probable que los proveedores ignoren a los investigadores y demoren el parcheo. Esto sucedió mucho en la década de 1990, e incluso hoy en día, los vendedores a menudo usan tácticas legales para tratar de bloquear la publicación. Que tiene sentido; se ven mal cuando sus productos se declaran inseguros.

En los últimos años, los investigadores han comenzado a coreografiar los anuncios de vulnerabilidad para provocar un gran impacto en la prensa. Nombres inteligentes: la vulnerabilidad del correo electrónico se llama "Efail": los sitios web y los lindos logotipos son ahora comunes. A los informantes clave se les brinda información anticipada sobre las vulnerabilidades. A veces se lanzan adelantos anticipados. Los proveedores ahora son parte de este proceso, tratando de anunciar sus parches al mismo tiempo que se anuncian las vulnerabilidades.

Este anuncio simultáneo es mejor para la seguridad. Si bien siempre es posible que alguna organización, ya sea gubernamental o criminal, haya descubierto de manera independiente y esté usando la vulnerabilidad antes de que los investigadores se hagan públicos, el uso de la vulnerabilidad está esencialmente garantizado después del anuncio. El período de tiempo entre el anuncio y el parcheo es el más peligroso, y todos, excepto los posibles atacantes, quieren minimizarlo.

Las cosas se vuelven mucho más complicadas cuando están involucrados múltiples proveedores. En este caso, Efail no es una vulnerabilidad en un producto en particular; es una vulnerabilidad en un estándar que se usa en docenas de productos diferentes. Como tal, los investigadores tenían que asegurarse de que todos conocieran la vulnerabilidad a tiempo para solucionarla y de que nadie filtrara la vulnerabilidad al público durante ese tiempo. Como se puede imaginar, eso es casi imposible.


Efail fue descubierto en algún momento del año pasado, y los investigadores alertaron a docenas de compañías diferentes entre octubre y marzo pasado. Algunas compañías tomaron las noticias más en serio que otras. Las noticias sobre la vulnerabilidad no se filtraron hasta el día antes de la fecha de anuncio programada. Dos días antes de la publicación programada, los investigadores dieron a conocer un avance - honestamente, una muy mala idea - que dio como resultado la filtración de detalles.

Después de la filtración, la Electronic Frontier Foundation publicó un aviso sobre la vulnerabilidad sin detalles. La organización ha sido criticada por su anuncio, pero estoy en apuros para encontrar fallas en sus consejos. Luego, los investigadores publicaron y mucha prensa siguió.


Todo esto habla de la dificultad de coordinar la divulgación de vulnerabilidades cuando involucra a un gran número de empresas o, incluso más problemáticas, comunidades sin una propiedad clara. Y eso es lo que tenemos con OpenPGP. Es aún peor cuando el error involucra la interacción entre diferentes partes de un sistema. En este caso, no hay nada malo con PGP o S / MIME en sí mismos. Más bien, la vulnerabilidad ocurre debido a la forma en que muchos programas de correo electrónico manejan el correo electrónico cifrado. GnuPG, una implementación de OpenPGP, decidió que el error no era su culpa y no hizo nada al respecto. Esto es discutiblemente cierto, pero irrelevante. Deberían arreglarlo.


Espere más de este tipo de problemas en el futuro. Internet está cambiando de un conjunto de sistemas deliberadamente use, nuestros teléfonos y computadoras, a un mundo inmerso en el mundo de las cosas en el que vivimos las 24 horas del día, los 7 días de la semana. Y al igual que esta vulnerabilidad de correo electrónico, las vulnerabilidades surgirán a través de las interacciones de diferentes sistemas. A veces será obvio quién debería solucionar el problema. Algunas veces no será así. A veces serán dos sistemas seguros que, cuando interactúan de una manera particular, causan una inseguridad.

El sistema de divulgación y parche asume que los proveedores tienen la experiencia y la capacidad de parchar sus sistemas, pero eso simplemente no es cierto para muchos de los paquetes de software de Internet de cosas integradas y de bajo costo. Están diseñados a un costo mucho más bajo, a menudo por equipos extraterritoriales que se unen, crean el software y luego se disuelven; como resultado, simplemente no queda nadie para recibir alertas de vulnerabilidad de los investigadores y escribir parches. Peor aún, muchos de estos dispositivos no son parcheables en absoluto. En este momento, si posee un grabador de video digital que es vulnerable a ser reclutado para un botnet, recuerde a Mirai en 2016? - La única forma de parchearlo es tirarlo y comprar uno nuevo. La conexión está empezando a fallar, lo que significa que estamos perdiendo el mejor mecanismo que tenemos para mejorar la seguridad del software al mismo tiempo que el software está ganando autonomía. Muchos investigadores y organizaciones, han propuesto regulaciones gubernamentales que imponen estándares mínimos de seguridad para los dispositivos de Internet de las cosas, incluidos los estándares en torno a la revelación de vulnerabilidades y parches. Esto sería costoso, pero es difícil ver otra alternativa viable.

Volviendo al correo electrónico, la verdad es que es increíblemente difícil de asegurar. No porque la criptografía sea difícil, sino porque esperamos que el correo electrónico haga tantas cosas. Lo usamos para correspondencia, conversaciones, programación y mantenimiento de registros. Busco regularmente en mi archivo de correo electrónico de 20 años. Los protocolos de seguridad PGP y S / MIME están desactualizados, son innecesariamente complicados y han sido difíciles de usar correctamente todo el tiempo. Si pudiéramos comenzar de nuevo, diseñaríamos algo mejor y más fácil de usar, pero la gran cantidad de aplicaciones heredadas que usan los estándares existentes significa que no podemos.

 

Si te ha gustado el artículo, síguenos en FacebookTwitterunete a nuestra charla en Riotúnete a IRC o únete a Telegram y no olvides compartirnos en las redes sociales. También puede hacernos una donación o comprar nuestros servicios.

Acerca del autor

Fredy Yesid Avila - Ingeniero de Sistemas, CEH - ECSA,