Autenticidad de e-mail (II). Experiencias prácticas

En la entrada anterior (Metodología) se presentó una metodología para determinar la autenticidad de mensajes de correo electrónico (emails). Resumiendo aquella entrada, el perito puede confirmar la manipulación (o recreación) de un mensaje de correo electrónico si encuentra alguna incoherencia en el contenido del mismo.
Así que la labor consiste en extender toda la información de los mensajes a analizar y buscar "cosas raras". En esta entrada voy a presentar una lista con ejemplos de estas incoherencias que mencionaba anteriormente. Por supuesto no es una lista exhaustiva, ni aplicable directamente a cualquier situación, pero sí son consejos útiles extraídos de casos reales afrontados por este perito.
  • Capturar los mensajes en el receptor, no en el emisor: los emails van acumulando cabeceras durante el tránsito entre servidores, por eso el mensaje recibido tiene todas las cabeceras de interés. Si tomásemos el mensaje "enviado" sólo veríamos la fecha de envío al servidor SMTP.
  • Elegir el mejor formato disponible para procesar el email: lógicamente, hay que elegir un formato que mantenga las cabeceras técnicas. Por ejemplo, en Outlook es mejor exportar los mensajes como MSG que EML. 
  • Convertir y ordenar todas las fechas y horas encontradas en las cabeceras: personalmente, antes de analizar las fechas, convierto todas las fechas a UTC. Una vez convertidas todas las fechas hay que verificar que la secuencia es correcta, es decir, que el mensaje ha pasado por el servidor saliente "antes" de llegar al siguiente servidor o al servidor destino. 
  • Reconstruir la secuencia lógica de creación de todos los elementos: normalmente, los mensajes contienen varios elementos fechados: ficheros adjuntos, imágenes utilizadas como firma en mensajes con formato, etc. Si un mensaje contiene un adjunto (un PDF, por ejemplo) la fecha de creación del adjunto debe ser anterior a la fecha de envío. Ojo: las fechas de creación de adjuntos suelen estar expresadas en la hora local del ordenador donde fueron creados.
  • Sospechar de fechas coincidentes: si estamos analizando una serie de varios mensajes, es sospechoso que varios de estos mensajes coincidan en la fecha de envío (minutos y segundos, por ejemplo). Cuando se recrean muchos mensajes (se construyen desde cero con el fin de aportar pruebas falsas) se suele partir de una plantilla base que se va modificando para cada uno de los falsos mensajes creado. En este caso, es habitual que no se modifiquen todas las cabeceras por lo que suelen aparecer patrones repetitivos sospechosos. 
En el ejemplo siguiente (convenientemente manipulado y anonimizado) se pueden ver varias incongruencias con las fechas registradas en la cabecera: 
    • todas las horas indicadas coinciden en el segundo "08", 
    • el mensaje llega al servidor SMTP justo una hora y un minuto después de ser enviado,
    • el mensaje llega al servidor intermedio de gmail una hora antes de ser enviado ("16 Dec 2011 13:22:08 +0100")
    • el servicio de Spam intenta procesar el mensaje un día antes de ser enviado, además de que el 15 de diciembre de 2011 no fue viernes ("Fri, 15 Dec 2011 13:27:08 +0200")
Received: from authsmtp.register.it ([88.88.88.88])
       by cromasms.com (cromasms.com [80.80.80.80])
       (MDaemon.PRO.v7.1.0.R)
       with ESMTP id md50015530304.msg
       for <gggggggg@dominio1.es>; Fri, 16 Dec 2011 13:23:08 -0000
Received: (qmail 21152 invoked from network); 16 Dec 2011 13:22:08 +0100
Received: from unknown (HELO MyPC) (smtp@dominio2.net@81.81.81.81)
  by authsmtp.register.it with ESMTPA; 16 Dec 2011 13:21:08 -0000
