Security Art Work

(Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.)

La entrada anterior (ver parte I, parte II, parte III y parte IV) había dejado la investigación en un punto clave: logramos acceder a la cuenta de iCloud de S.P.F, y ahora teníamos que ver si podíamos sacar algo de sus copias de seguridad (recordemos que el MacBook había sido sospechosamente reinstalado). La pantalla de entrada es algo similar a esta:

En función de lo que S.P.F. haya habilitado tanto en su iPhone como en su MacBook podremos recuperar más o menos información. Lo primero es verificar qué dispositivos están conectados a la cuenta de iCloud, por lo que accedemos a Settings -> Devices.

Un MacBook Pro, un iPhone 5, otro iPhone 5… ¡¿qué?! Ojipláticos comprobamos que al parecer tenemos un iPhone “extra” dentro de esta cuenta de iCloud. Vamos a obtener algo más de información pulsando sobre el dispositivo (la foto siguiente es un ejemplo de lo que aparecería).

Como podemos ver tenemos tanto la última fecha de copia de seguridad (en este caso, nunca), así como el número de serie y el IMEI (International Mobile System Equipment Identity), que nos van a servir para identificar de forma unívoca ese terminal esté donde esté.

El paso siguiente es obvio: vamos a ver dónde está ese terminal vía Find my iPhone. Solo nos muestra el primer teléfono de S.P.F, ni rastro de este segundo terminal. Si accedemos al resto de opciones de iCloud no encontramos nada digno de mención aparte de una copia de seguridad de miles de fotos (Instagram es lo que tiene).

Parece ser que ese teléfono se conectó a iCloud pero luego no se ha activado ninguna funcionalidad de copia de seguridad. Y si la funcionalidad de encontrarlo no está operativa lo único que se nos ocurre es que o bien el teléfono esté apagado o que ya no esté conectado a esa cuenta de iCloud (no lo podemos confirmar pero no creemos que un mismo terminal pueda estar conectado a dos cuentas de iCloud a la vez). La información del nuevo terminal es vital para la investigación, así que se la facilitamos a las FFCCSSE para que (siempre con orden judicial) soliciten los datos de llamadas y posicionamiento del terminal, mientras esperamos mordiéndonos las uñas y tomando más café del que deberíamos (es decir, mucho).

Los resultados nos aclaran algunas dudas y nos generan otras. Por si no lo sabéis, cuando se emite una orden de obtención de datos a partir de un IMEI, la operadora facilita los datos de la SIM que está conectada al mismo… y de otras SIM que hayan estado conectadas al terminal en el plazo temporal requerido en la orden.

El terminal ha tenido dos SIM conectadas, cada una con un patrón de uso diferente:

a) SIM1 (conectada hasta el día después de autos).

• Titular: Abdul Alhazred.
• Patrón de llamadas: Varias llamadas diarias al móvil X, casi no hay llamadas a otros números.
• Patrón de localizaciones: Barrio de Chamberí, centro de Madrid, sede central de Armand & Old.

b) SIM2 (conectada a partir del día después de autos).

• Titular: Vanessa Pérez Fuencarral.
• Patrón de llamadas: Pocas llamadas a unos 20 números de teléfono.
• Patrón de localizaciones: Barrio de Salamanca, centro de Madrid, colegio privado XXX.

Oro en lingotes como para hacerle una casita al perro. Cuesta poco obtener las siguientes conclusiones:

• La SIM1, por su patrón de comportamiento, pertenece o bien a S.P.F. o a un señor árabe que está en todo momento junto a ella (y no creemos que sea tan amigo como para que lo dejen entrar en su casa y en su trabajo).
• La SIM2 tiene como titular a V.P.F, que no es más que la hermana de S.P.F. Ella es un poco mayor para ir a un colegio privado, pero es muy posible que tenga hijas que sí que puedan hacerlo (¿y qué adolescente no querría un iPhone5?)

El terminal cambió de SIM1 a SIM2 el día después del asesinato. ¿Alguien se está deshaciendo de pruebas? Y sobre todo… ¿dónde está el móvil X? Una nueva orden judicial (con el juez ya un poco calentito al respecto) deshace el entuerto y nos da información sobre el terminal X:

