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

Continuidad de negocio. What the "FAQ"?


Llamémoslo "continuidad de negocio", "recuperación de desastres", "gestión de continuidad operacional", "preparación de emergencias", "disaster recovery", "business continuity", "resiliency planning", "business recovery", "emergency management", "continuity programs", ... y, por supuesto, todas las combinaciones intermedias. Todo ello aderezado con un buen número de acrónimos del tipo: BCP, BCM, DRP, CM, BIA, IR, ...

Entre el material que uso para dar formación sobre BCP tengo una "slide" muy bonita (está mal que yo lo diga) para resumir la respuesta de una organización ante un desastre. Así que he pensado colgar aquí una versión resumida (más gráfica) de la mencionada slide y comentar una serie de cuestiones recurrentes (FAQ) que aparecen siempre que presentamos un plan de continuidad (BCP o "business continuity plan").

Mi FAQ particular sobre BCP es el siguiente decálogo de 10 puntos (casualmente):
  • Los desastres son, por definición, imprevistos y difícilmente repetibles. Es difícil preparar un desastre concreto porque no se suelen anunciar y no se repiten frecuentemente. "No podemos quemar un rascacielos todos los sábados por la tarde para garantizar que la organización está entrenada ante esta situación".
  • El comité de crisis debe tomar el control de la situación lo antes posible. Toda la información sobre el incidente debe llegar al "puesto de mando" (o "torre de control"), todas las decisiones sobre el incidente deben salir del "puesto de mando" y todas las comunicaciones hacia el exterior deben ser supervisadas por el comité de crisis. "En resumen, el comité de crisis se come el marrón del desastre".
  • El objetivo principal del comité de crisis es recuperar la actividad de la empresa lo antes posible. Estrictamente hablando, el objetivo es recuperar el nivel de servicio de la organización. 
  • Son objetivos secundarios del comité de crisis: evitar crisis de reputación, aminorar el impacto en clientes y proveedores, controlar los costes económicos y organizativos de la crisis. Importante tener en cuenta que estos objetivos secundarios son, eso, menos importantes que el objetivo principal.
  • Durante el funcionamiento en contingencia la actividad debe ser percibida como "normal" desde el exterior (clientes, proveedores, etc.). El cliente debe percibir que recibe la atención habitual, aunque "es normal que los empleados estén jodidos durante la contingencia: cambio de ubicación, falta de comodidades, limitación de espacio, recursos, etc".
  • La vuelta a la normalidad no significa, necesariamente, volver a la situación anterior al desastre. No siempre, pero es habitual que durante la recuperación de la actividad se aproveche para optimizar procesos, actualizar plataformas tecnológicas, etc. "No es realista construir otra torre igual de grande, igual de obsoleta e igual de insegura en el mismo sitio para poder afirmar que se ha vuelto a la normalidad". 
  • "Wait and see" (esperar y ver) es siempre una opción. Todos los procesos imprevistos que requieren tomar una decisión admiten, de alguna manera, aplazar la decisión. Lo correcto, sin embargo, suele ser empezar a hacer lo que haya que hacer lo antes posible. "A nadie le dieron nunca una medalla por no hacer nada. En general, no hacer nada significa que si aciertas nadie te lo agradece y si fallas te vas a comer el marrón tú solo".
  • Todas las acciones del comité de crisis deben ser comunicadas. No sirve para nada tomar decisiones si no se comunican. "Los miembros del comité no suelen caracterizarse por ejecutar sus propias decisiones directamente, así que, al menos, necesitan comunicar sus decisiones para que alguien las ejecute".
  • El comité de crisis debe estar activo 24x7 hasta que se restablezca el funcionamiento normal de la organización. Siempre es posible utilizar algún mecanismo de turnos, atención "on call", ampliar el comité con nuevos miembros, etc. "En última instancia, este requisito es un incentivo para resolver la crisis lo antes posible".
  • La respuesta al desastre termina cuando, una vez restablecida la operación normal, se presenta un informe "post mortem" del incidente. El informe debe incluir: auditoria de los gastos incurridos durante el desastre y la recuperación, impacto en los clientes, valoración de la comunicación interna y externa durante la crisis, etc. "Es muy habitual incurrir en gastos no justificados o injustificables durante una crisis. También es, de alguna manera, inevitable".
Y éste es mi decálogo. medio irónico medio serio.

<Continuidad de negocio. What the FAQ? />

Hola, me llamo Javier Tobal y he comprado un billete en la web de Renfe