Return-Path: <jjjjjjjj@dominio2.net>
Return-Receipt-To: "J J JJJ" <jjjjjjjj@dominio2.net>
From: " J J JJJ " <jjjjjjjj@dominio2.net>
To: "'G GGGGG'" <gggggggg@dominio1.es>
Subject: Asunto-Asunto
Date: Fri, 16 Dec 2011 13:20:08 +0100
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAIKbhNI7ijtPqgFnlYjDyprCgAAAEAAAABnc4asXvB1BmhrZS95aLHYBAAAAAA==@dominio2.net>
MIME-Version: 1.0
Content-Type: multipart/mixed;
       boundary="----=_NextPart_000_021D_01CEFBD1.30E76210"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acy77Qy7ej+XwCNxSSm6hcYsAa8nBQ==
Content-Language: es
X-Spam-Processed: cromasms.com, Fri, 15 Dec 2011 13:27:08 +0200    (not processed: message size (7162935) exceeds max size (512000))
X-MDRemoteIP: 88.88.88.88
X-Return-Path: jjjjjjjj@dominio2.net
X-MDaemon-Deliver-To: gggggggg@dominio1.es
Disposition-Notification-To: " J J JJJ " <jjjjjjjj@dominio2.net>
  • Verificar todas las direcciones IP: Las cabeceras de los emails contienen muchas direcciones IP, incluyendo el ordenador que envió el mensaje y los servidores intermedios. Hay que comprobar que las direcciones IP son "plausibles", es decir, que la ubicación geográfica es lógica o, si tenemos esa información, que la IP pertenece al ISP del supuesto remitente.
  • Analizar el contexto histórico (WHOIS, DNS, etc.): es habitual (al menos en España) tener que analizar correos electrónicos que fueron enviados hace años. El mes pasado tuve que analizar unos emails de 2009! En este caso, verificar las IP y servidores utilizados mediante consultas estándar WHOIS y DNS no es correcto. Hay que utilizar registros históricos que nos resuelvan la consulta con la información de la fecha cuando ocurrieron los hechos. En este sentido, recomiendo utilizar servicios como http://www.domaintools.com/  o http://dnshistory.org/
  • Revisar los metadatos de los archivos adjuntos: al analizar mensajes manipulados, es habitual encontrar incoherencias en los metadatos de archivos adjuntos. Por ejemplo: 
    • Ficheros PDF con versiones que no existían cuando supuestamente se crearon (la versión 1.6 de PDF está disponible desde 2.004, luego no puede existir un fichero PDF v1.6 en un email de 2.002). 
    • Documento creado con una versión de software posterior a la supuesta fecha de envío (por ejemplo, el formato DOCX de Microsoft está comercialmente disponible desde Micosoft Office 2007)
    • Autores "sospechosos". Por ejemplo, hace unos años analicé unos PDF cuyo autor coincidía, casualmente, con el nombre del abogado que defendía el caso. 
En el ejemplo siguiente (convenientemente manipulado y anonimizado) se pueden ver varios datos relevantes: 
  • la versión de PDF, v1.4, está disponible desde 2001 (Acrobat 5.0)
  • Windows Vista x64 sólo está disponible desde 2007
  • XLSX es una extensión que apareció por primera vez con la versión Office 2007
  • la fecha de creación está mal formada y, por lo visto anteriormente, este documento no pudo ser creado en 2.005. 
Title:          Balance-2006.xlsx
Author:         jhernandez
Creator:        Balance-2006.xlsx
Producer:       doPDF   Ver 6.1 Build 286 (Windows Vista  x64)
CreationDate:   25/01/05 15:36:08
Tagged:         no
Form:           none
Pages:          1
Encrypted:      no
Page size:      842 x 595 pts (A4) (rotated 0 degrees)
File size:      535589 bytes
Optimized:      no
PDF version:    1.4


<Autenticidad de e-mail (II). Experiencias prácticas />

1 comentario:

  1. Hola,
    Ante todo felicitarte por el artículo, puesto que me sirve de guía en un caso de ejemplo. Supongamos que una empresa privada pide certificar el envoi de un e-mail a otra empresa. La cabecera del mail no contiene información. ¿Cómo se puede verificar que ha sido enviado?. ¿Mirando los logs del servidor de correo?¿Como puedo seguir el recorrido del correo internamente? ¿es decir puede ser que se haya quedado en algún firewall, etc?.
    Gracias por tu colaboración.

    ResponderEliminar