c) SIM3 (conectada hasta el día de autos)

• Titular: Eduardo Tobías Jiménez Mejido.
• Patrón de llamadas: Varias llamadas a la SIM1, casi no hay llamadas a otros números.
• Patrón de localizaciones: La Moraleja, centro de Madrid, sede central de Armand & Old.

Este último patrón de localizaciones concuerda a la perfección con el de R.G, pero con un añadido: A eso de las 00.00h el terminal sale de la casa de Chamberí, se desplaza hasta la casa de R.G. en La Moraleja, permanece allí como 20min, empieza a moverse hacia el centro de Madrid… y desaparece sin dejar más rastro en la operadora.

Las FFCCSSE lo tienen bastante claro: las SIM han sido adquiridas en algún locutorio (recordad que desde hace años no se puede obtener un nuevo número de teléfono sin que tenga unos datos personales asociados al mismo) y los terminales han sido comprados en el mismo lugar, o mediante efectivo para no dejar huellas. Los patrones de localización cuentan una historia bien fácil de leer, situando ese terminal en la escena del crimen y relacionándolo con S.P.F.

Las evidencias parecen bastante claras, pero dado lo mediático del caso las FFCCSSE quieren un caso sólido y sin ningún resquicio, por lo que vamos a tener que recuperar esos dos terminales. La resolución del caso, en la próxima entrega…

En esta segunda parte de la serie sobre Suricata (ver primera parte) vamos a continuar repasando las ventajas de Suricata, pero esta vez centrados en la información que podemos obtener de la aplicación.

Con Snort teníamos únicamente alertas, que podían provenir o bien de preprocesadores o bien de firmas que se cargaban a la aplicación. Suricata, si bien mantiene estas ideas, y ofrece total compatibilidad con las reglas existentes para Snort, ofrece muchísimo más.

Por una parte se ha mejorado el proceso de detección de protocolos, de forma que, para algunos de ellos (actualmente http, ssl, tls, smb, smb2, dcerpc, smtp, ftp, ssh y dns), ya no es necesario especificar los puertos en los que queremos buscarlos, sino que con añadir el protocolo correspondiente al principio de la firma se va a identificar el protocolo y procesar la regla, sea cual fuere el puerto en el que se ha detectado el tráfico.

[Read more…]

La Unión Europea, después de muchos años y tras varios intentos fallidos, ha conseguido incorporar el dispositivo de emergencias eCall en los nuevos vehículos. Finalmente se ha aprobado una ley para que sea obligatorio en todos los modelos nuevos de coches y furgonetas ligeras a partir de abril del 2018.

La Comisión de Mercado Interior y Protección de los Consumidores del Parlamento Europeo ha dictaminado que, a partir del 31 de marzo del año 2018, todos los coches y furgonetas ligeras nuevas deberán ir equipados con el sistema automático de llamada a los servicios de emergencia en caso de siniestro, denominado eCall.

La verdad es que esta medida no es nueva, sino que se lleva hablando de ella desde hace varios años; en un principio el 2015 era el año en el que debía ser obligatorio, pero diversos motivos legales la han ido retrasando hasta el 2018. Este retraso al menos servirá para instalar la infraestructura necesaria para garantizar que el sistema funciona correctamente.

La mayor parte de los retrasos que ha acumulado el proyecto se deben principalmente a temas relacionados con la privacidad y a la protección de los datos de los usuarios. En ese sentido, los europarlamentarios han ido corrigiendo el texto legal para que la privacidad no quedara en entredicho. Básicamente han reforzado la cláusula sobre protección de datos para impedir que se rastreen los vehículos equipados con el nuevo dispositivo antes de un accidente.

Según la nueva normativa, la llamada automática de emergencia solo facilitará datos básicos, como el tipo de vehículo, el combustible utilizado, la hora del accidente, la localización exacta y el número de pasajeros. Además, también establece que ningún dato será transferido a terceros sin el consentimiento explícito de la persona, y que los fabricantes garanticen el borrado completo y permanente de los datos almacenados.

