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 />

Autenticidad de e-mail (I). Metodología

Un problema habitual que se nos plantea a los peritos judiciales informáticos es determinar la autenticidad de correos electrónicos (emails) presentados como prueba en un juicio. Por ser un problema recurrente es útil tener preparado el procedimiento a seguir.

Personalmente, mi aproximación tiene dos elementos: un enfoque formal (que llamaré "metodología") y un enfoque práctico (que llamaré "experiencias prácticas"). En esta primera entrada describiré la parte metodológica

¿Qué es un email "auténtico"?

En la práctica, el perito no puede afirmar que un email es auténtico sino que se "limita" a confirmar que el email presentado no presenta ninguna irregularidad que confirmase que no es auténtico. Parece un juego de lógica pero, en realidad, es un matiz importante.

Existen dos tipos de emails "no auténticos":

Manipulaciones: se trata de emails auténticos que en su día fueron enviados y que han sido modificados posteriormente para tergiversar su contenido. Ejemplos reales de manipulaciones: cambiar la fecha de envío del email, sustituir un adjunto contenido en el mensaje original por otro adjunto diferente, añadir un destinatario que no existía en el email original, etc.

Recreaciones: se trata de presentar como auténticos emails que nunca fueron enviados. Normalmente, las recreaciones se realizan a partir de un mensaje auténtico al que se le modifican los elementos principales (remitente, destinatarios, asunto del mensaje, fechas de envío, contenido del mensaje, etc.). 

Si no se detecta ninguna irregularidad después de un examen exhaustivo de todas las evidencias presentadas u obtenidas por otros medios, el perito podrá determinar que el email en cuestión no ha sido manipulado y, por tanto y salvo nuevas evidencias en contrario, se trata de un email "auténtico". 

Metodología para determinar la autenticidad de un mensaje de correo electrónico (email)

Estas son las principales actividades que, en la práctica, permiten afrontar el problema de determinar la autenticidad de un email.

1. Obtención del mensaje original en formato digital. La prueba pericial se realizará a partir de una evidencia que contenga el mensaje completo a analizar, descartando el análisis de copias impresas o reenvíos del mensaje. Una parte importante de la información a analizar está en la cabecera técnica del mismo y esta cabecera no aparece en los emails impresos. Por otra parte cuando se reenvía un email las cabeceras que aparecen son las correspondientes al reenvío, no al mensaje a analizar.
2. Obtención de fuentes adicionales de información relacionadas con el mensaje. La mejor opción para detectar posibles manipulaciones es disponer de informaciones coincidentes procedentes de fuentes diversas. Personalmente, mi búsqueda suele incluir:
1. Archivo contenedor del email a analizar. Estos archivos contenedores dependen de los clientes y servidores de correo electrónico. La mejor opción, porque tiene información más completa, consiste en extraer los mensajes del receptor o del servidor de correo del receptor.
2. Registros de actividad de los servidores de correo implicados en la transmisión del email a analizar.
3. Registros de actividad de los elementos de red por los que se ha cursado el tráfico asociado a la transmisión del email a analizar.
4. Unidades de almacenamiento donde el email en cuestión ha podido quedar almacenado (copias de back-up de los servidores, unidades externas, etc.). 
3. Análisis de los elementos de información obtenidos. Lógicamente, cuantas más fuentes se puedan obtener y analizar más fiable será el resultado del análisis.
1. Cabecera del mensaje a analizar (cabecera técnica). Contiene información muy importante que permite localizar incoherencias en caso de manipulación. Ejemplo de información presente en la cabecera: cuentas de correo, servidores de envío, recepción y tránsito, fecha y hora de los envíos entre servidores, etc.
2. Cuerpo del mensaje
3. Ficheros adjuntos
4. Metadatos del archivo contenedor
5. Metadatos de los ficheros adjuntos
4. Correlación de toda la información obtenida y búsqueda de parámetros incoherentes (fechas, tamaños, direcciones, cuentas, etc.). La presencia de incoherencias en esta información probaría la presencia de alteraciones o recreaciones (intencionadas o no) del email analizado.