"Hola, me llamo Javier Tobal y he comprado un billete en la web de Renfe". Esto no debería ser noticia, pero esta vez me fijé en un detalle que me había pasado desapercibido anteriormente o, tal vez, sea una "mejora" introducida recientemente.


La cuestión es que Renfe ha implementado un mecanismo de autocompletar para algunos campos: población, calle y, también y sorprendentemente, para los campos nombre y apellidos!!! Esto me dejó anonadado, desconcertado y, como se puede ver en mi tuit, contrariado.

Las principales "pegas" que le pongo a esta funcionalidad:
  • El nombre es un valor único, personal. ¿qué sentido tiene que una aplicación informática me dé a elegir el nombre entre una lista de posibles nombres?
  • Todo el mundo sabe escribir su nombre. Hasta mi hijo de 3 años lo hace.
  • No hay nombres más importantes que otros. Me imagino al señor "Rodrigues" preguntando "¿por qué me debería apellidar "Rodríguez"?
  • La web de Renfe reconoce mi apellido (sorprendente) pero me lo cambia por "Tobalina" cuando pulso el tabulador. Esto pasa porque el autocompletar está ordenado por frecuencia del nombre y selecciona el primero de la lista. 

Pero lo que al principio parecía peor, o al menos más heterodoxo, es que los datos (nombres o apellidos) parecían extraerse de la base de datos de clientes. Sólo así se explicaría que aparecieran apellidos aparentemente raros y no aparecieran otros más populares. En mi caso, tengo un nombre muy común (300.000 en España) y un apellido relativamente raro (500 en España) pero Renfe conoce ambos. Hice unas pruebas manuales buscando un caso que confirmara mi teoría.



Y como así no conseguí nada concluyente, busqué la manera de automatizar esta investigación. Al final, la web usa un método en el servidor llamado "nombresManagerAjax.getNombresFrecuentes.dwr" que devuelve la lista de elementos para el autocompletar.

Aquí se ve cómo funciona:
Remote Address:213.144.49.57:443
Request URL:https://venta.renfe.com/vol/dwr/call/plaincall/nombresManagerAjax.getNombresFrecuentes.dwr
Request Method:POST
Status Code:200 OK

Request Headers
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:es,en-US;q=0.8,en;q=0.6
Connection:keep-alive
Content-Length:270
Content-Type:text/plain
Cookie:tipoUsuario=N; url_logout=/vol/index.do; tipoUsuario=N; org.springframework.web.servlet.i18n.CookieLocaleResolver.LOCALE=es_ES; __g_u=202999812043209_0; JSESSIONID=0000C560QoOyAIi2PyCr_modONr:16dv7ekdi; __g_c=a%3A1%7Cb%3A3; s_cc=true; s_sq=%5B%5BB%5D%5D; s_fid=38BB206B580BA00C-03798198EB657DDB; s_nr=1401562262384-Repeat; gpv_p6=Venta%3ARegistro%20Cliente
Host:venta.renfe.com
Origin:https://venta.renfe.com
Referer:https://venta.renfe.com/vol/datosComprador.do
User-Agent:Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36

Request Payload
callCount=1
page=/vol/datosComprador.do
httpSessionId=0000C560QoOyAIi2PyCr_modONr:16dv7ekdi
scriptSessionId=C93936BC746559589B085F596EBEA0E1804
c0-scriptName=nombresManagerAjax
c0-methodName=getNombresFrecuentes
c0-id=0
c0-param0=string:EIL
c0-param1=string:
batchId=75

Response
Connection:Keep-Alive
Content-Language:es-ES
Content-Length:131
Content-Type:text/javascript;charset=ISO-8859-1
Date:Sat, 31 May 2014 18:53:18 GMT
Keep-Alive:timeout=10, max=98
throw 'allowScriptTagRemoting is false.';
//#DWR-INSERT
//#DWR-REPLY
dwr.engine._remoteHandleCallback('75','0',["EILEEN","EILA"]);
Una vez descubierto cómo se hace la consulta, se podría "machacar" este método para obtener todos los nombres que devuelve el método "getNombresFrecuentes.dwr".
Pero no hizo falta desarrollar ningún script, en seguida se comprueba que lo que apuntaba Alejandro Ramos (@aramosf) en Twitter era la solución. Los programadores de la web de Renfe han cargado las estadísticas del INE de nombres y apellidos más frecuentes en España. En concreto han cogido los nombres y apellidos que tienen una frecuencia superior a 500.