Pero, ¿cómo funciona este sistema? El sistema eCall utiliza la tecnología del número 112 para avisar automáticamente a los servicios de emergencia en caso de un accidente grave. Así pueden decidir inmediatamente el operativo de asistencia necesaria. Además, los estudios demuestran que gran parte de las víctimas mortales y de las lesiones graves son causadas por la ausencia de asistencia médica inmediata. Con la incorporación de este dispositivo se espera reducir entre un 50 y un 60% el tiempo de respuesta ante un accidente, y con ello el número de víctimas mortales.

En caso de accidente, eCall realiza una llamada inmediata al 112, quienes responderán a la llamada y tratarán de ponerse en contacto con los ocupantes del vehículo para confirmar su estado y por otro lado, advertir en caso necesario, si el accidente no reviste gravedad. De no contestar nadie, se activará inmediatamente un protocolo de emergencia para que acudan al lugar del accidente ambulancias, policías y bomberos. Para ello, el dispositivo transmitirá la marca y el modelo del coche, el titular del vehículo, el tipo de combustible, la hora del accidente, la localización exacta y el número de ocupantes.

Aunque de momento no es obligatoria su instalación en los coches nuevos, muchas marcas ya lo han incorporado en muchos de sus modelos. Por ejemplo Mercedes, BMW, Citroën, Ford y Opel ya lo hacen. El sistema se suele ofrecer como equipamiento opcional, incluyendo su uso por un determinado periodo de tiempo, que posteriormente requiere de una suscripción con la correspondiente cuota anual. No obstante, también los hay que no conlleva ningún coste ni suscripción por parte de los conductores.

A partir de la fecha límite, este dispositivo tendrá que ser de serie en todos los vehículos y se supone que no conllevará ningún coste añadido, ni ninguna tarifa de suscripción para los servicios básicos obligatorios, ni ningún problema de privacidad… aunque esto, como se imaginan, está todavía por ver.

(Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.)

Según lo visto en la entrada anterior (ver parte I, parte II y parte III), teníamos a nuestra disposición las siguientes evidencias digitales:

• Volcado lógico de un iPhone5.
• Volcado físico de un Samsung Galaxy S5.
• Imagen forense de un Apple MacBook Pro.

La situación es casi la misma que en el caso de R.G, solo que con un portátil de Apple en lugar de uno de HP. El tratamiento de los móviles va a ser exactamente el mismo, así que nos ponemos rápidamente al lío.

[Read more…]

Cuando pasas mucho tiempo analizando muestras de malware empiezas a darte cuenta de que cada vez es más frecuente encontrarte con técnicas anti-sandboxing y anti-debugging. Estas técnicas tienen como finalidad proteger la muestra ante los análisis de malware dinámicos y evitar que su comportamiento sea estudiado.

Las técnicas anti-sandboxing se basan en encontrar alguna traza de información clave del sistema donde se está ejecutando. Esta información debería ser exclusiva de sistemas virtualizados, por ejemplo, claves concretas en el registro de una máquina virtual Windows, procesos de VMware o VirtualBox, tamaño del disco duro (en máquinas virtuales suele ser menor), etc.

Por otro lado, las técnicas anti-debugging son utilizadas por el malware para detectar si está siendo ejecutado desde un debugger. Generalmente, cuando detecta que es así, realiza acciones distintas al proceso de infección para el que ha sido programado, o bien, finaliza el proceso inmediatamente con el fin de complicar el análisis del mismo.

Muchas veces, ambas técnicas son incluidas en la misma muestra, incluso implementan varios métodos de cada técnica para protegerse mejor ante mirones.

La mayor parte de las técnicas anti-sandboxing pueden ser evadidas fácilmente por un analista de malware, por ejemplo, cerrando los procesos de las “tools” de la máquina virtual, cambiando de plataforma de virtualización, modificando algunas claves del registro, etc. En cambio, engañar al malware para que se ejecute correctamente en un debugger puede ser algo más complicado.