El procedimiento descrito necesita, para su realización, de experiencia y conocimientos concretos relacionados con los sistemas implicados: servidores y clientes de correo electrónico, herramientas de análisis forense específico, herramientas de recuperación de datos, análisis de logs, herramientas ofimáticas que generan los tipos de adjuntos más comunes, etc. Además es necesario, por supuesto, conocer el funcionamiento y los estándares implicados: SMTP, POP3, IMAP, DNS, TCP/IP, etc.

Pero, desde mi punto de vista, lo más importante a la hora de analizar la autenticidad de uno (o varios) emails es disponer de capacidad para observar grandes volúmenes de información, encontrar incoherencias entre datos relacionado o detectar patrones definidos dentro de información que, en principio, debería ser aleatoria. 

En la próxima entrada, presentaré algunas experiencias prácticas describiendo cómo ha sido posible, en entornos reales, detectar emails manipulados. 

<Autenticidad de e-mail (I). Metodología />

Identificación mediante imágenes reflejadas en la pupila

La noticia en la prensa "generalista": [ABC] Las imágenes reflejadas en los ojos de un fotografiado pueden recuperarse.  
Luego está la fuente donde aparece el trabajo de Kerr Jenkins: [PLOS ONE] Identifiable Images of Bystanders Extracted from Corneal Reflections. Y la imaginación, el optimismo y/o la imprudencia del investigador se dispara afirmando que se puede recurrir a este sistema en casos de toma de rehenes o abusos sexuales infantiles para identificar a los autores a partir de los reflejos en los ojos de las fotografías de las víctimas. 


Aquí el vídeo "promocional":


Fuente del vídeo: Kerr Jenkins: [PLOS ONE] Identifiable Images of Bystanders Extracted from Corneal Reflections. 



Antes de seguir adelante, vamos a adelantar unos cuantos conceptos teóricos sobre la identificación de personas a partir de fotografías. 

"Reconocer" es la capacidad de nombrar indubitadamente (sin duda) a una persona que aparece en una imagen. Es decir, la persona de la imagen es conocida por el testigo (un amigo, un conocido o una persona famosa) y el testigo asocia la imagen a su conocido. Ejemplo: un guarda de seguridad está supervisando una cámara a la entrada de un edificio y reconoce a las personas que aparecen en pantalla ("ése es Federico García, tercera planta, contabilidad").
"Identificar", en este contexto, es la capacidad de determinar unívocamente la identidad de una persona desconocida que aparece en una imagen. Es decir, a partir de ese momento el observador podrá reconocer a esa persona en el futuro. Ejemplo: un guarda de seguridad está supervisando una cámara de la puerta de un centro comercial y es capaz de "quedarse con la cara" de una de las personas que aparecen en pantalla ("no le conozco pero si le vuelvo a ver seguro que le reconozco").

Habitualmente, cuando se montan sistemas de videovigilancia, se establece que para reconocer a una persona se necesita una imagen de la cara de 40x40 pixeles. Y para identificar a una persona sería necesaria una imagen de 90x90 pixeles. 

En el paper de Kerr Jenkins afirma que se puede reconocer a una persona a partir de una imagen de su rostro de 7x10 pixeles, según estudios anteriores. Y pone como ejemplo la siguiente imagen "icónica" de Barack Obama que tiene una resolución de 16x20. 

Por supuesto, este es un ejemplo muy tramposo porque es una imagen muy famosa que representa a una de las 5 personas vivas más famosas del mundo. 

Volvamos al artículo citado: ¿qué resolución tiene que tener la foto del sujeto víctima para ser capaces de identificar una persona reflejada en su pupila? Pues el propio estudio lo dice: en el experimento realizado hicieron una foto de 39 MPx (migapíxeles) a una distancia de 1 metro usando iluminación de estudio. 

Con este montaje consiguieron que en la pupila del sujeto fotografiado aparecieran refleajdos 5 rostros cuyo tamaño medio (en píxeles) era de 30x50. Estos ya son tamaños considerables.