En resumen, aunque no me gusta esta funcionalidad se puede comprobar que los nombres y apellidos no salen de la base de datos de clientes, sino de las estadísticas públicas del INE.


<Hola, me llamo Javier Tobal y he comprado un billete en la web de Renfe /> 

El "efecto CSI" y los forenses informáticos

Descubro gracias a un tuit de David Maeztu (@davidmaeztu) un artículo de Inés Vila (@i_vila) en lainformacion.com: No hay usuarios anónimos en Twitter: los peritos los identifican fácilmente

En el artículo, "un perito judicial tecnológico que no quiere revelar su identidad" describe cómo se descubre al autor de un tuit siguiendo unos "sencillos" pasos: identificar el tuit, pedir a Twitter la IP que envió el tuit, solicitar una orden judicial para requerir al ISP que identifique al usuario (nombre, apellidos, dirección), acudir al domicilio del sospechoso, intervenir el dispositivo utilizado y, voilá, encontrar en el cacharro las pruebas definitivas de la autoría del mensaje.

Bueno, el anónimo colega (espero que sin mala fe) está planteando una situación utópica bastante lejana de la realidad.


Por una parte, sí hay mensajes en Twitter anónimos. Recientemente en relación a la operación "Araña", la Guardia Cívil reconoció que había 200 usuarios anónimos de Twitter que no habían podido identificar (http://politica.elpais.com/politica/2014/05/01/actualidad/1398960953_590117.html)

En mi respuesta en Twitter, puse varios ejemplos de cómo poner tuits anónimos en Internet (o cómo conseguir, en general, acceso anónimo a Internet):
1. Tarjetas SIMs prepago con servicio de datos. Pueden ser tarjetas de cualquier operador del mundo. Hay países donde se puede conseguir una tarjeta SIM en una máquina de "vending" sin ningún tipo de identificación y, en España, hay gente que vende tarjetas SIM sin solicitar el DNI.
2. Conexiones anónimas en redes WIFI: WIFI públicas, obteniendo claves de WIFI privadas o suplantando la conexión de otros usuarios conectados.
3. Ordenadores públicos: en bibliotecas, en ayuntamientos, en cibercafés, en centros de trabajo (tipo WorkCenter).
4. Conectando un ordenador a cualquiera de esos puertos Ethernet que son tan accesibles (aeropuertos, hospitales, ministerios, etc.) y que muchas veces permiten acceder a Internet (más o menos fácilmente).

El efecto CSI
Pero en mi opinión, lo peor de este artículo es que alimenta el "efecto CSI" que tanto daña la actividad de los peritos.
... la serie CSI (y otras) tienden a convencer a los miembros del jurado que los forenses pueden siempre resolver todos los casos. En otras palabras, ahora esperan que eso ocurra. Estas expectativas irreales pueden provocar veredictos erróneos. El jurado podría absolver a una persona culpable simplemente porque no se puede presentar una evidencia científica concluyente. El jurado puede presuponer que si el acusado es culpable siempre habrá algún tipo de evidencia científica que lo demuestre. (John Sammons, "The basics of digital forensics", 2012. Traducción propia)

Parece ser que el primero que definió el término "Efecto CSI" fue Richard Saferstein en relación a los forenses tradicionales (huellas dactilares, balística, etc.).

Creo que artículos como el mencionado donde un colega anónimo afirma que no hay actividad anónima en Internet tiene, al menos, dos graves problemas:
- lo que cuenta no es cierto (esto ya es bastante descalificador), y
- transmite una sensación de control de la actividad en Internet que es irreal (incluso con la colaboración de jueces y fuerzas de seguridad).

Y luego somos los demás profesionales los que tenemos que responder preguntas peregrinas del tipo "¿cómo que no se puede saber quién usó este ordenador hace 10 años?"

<El "efecto CSI" y los forenses informáticos />





Garmin Vivofit. Mini-reversing

Me compré hace un mes una "pulsera de fitness" Garmin Vivofit que sirve para medir algunos parámetros de tu actividad física diaria: pasos realizados, tiempo inactivo, kilómetros recorridos, horas de sueño, calorías. También da la hora y te avisa con una barra de progreso de color rojo del tiempo que llevas parado. En la foto se ve la raya roja: el primer segmento, el largo, representa una hora de "inactividad", y cada nuevo segmento pequeño son 15 minutos más sin movimiento. Cuando la barra se completa sabes que llevas dos horas sin mover el culo. 

A los dos días ya tenía el análisis completo de mi actividad física:
- Ando bastante más del objetivo marcado (este valor cambia cada día y el algoritmo que lo calcula es "secreto")
- Paso mucho tiempo sentado (soy informático, ¿qué esperas?)
- Duermo poco (sign of the times)

Mi Vivofit en la muñeca y el adaptador ANT+  en el portátil

Así que en dos días descubrí que había contratado un consultor en forma de pulsera: te cobra 100€ por decirte de forma bonita lo que ya sabías hace tiempo.

Luego me puse a analizar cómo funciona la pulsera y a hacer un poco de "reversing". Sólo un poco. La pulsera se sincroniza con el servicio web (en "la nube") Garmin Connect donde deja los datos, se muestran los gráficos y, además, permite configurar el dispositivo (ponerlo en hora, actualizar el software, indicar las "pantallas" que quieres ver, etc.). Sin esta comunicación el cacharro no sirve para nada más que para ver la hora. Hay otros dispositivos de Garmin que usan el mismo servicio, por ejemplo relojes de entrenamiento, monitores cardíacos, etc.

Resumen de mi actividad en Garmin Connect

Configuración del dispositivo en Garmin Connect

Para todo esto, la pulsera necesita conectarse usando un ordenador o un móvil que tenga Bluetooth 4.0 o ANT+. Cada dispositivo tiene un ID único (3880920587, en mi caso) y cada usuario de Garmin tiene otro ID único. Así que tienes que dar de alta un usuario y cuando recibes la pulsera emparejar dispositivo y usuario. La pulsera no se conecta automáticamente, hay que forzar la sincronización cuando el dispositivo tenga a su alcance el móvil o el ordenador con el que está emparejado. La verdad es que funciona bastante bien.

¿cómo funciona esta comunicación?

Un mecanismo sencillo basado en HTTP. Cada vez que se inicia la sincroniación, la Vivofit pregunta al servidor (connectapi.garmin.com) si tiene "algo" pendiente. Para ello, envía su identificador.
VIVOFIT (pulsera) -> GARMIN (web)

GET /device-service/devicemessage/messages/?device_id=3880920587 HTTP/1.1
a lo que, en este caso, el servidor responde que no hay nada pendiente. Imagino que aquí se notificarán los cambios de configuración o algo importante. No es el caso de la actualización de software de la pulsera que se realiza de otra manera:
GARMIN -> VIVOFIT
{"serviceHost":"http://connectapi.garmin.com/","numOfMessages":0,"messages":[]}
A continuación, la Vivofit pregunta por la configuración para dejar los datos registrados. Otra vez, el ID de la pulsera sirve de clave.
VIVOFIT -> GARMIN

GET /UploadConfigurationService/UnitUploadSettings/3880920587?clientId=express-windows HTTP/1.1
a lo que, esta vez, el servidor responde:
GARMIN -> VIVOFIT
[...] 
{"DataTypes":[{"DataTypeName":"FIT_TYPE_32","UploadLocations":[{"Url":"http://connectapi.garmin.com/upload-service/upload/wellness","RequiresAuthentication":true,"RequiresUserConsent":true}],"ExpectedSources":[]}]}
Y en esta dirección la Vivofit "postea" los datos de actividad (que no he intentado descifrar)
VIVOFIT -> GARMIN

POST /upload-service/upload/wellness HTTP/1.1
[...]
Content-Type: application/octet-stream
Host: connectapi.garmin.com
Content-Length: 331
[...]
Este es, por ejemplo, uno de los bloques enviados. En esta prueba se enviaron 11 bloques de unos 2000 bytes de media cada bloque. Intuyo que cada bloque son los datos de un día:
0E 10 EC 03 3B 01 00 00 2E 46 49 54 E1 7B 40 00 00 00 00 07 03 04 8C 04 04 86 01 02 84 02 02 84 05 02 84 06 02 84 00 01 00 00 0B 26 52 E7 04 DD A5 2D 01 00 2D 07 03 00 00 00 20 40 00 00 17 00 07 FD 04 86 03 04 8C 02 02 84 04 02 84 05 02 84 0A 02 84 06 01 02 00 A0 8E B2 2D 0B 26 52 E7 01 00 2D 07 F0 00 EC 05 01 41 00 00 37 00 05 FD 04 86 03 04 86 04 04 86 1D 02 84 05 01 00 43 00 00 37 00 02 1A 02 84 18 01 0D 47 00 00 7D 00 03 FD 04 86 01 10 02 02 20 84 40 00 00 67 00 07 FD 04 86 00 04 86 03 04 84 04 04 84 07 08 86 05 02 84 01 02 00 00 04 DD A5 2D 24 F9 A5 2D 59 20 85 30 3C 01 E4 03 15 29 00 00 15 29 00 00 AE 08 06 01 01 04 DD A5 2D 1D 01 00 00 90 65 00 00 27 00 06 01 04 DD A5 2D 4C 05 00 00 50 BD 01 00 27 00 01 03 04 DD 08 01 04 DD A5 2D 1D 01 00 00 90 65 00 00 27 00 06 01 04 DD A5 2D 4C 05 00 00 50 BD 01 00 27 00 01 07 04 DD A5 2D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 28 32

La actualización de software también es interesante. La Vivofit envía un POST con un XML que contiene la información de su configuración y versión actual de software.
VIVOFIT -> GARMINPOST /Rce/ProtobufApi/SoftwareUpdateService/GetAllUnitSoftwareUpdates HTTP/1.1
[...]
<Device xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.garmin.com/xmlschemas/GarminDevice/v2 http://www.garmin.com/xmlschemas/GarminDevicev2.xsd" xmlns="http://www.garmin.com/xmlschemas/GarminDevice/v2">
<Model>
<PartNumber>006-B1837-00</PartNumber>
<SoftwareVersion>240</SoftwareVersion>
<Description>vívofit</Description>
</Model>
<Id>3880920587</Id>
[...]

<UpdateFile>
<PartNumber>006-B1837-00</PartNumber>
<Version>
<Major>2</Major>
<Minor>40</Minor>

</Version>
</UpdateFile>
<UpdateFile>
<PartNumber>006-B1837-01</PartNumber>
<Version>
<Major>0</Major>
<Minor>0</Minor>
</Version>
</UpdateFile>
</MassStorageMode>
</Device>
Es decir, que la Vivofit con ID 3880920587 y número de serie 006-B1837-00 tiene la versión de software 2.40. A lo que el servidor responde "actualízate a la versión 2.50, anda". Y le pasa una URL para descargar la nueva versión.
HTTP/1.1 200 OK
[...]

¤
AVigorous activity with HR monitor connected will clear Move bars.
8Fixed calories displayed when connected to a HR monitor.
SFixed issue with extra activities being created when disconnecting from HR monitor.
6Fixed issue with auto goal getting seeded incorrectly.
>Fixed heart rate based calories missing in end-of-day message.
Display heart rate zone '0'. vivofit *http://www.garmin.com/gcdfiles/license.txt" vivofit_250.( 2] 3http://download.garmin.com/software/vivofit_250.rgn 9bd7eae9893e8d1f5182ab7cd7a88c98 Üô B 006-B1837-00J 2.50P `
Lógicamente, lo siguiente que hace la Vivofit es descargar desde esa dirección el nuevo firmware. 
VIVOFIT -> GARMIN

GET /software/vivofit_250.rgn HTTP/1.1
Host: download.garmin.com
Connection: Keep-Alive

HTTP/1.1 200 OK
Server: Apache
ETag: "9bd7eae9893e8d1f5182ab7cd7a88c98:1396559803"
Content-MD5: m9fq6Yk+jR9Rgqt816iMmA==
Last-Modified: Thu, 03 Apr 2014 21:16:43 GMT
Accept-Ranges: bytes
Content-Length: 64092
Content-Type: text/plain
Date: Thu, 17 Apr 2014 13:45:46 GMT
Connection: keep-alive
4B 70 47 72 64 00 02 00 00 00 44 64 00 1B 00 00 00 41 C8 00 53 51 41 00 4F 63 74 20 32 35 20 31 39 39 39 00 31 34 3A 31 36 3A 31 33 00 2A FA 00 00 52 0E 00 00 00 00 00 20 FA 00 00 00 BF 01 48 01 49 08 47 14 FE 02 00 7D FD 02 00 40 BA 70 47 40 BA 70 47 40 BA 70 47 C0 BA 70 47 C0 BA 70 47 C0 BA 70 47 08 B5 EF F3 10 80 00 28 03 D0 00 20 69 46 08 70 09 E0 68 46 12 DF 00 28 05 D1 68 46 00 78 00 28 01 D0 01 20 08 BD 00 20 08 BD 08 B5 FF F7 E8 FF 00 28 02 D0 68 46 2B DF 03 E0 EF F3 10 80 00 90 72 B6 00 98 08 BD EF F3 05 80 C0 05 00 D0 01 20 70 47 10 B5 04 46 FF F7 D3 FF 00 28 02 D0 E0 B2 2C DF 10 BD 84 F3 10 88 10 BD 00 00 [...]
El fichero en formato RGN ocupa 64 KB. Encontré en Internet una herramienta para editar estos ficheros. La herramienta se llama RGN_tool
RGN_tool

Hasta aquí ha llegado mi análisis del funcionamiento interno de la Garmin Vivofit. Cosas que no he estudiado de momento (pero me gustaría):
- estructura de los datos de actividad (trolear al sistema para decirle que hoy he andado 520 km...),
- estructura del firmware de la pulsera (crear mi propia versión de firmaware. Esto me gustaría....),
- mecanismo de la sincronización de la configuración del dispositivo (formato de hora, pantallas que se muestran, etc.)
- mecanismo de sincronización de tiempo y precisión del mismo.

<Garmin Vivofit. Mini-reversing />

Rooted CON 2014. Día 3 (y último). Fotos y tuits.



Manu Quintans & Frank Ruiz
50 shades of crimeware

Hugo Teso
Profundizando en la seguridad de la aviación

José Pico & David Perez
Atacando 3G

Borja Berástegui
Handware hacking. Si hay un 'input' hay peligro

Juan Vazquez & Julián Vilas
Tú a Boston Barcelona y yo a California Tejas. A patadas con mi SCADA!

Aladdin Gurbanov
Magnetic Road

Raúl Siles
iOS: Regreso al futuro

Jaime Sánchez & Pablo San Emeterio
WhatsApp: mentiras y cintas de video

FOTOS

El verdadero hacker no lleva más que una libreta, un boli y una cámara

Aladdin lee su propia tarjeta y nos la enseña toda

Premiados los mejores ponentes de las 4 ediciones anteriores. Se autoaplauden

Asistencia multitudinaria

Telemadrid en la Rooted grabando una entradilla

Rooted CON 2014. Día 2. Fotos y tuits. ACTUALIZACIÓN

Resumen actualizado del día 2. TUITS y FOTOS

Jose Luis Verdeguer & Victor Seva
Secure Communications System

Joaquín Moreno Garijo
Forense a bajo nivel en Mac OS X

José Luis Quintero & Felix Estrada
Ciberguerra. De Juegos de Guerra a La Jungla 4

Jeremy Brown & David Seidman
Microsoft Vulnerability Research: How to be a finder as a vendor

Chema Alonso
Playing and Hacking with Digital Latches

Miguel Tarasco
Análisis WiFi de forma nativa en Windows

Andrés Tarasco
Ataques dirigidos con APTs Wi-Fi

Roberto Baratta
Monetización de seguridad: de más con menos a más con nada

Cesar Lorenzana & Javier Rodriguez
Por qué lo llaman APT´s cuando lo que quieren decir es dinero


FOTOS

Chema espera a que termine una pregunta

Taxi!

Demo llamada ¿segura? entre dos móviles

Jeremy "el de Microsoft".  Hacker mindset

Fuerzas del orden. Del congreso (izquierda) y de la calle (derecha)

Joaquin Moreno. El crack de MAC OS X

x1red+segura. Agradeciendo
A medias


Rooted CON 2014. Día 1. Tuits y fotos

Resumen telegráfico del primer día de la Rooted CON 2014. Muy telegráfico. Las fotos están al final.

Francisco Jesús Gómez & Carlos Juan Diaz
Sinfonier: Storm Builder for Security Investigations

Alfonso Muñoz
Ocultación de comunicaciones en lenguaje natural

Pau Oliva
Bypassing wifi pay-walls with Android

Antonio Ramos
Agilidad. La via a la seguridad

Raj Shah
The Kill Chain: A day in the life of an APT

Pablo González & Juan Antonio Calles
Cyberwar: Looking for... touchdown!

Alberto Cita
Skype sin Levita. Un análisis de seguridad y privacidad

Jorge Bermúdez
Los hackers son de Marte, los jueces son de Venus


FOTOS
Algunas fotos del día. 
Alberto Cita. ¿de qué me suena este nombre?

Asistentes asistiendo a la Rooted

Cármara SONY single. A mi NIKON le mola

Fiscal Bermúdez. Triunfador del día

Público cautivado (y cautivo)

I eat APTs for breakfast.
Mi versión: "I hate APTs before breakfast"

Ingenieros cambiando resolución de pantalla. La primera vez aún hacía gracia.

Organizadores frescos (eran las 10 am)

Momento demo de fluproject