Vamos a detallar brevemente en que consisten algunas de estas técnicas. Además, crearemos pequeños “crackmes” con los que jugaremos a evadir las protecciones. Nosotros vamos a utilizar OllyDbg, pero podéis usar el que más os guste. Podéis echar un vistazo a la web de Ricardo Narvaja, donde podréis encontrar mucha información sobre el uso de este debugger y de cracking en general. Como la mayoría del malware está programado para plataformas Windows, nos basaremos en esta. Todos los que hayáis trabajado alguna vez con debuggers como OllyDbg, WindDbg, Radare o IDA ya sabréis que se requieren conocimientos sobre lenguaje ensamblador y estructuras internas de ficheros, así que os animo a que os documentéis al respecto.

Vamos a comenzar con una técnica anti-debugging muy fácil de implementar, pero también muy fácil de evadir, la función “IsDebuggerPresent”.

IsDebuggerPresent

Es una función de la librería kernel32.dll. Si el proceso está siendo debuggeado, la función devuelve un valor distinto de 0, en caso contrario, el valor devuelto es 0. Es muy fácil de implementar ya que basta con realizar la llamada a la función y comparar el valor devuelto. Podéis ver la documentación oficial aquí.

Esta función lo que realmente hace es consultar el valor del flag “BeingDebugged” del PEB (Process Environment Block), el cual se activa si el proceso está siendo debuggeado. Vamos a ponernos manos a la obra, podéis descargar el binario y los sources (lenguaje C) de este crackme desde mi cuenta de GitHub: https://github.com/reverc0de/saw-anti-debugging.

El código de crackme01_IsDebuggerPresent es el siguiente:

/***************************************************************** 
* File: 	crackme01_IsDebuggerPresent.c 
* Description:  Es un crackme con la proteccion IsDebuggerPresent 
* Author: 	reverc0de 
* Date: 	26/03/2015 
* Github:	https://github.com/reverc0de/saw-anti-debugging	 
*****************************************************************/ 
#include  
#include  

int main(int argc, char **argv) 
{ 
	if (IsDebuggerPresent()) 
	{ 
		MessageBox(0, "Debugger detectado!!","Crackme01 IsDebuggerPresent",MB_OK); 
		exit(0); 
	} 
	MessageBox(0, "Debugger NO detectado!!","Crackme01 IsDebuggerPresent",MB_OK); 
	return 0;		 
}

Si deseáis, podéis compilarlo vosotros mismos en cualquier IDE para Windows como Dev-C++. Si ejecutamos el crackme directamente (crackme01_IsDebuggerPresent.exe), el mensaje es el esperado:

Ahora vamos a cargarlo en OllyDbg y lo ejecutamos con F9. Esta vez, el crackme ha detectado que se esta ejecutando a través de un debugger:

¿Y ahora que? ¿Como podemos saltarnos esta protección? Se puede conseguir de varias formas pero primero, hay que echar un vistazo al código en OllyDbg cuando llama a la función en cuestión:

En el fragmento de código dentro del recuadro rojo encontramos la llamada a la función IsDebuggerPresent.

Después de la llamada tenemos una comparación con TEST del registro EAX. Con TEST comprobamos si el valor de EAX es igual a 0, en cuyo caso el flag ZF se pone a 1 y se ejecutaría el salto ‘JE SHORT‘ a la posición 00401576. Si ejecutamos el crackme paso a paso (F7), podemos ver como EAX tiene el valor 1 en la comparación y el salto no se produce (ZF = 0), continuando con la ejecución de código secuencial.

A continuación nos encontramos con la función MessageBoxA, la cual genera el mensaje que hemos visto anteriormente con el texto “Debugger detectado!!”. Si seguimos analizando unas líneas más, podemos ver como en la posición 00401576, a la cual se accedía desde la operación de salto anterior (JE), se encuentra otra llamada a MessageBoxA, pero esta vez con el texto del mensaje que deseamos, “Debugger NO detectado!!”.

Conseguir que muestre el segundo mensaje y saltarnos así esta protección es tan fácil como sustituir el tipo de salto condicional, por ejemplo, por un salto JNZ, que se produce si ZF = 0, es decir, si el resultado de la comparación anterior es distinta a 0.

