¿Es suficiente la investigación del archivo .eml de un correo electrónico para considerarlo malicioso?

No. Hay algunos campos SMTP como

  

MAIL FROM : - generalmente presentado al destinatario como la ruta de retorno:   encabezado, pero normalmente no es visible para el usuario final, y por defecto no   Se realizan comprobaciones que el sistema de envío está autorizado para enviar en   nombre de esa dirección.

también

  

De : Joe Q Doe: la dirección visible para el destinatario; pero de nuevo, por defecto no se realizan comprobaciones que el envío   El sistema está autorizado para enviar en nombre de esa dirección.

Cualquier persona puede falsificar cualquier dirección de correo existente. Incluso podría enviarle un correo desde su propia dirección de correo .

Concentrándose en el cliente de correo electrónico y sus vulnerabilidades, en su mayor parte la evidencia estaría en el archivo eml enviado. Puedo imaginar algo como, por ejemplo, un desbordamiento de búfer en el renderizador de imágenes o daños en la memoria en el analizador html para correos electrónicos html: la evidencia de estos estaría presente en el archivo .eml. Sin embargo, si es obvio, esa es otra pregunta, en algunos casos especiales puede ser sutil y si la pregunta es si puede encontrarlos automáticamente con algún tipo de herramienta, probablemente no en caso de fallas de día cero. Pero el análisis manual (análisis forense) puede identificar este tipo de ataques desde archivos .eml.

Puedo pensar en otra cosa que puede o no ser de tu interés. Un atacante puede crear de alguna manera un correo electrónico recibido por su servidor smtp y comprometer ese smtp a través de sus propias fallas de una manera que más tarde, cuando presumiblemente el mismo servidor sirve ese correo electrónico a los clientes en imap o pop3, el ataque se reenvía a Clientes dentro de imap o pop3 en sí. En este caso, no habría evidencia en los archivos .eml, la vulnerabilidad estaba en la implementación del protocolo en el cliente de correo electrónico. Sin embargo, tal ataque sería muy improbable, pero creo que no es necesariamente imposible.

Entonces, resumiendo esto, creo que el cliente puede estar comprometido a través de dos canales, cualquiera de ellos el contenido del correo electrónico en sí mismo, lo cual es mucho más probable, y la evidencia estaría en los archivos .eml en bruto, o a través del protocolo que utiliza para descargar correos electrónicos desde el servidor, pero ese servidor es controlado por usted, por lo que representa un riesgo mucho menor.

Otra cosa que me viene a la mente es que si se explota la ejecución del código en el cliente de correo electrónico, es posible que el código del atacante en realidad cambie el archivo de correo electrónico para ocultar la evidencia. Una vez más, creo que sería muy difícil hacerlo de manera confiable en el caso general, pero en teoría no es imposible. Sin embargo, aún tendrías los archivos de correo electrónico sin cambios en el servidor, a menos que eso también se vea comprometido en un ataque por separado.

Nunca puedes clasificar nada como 100% seguro.

Para responder a su pregunta correctamente, no puede saber si algo está seguro solo con la fuente del correo electrónico (o encabezado), pero puede decir si es muy probable que sea inseguro. Recuerde que no saber si algo es seguro no significa que sea inseguro.

La respuesta es NO . La única forma de confiar en que un correo electrónico en particular es de una fuente auténtica y el remitente no ha sido falsificado ni el mensaje modificado de manera malintencionada es a través de un certificado digital emitido por una Autoridad de Certificación de confianza .

Un algoritmo típico y ampliamente utilizado para firmar y cifrar digitalmente el correo electrónico es RSA. El resumen del mensaje se cifra utilizando la clave privada conocida solo por el remitente del mensaje. Una vez que el destinatario del correo electrónico recibe el mensaje, él o ella usa la clave pública del remitente para descifrar el mensaje. Si el remitente fue falsificado, la clave pública no funcionaría ya que está vinculada a una clave privada única en particular. Si el mensaje se modificó durante la transmisión de alguna manera, el mensaje descifrado resultante se consideraría dañado. Las firmas digitales solo son confiables si el certificado utilizado para generarlas es confiable, lo que significa que se necesita una CA para garantizar la identidad del remitente y el destinatario.

Seguridad del correo electrónico, desde el remitente hasta su buzón

Por su diseño, SMTP no es seguro porque no autentica al remitente. Por lo tanto, un atacante lo suficientemente inteligente puede falsificar un correo electrónico de "aspecto seguro" utilizando Telnet.

Hay algunas iniciativas para hacer que SMTP sea más seguro: SPF y otros, servidores SMTP autenticados, PGP, etc ... pero como ninguno de ellos se ha extendido ampliamente, smtp no es confiable.

Además, tenga en cuenta que incluso si la fuente de correo electrónico muestra el mismo par de repetidores que tiene, el mismo remitente, etc., esto no hará que el correo electrónico sea seguro porque el atacante podría controlar su buzón de correo correspondiente debido a:

• una fuga en un sitio público donde su corresponsal utilizó el mismo correo electrónico dirección y la misma contraseña que la cuenta de correo electrónico para registrarse.

• Un ataque de fuerza bruta, una vulnerabilidad en el software de correo electrónico FAI, un malware en su computadora.

• alguien que está secuestrando su sesión (siempre cierra la computadora si vas a fumar un cigarrillo).

• Un hombre apunta un arma frente a él y le dice que escriba ese correo electrónico.

La respuesta es claramente NO :) (y sí, en realidad, todo tipo de comunicación no es segura)

Seguridad del correo electrónico, en su buzón (agregado debido a la edición de la pregunta)

Dado que la pregunta original ha evolucionado, sigamos respondiendo ;-)

Como usted dice, un correo electrónico puede incrustar código malicioso para explotar una vulnerabilidad en su MUA. Podemos clasificar las vulnerabilidades en dos categorías:

• Vulnerabilidades en el renderizador de HTML
• Vulnerabilidades en el sobre del correo electrónico (básicamente, encabezados analizando, etc.)

Deseo que, hoy en día, la mayoría de los códigos MUA incorporen un código robusto y mejorado para el análisis del sobre del correo electrónico. Como el sobre no ha cambiado durante décadas y es bastante básico (< nombre del encabezado & gt ;: < header value >) podemos esperar que esta parte sea segura. Pero solo "esperanza" ... tenga en cuenta que la regresión se introduce todos los días en todo tipo de software (consulte CVE-2007-6165 y CVE-2006-0395, por ejemplo).

Y también recuerda que no se publican todas las vulnerabilidades, por lo que se puede utilizar un exploit desconocido para abusar de tu cliente de correo electrónico.

Para terminar, lo peor y más peligroso es el motor de procesamiento de HTML: dado que está en constante evolución, el código también evoluciona y un atacante podría intentar explotar algunas vulnerabilidades en este software específico. El correo electrónico HTML es, en mi humilde opinión, la parte más peligrosa del correo electrónico.

Inspeccionar .eml te ayudará a descubrir los intentos más obvios de aprovechar cualquier vulnerabilidad: encabezados con formato incorrecto, adjuntos con nombres extraños (big_b00bs.jpg.exe)

Pero como el vector de ataque puede ser muchas otras cosas, creo que esto todavía no es suficiente para considerar un correo electrónico seguro .

Pero si:

• inhabilitas la representación HTML.
• inhabilitas la visualización de imágenes.
• eres cauteloso con el apego.
• utiliza un antivirus (se prefiere el lado del servidor) en su cadena de correo electrónico.
• usas un cliente de correo electrónico aislado.

Estás como 90% seguro :)