Para que se vea con un ejemplo práctico he cogido cuatro fotos de cuatro famosos y las he escalado a diferentes tamaños, reescalando a continuación todas las imágenes al mismo tamaño para que se puedan comparar. He usado interpolación cúbica para evitar granularidad y el efecto de pixelado (exactamente igual que en el estudio de Kerr Jenkins). 

Las resoluciones son, respectivamente, 10x10, 30x30, 50x50 y 100x100.

Personalmente, creo que es imposible identificar a nadie con una imagen menor de 30x30. A partir de 50x50 se puede empezar a reconocer a la persona si su rostro nos resulta muy familiar y, por supuesto, la imagen es buena (frontal, con luz, etc.).

El estudio referido es demasiado optimista y, desde luego, sus resultados no se pueden aplicar a las imágenes de aficionados que se suben habitualmente a Internet (en redes sociales u otros servicios).


<Identificación mediante imágenes reflejadas en la pupila />

Belkasoft RamCapturer

Belkasoft RAMCapturer es, como su nombre indica, una herramienta de la empresa Belkasoft que realiza una captura de la información contenida en memoria. Funciona en plataformas MS Windows. Yo lo he probado en XP (sic), Win7 y Win8 pro con excelentes resultados. En todos los casos ha funcionado bien. Es un software gratuito de Belkasoft (no así la herramienta para analizar la información capturada) y, por supuesto, no requiere instalación.

Notas previas antes de usar RAMCapturer: para qué y para qué no 
¿para qué querría una persona capturar el contenido de la memoria de un ordenador? Muy buena pregunta. La respuesta críptica inmediata sería "hombre, para espiar lo que está haciendo el PC" y la réplica "ya, pero el PC hará lo que ordene la persona que lo está utilizando. Si lo estás usando tú, ya sabes lo que está haciendo (puede que no) y si no lo estás usando tú, estás espiando a su legítimo usuario (puede que no tan legítimo)". Vamos a comentar algunos ejemplos.

Cuándo usar RAMCapturer (por ejemplo):
Algunos casos de uso "legítimo":

• Perteneces a una fuerza de seguridad legítima (policía, guardia civil, ertzaina, mossos, etc.) entras en un domicilio con una orden de registro y encuentras un ordenador en funcionamiento. La buena práctica forense recomienda "tirar del cable" (desconectar corriente, quitar batería, quitar LAN, etc.) y ya veremos cómo recuperamos la información más tarde. Pero si en ese momento los "malos" están usando el PC, se quiere obtener toda la información que estén manejando y hay riesgo de que si se apaga se pierda información valiosa (por ejemplo, están chateando). En este caso se podría intentar un volcado de la memoria. 
• Eres usuario del ordenador y quieres analizar lo que está haciendo. Esto es típico cuando detectas que el ordenador se conecta a donde no debería, usa mucha CPU, etc. Lo normal aquí sería quitar el virus, recuperar una copia de seguridad de tu ordenador y actualizar el antivirus. Pero bueno, si te dedicas a la seguridad igual tienes curiosidad por ver lo que hace el troyano antes de eliminarlo.
• Eres el propietario legítimo del ordenador y quieres ver lo que está haciendo su usuario (o usuarios). Esto pasa cuando una empresa sospecha de lo que hace su empleado y le quieren pillar con las manos en la masa. Otro caso (que viví en primera persona): un servidor Windows se usaba como consola para administrar un sistema complejo (unos 50 servidores a los que se llegaba desde el servidor Windows). Todos los operadores, ingenieros, técnicos de sistemas, etc. se conectaban al PC con una VPN desde un lugar muy remoto y desde allí lanzaban sesiones X/WIN, Telnet, SSH, FTP, etc. Pues bien, al cliente no le gustó esto y nos pidió una auditoria de todo lo que estaba ejecutando el PC, qué conexiones tenía abiertas, quién estaba loggeado, etc. etc.