Para modificar el código en el debugger, nos situamos sobre la sentencia del salto y pulsamos la barra espaciadora. Se abrirá un cuadro donde tenemos que sustituir JE por JNZ y aceptamos. Si ahora ejecutamos de nuevo el crackme con esta modificación, obtendremos el mensaje que queríamos, ya que esta vez escoge el salto, consiguiendo evadir esta técnica anti-debugging.

Otras formas de conseguir el mismo resultado es modificar el salto condicional por otro incondicional, o modificar el valor del flag Z en la ejecución del salto.

Variaciones de esta técnica anti-debugging puede ser la de consultar directamente el valor del flag “BeingDebugged” del PEB mediante la inserción de código ASM en el propio source del malware. Otra opción es utilizar la función CheckRemoteDebuggerPresent, que comprueba si el debugger se está ejecutando en otro proceso separado,utilizando además, la función IsDebuggerPresent.

Esta técnica anti-debugging es de las más obvias y fáciles de identificar por un analista de malware. En próximos artículos seguiremos jugando con otra técnicas algo más entretenidas así que… ¡empezad a practicar!

(Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.)

Como ya habíamos comentado en entradas anteriores (ver parte I y parte II), la investigación estaba siendo bastante complicada: por ahora no habíamos sacado prácticamente nada en claro, y únicamente nos quedaba por analizar la imagen forense del ultrabook de R.G.

En muchas ocasiones el análisis forense tiene unos objetivos dirigidos: comprobar la existencia de unos ficheros, verificar por qué páginas ha navegado un usuario, detectar si se ha enviado un correo electrónico, etc… En este caso el análisis es el clásico generalista, el “tú mira y si encuentras algo raro nos lo dices”. La mejor forma de atacar estos análisis es mediante 3 pasos:

1. Recuperación de ficheros borrados: Recordemos que, cuando borramos la papelera, los datos no se borran realmente sino que se quedan marcados como disponibles para su uso. En muchos casos podemos recuperar información de ese espacio disponible.

2. Creación de una línea temporal: Una vez tenemos todos los ficheros podemos crear una línea temporal, un cronograma de lo que ha sucedido en el equipo.

3. Análisis de la información: Una vez tenemos toda la información espacio temporal llamamos al Dr Wh… digo cruzamos datos y realizamos un análisis mucho más completo.

[Read more…]

Recientemente hemos visto como en medios generalistas comienza a hablarse del concepto de secuestro virtual, una estafa que va a más y que puede afectar a cualquiera de nosotros.

Lo primero que hay que saber es que un secuestro virtual no es un secuestro. Es decir, no hay nadie secuestrado, aunque el delincuente trate de hacernos creer lo contrario.

Un secuestro virtual es una estafa en la que la víctima recibe una llamada en la que se le asegura que han secuestrado a un familiar suyo, y se le pide a cambio un rescate económico. Sin embargo, no existe tal secuestro, ya que la víctima está a menudo escogida al azar y la información del rehén está extraída de redes sociales u obtenida en de la propia víctima.

Las fuerzas y cuerpos de seguridad del estado están informando sobre la forma de actuar de estos delincuentes, para poder identificarlos mejor:

[Read more…]

A finales de 2010 nuestro compañero Nelo hablaba, en tres magníficos artículos, acerca de cómo configurar nuestro IDS Snort para que fuera capaz de procesar gran cantidad de tráfico (partes 1, 2 y 3). En aquel momento Nelo utilizó cuatro instancias, a las que enviaba únicamente una parte del tráfico mediante filtros BPF.

En todo este tiempo los despliegues han ido actualizándose, y mejorando y aumentando sus funcionalidades. Esto se debe por una parte a que Snort ha incluido nuevas mejoras, como por ejemplo la posibilidad de extraer información adicional de los preprocesadores SMTP y HTTP (partes 1 y 2).

Por otra parte, también se han mostrado útiles nuevos drivers para tarjetas de red, como PF_RING, una herramienta excepcional que permite aumentar el número de “cerditos” en esta particular granja de forma fácil ya que, además de acelerar el acceso a la propia tarjeta de red para evitar pérdidas de datos, se encarga automáticamente de dividir el tráfico entre todas las instancias de Snort que se conectan a él evitando el uso de los incómodos filtros BPF que usamos inicialmente (en la documentación de Snort se puede encontrar un completo manual de instalación de Snort con PF_RING). Incluso es posible conectar Snort con nuevas herramientas de Big Data como la suite ELK (parte 1 y 2) para hacer algunos de esos cuadros de mando visuales que tan populares son actualmente.