El volcado de memoria se debe completar con el pagefile.sys y el hiberfil.sys. Normalmente los peritos informáticos preferimos tirar del cable antes que usar la hibernación, aunque aquí también entran en consideración otros factores (legales, jurídicos, procedimentales, etc.). En USA, algunas buenas prácticas recomiendan hibernar el sistema antes de apagarlo bruscamente. Es lo que tienen las buenas prácticas, que no son universales.

Cuándo NO usar RAM capturer:
Algunas contraindicaciones aunque, como siempre, el sentido común ya dice lo que no se debe hacer:

• Para espiar a un compañero que se ha dejado el PC encendido y sin contraseña.
• Para espiar lo que ha hecho el usuario anterior cuando coges un ordenador compartido (por ejemplo, en una biblioteca pública).
• Para obtener una prueba que se va a presentar a juicio. Esto depende de la legislación de cada sitio pero, en general, una captura de memoria como prueba funciona bastante mal:
• Para capturar la memoria hay que ejecutar un software en el ordenador lo que supone que el perito tiene que manipular el sistema antes de obtener la prueba. 
• La captura no es reproducible. Dos capturas consecutivas (incluso separadas por un par de segundos) generan imágenes de memoria diferentes lo que impide contrastar el resultado.
• La captura incluye todos los datos en memoria por lo que la parte afectada podría alegar que el perito no ha restringido su búsqueda a la información relevante, que ha obtenido datos de carácter personal sin autorización previa y, al final, podría intentar anular la prueba.

Ejemplo de uso de RAMCapturer 

El funcionamiento es realmente sencillo. El programa tiene versión de 32 y de 64 bits. Cada versión tiene un ejecutable y un driver. No necesita instalación, sólo lanzar el exe y seguir las instrucciones.

Se elige el directorio de salida (mejor si es una unidad rápida). Aquí veis que lo he probado en un ordenador con sólo 4GB de RAM. Lógicamente el tamaño del fichero de salida depende del tamaño de la RAM. En este ordenador en concreto, usando el disco duro como salida la captura duró dos (2) minutos. 30 segundos cada Giga.

Cuando termina, nos deja un fichero con la extensión MEM y como nombre la fecha del día (y un contador a partir del segundo fichero del mismo día). El fichero no está comprimido, ni cifrado, ni nada de nada, es el contenido de la memoria tal cual.

Cómo usar la captura realizada

Hay varias herramientas que se pueden usar para analizar el fichero generado, mis preferidas son las siguientes (en realidad, las únicas que he probado con RAMCapturer):

• Belkasoft Evidence Center. De pago pero relativamente barata. Es el mismo desarrollador. Es una herramienta muy potente (tipo ENCASE) de la que hablaré en otro momento.
• HxD. O tu editor hexadecimal preferido. En este caso está bien conocer algo de ensamblador y del API de Windows.
• Strings. Hay versión en Windows de Mark Russinovich.

En el ejemplo mostrado, usando el comando "strings" he sido capaz de obtener:

• Sesiones "estándar": tanto del navegador IE como de Chrome como de Skype, incluso de Exchange/Outlook. Algunos programas protegen la memoria que usan pero en mis pruebas RAMCapturer obtuvo esta información sin problemas.
• Información de sesiones de incógnito de Chrome. Tenía abierta una ventana en modo incógnito con una sesión de Hotmail y en la captura estaba la sesión, usuario y password. La navegación de incógnito tampoco se resiste al volcado de memoria (lógicamente).
• Información de una sesión de Facebook que tenía en un navegador Firefox que tenía en ejecución en una máquina virtual (Virtual Box) que estaba ejecutando una distribución Linux: BugTraq. Como en euskera, esta frase se entiende mejor si se lee del final al principio.

Por supuesto, para este ejemplo no me recorrí toda la información obtenida (la salida de "strings" ocupa 1,5GB). Para simplificar, preparé el escenario, saqué las cadenas a un archivo y busqué directamente las credenciales que ya conocía. Hacer un análisis "a lo bruto" sin saber lo que se busca es prácticamente inviable sin un software de apoyo.

Lo dicho, herramienta muy interesante aunque, probablemente, de poca utilidad en la vida real.

</Belkasoft RamCapturer>