Pero, como dice el dicho, no sólo de pan vive el hombre, o en nuestro caso no sólo de Snort vive el mundo de los IDS/IPS de código abierto. En estos últimos cuatro años hemos vivido la consolidación y expansión de Suricata, que ya por aquel entonces se postulaba como un duro competidor para Snort. Tal ha sido su expansión que a principios de marzo de este año la empresa matriz que está al cargo de su desarrollo (Emerging Threats) ha sido adquirida por Proofpoint Inc, una importante empresa americana dedicada a ofrecer servicios de seguridad.

En los últimos meses hemos estado probando Suricata, y precisamente de él, y de las mejoras que ofrece respecto a la rama actual (2.9.x) de Snort, quiero hablaros en esta serie de entradas.

A pesar de que el pasado mes de diciembre se anunció la existencia de la rama 3.0 de Snort, que supone una reescritura de gran parte del código de la aplicación y la introducción de bastantes mejoras sobre la rama actual, algunas de ellas presentes en Suricata y otras no, hemos decidido realizar la comparativa con la rama actual de Snort ya que la nueva rama 3.0 aún se encuentra en fase alfa y por tanto, al no ser un producto terminado, puede acarrear problemas y no se recomienda su uso en entornos en producción. Si de todas formas alguien se anima a empezar a probarlo, puede descargar el código fuente de su proyecto de GitHub.

El cambio más significativo en lo que a arquitectura se refiere, y uno de los principales a nivel global es el hecho de que, a diferencia de Snort, Suricata es multihilo. Esto quiere decir que una única instancia de Suricata va automáticamente a balancear la carga de trabajo entre todos los cores disponibles, mejorando el rendimiento de la aplicación y permitiendo alcanzar tasas de procesamiento de 10Gbit/s en servidores normales, sin necesidad de obtener hardware especial (un ejemplo aquí). Además, hay un control completo sobre qué hilos y de qué tipo (hay un tipo de hilo para cada una de las fases por las que pasa un paquete dentro de Suricata) se ejecutan sobre qué cores de nuestro equipo. También se permite elegir entre diferentes modos de ejecución, llamados runmodes en Suricata, y que permiten modificar a nivel global el comportamiento de los hilos y el flujo de paquetes a través de los mismos.

Otro punto importante es la integración con diferentes métodos y dispositivos de captura de tráfico. En Snort era necesario una extensión que había que compilar y enlazar por separado para hacer uso por ejemplo de PF_RING, pero Suricata trae por defecto soporte para este método de captura. En el ámbito de la integración, también cabe destacar la integración con CUDA, que permite descargar de trabajo a las CPU y llevar dicha carga a las potentes tarjetas gráficas existentes actualmente. Toda esta integración mejora también la instalación al reducir en gran medida el número de dependencias.

En siguientes entradas de esta serie nos centraremos en la información de toda clase que podemos obtener de Suricata, y cómo poder representar esta información de forma fácil.

(Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.)

Según lo visto en la entrada anterior, teníamos a nuestra disposición las siguientes evidencias digitales:

• Imagen forense (dd) de un GPS TomTom.
• Volcado lógico de un iPhone5.
• Volcado físico de un Samsung Galaxy S5.
• Imagen forense de un Ultrabook HP Spectre.

Una buena forma de comprobar una coartada es verificando la localización GPS, así que vamos a empezar con el análisis forense del navegador, un TomTom One. Si analizamos los artefactos forenses que podemos recuperar, vemos que nos interesan principalmente dos datos:

• Rutas programadas en el dispositivo: Queremos sobre todo la última ruta realizada, y la encontraremos en el fichero: MapSettings.cfg.
• Última conexión a GPS realizada: TomTom guarda la última conexión con la red de satélites GPS, algo que nos puede servir para corroborar la exactitud de la última ruta. Deberemos hacernos con el fichero CurrentLocation.dat.

[Read more…]