Security Art Work

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…]

Sin entrar en valoraciones sobre los motivos por los que en los últimos tiempos se crean “días de…” para todo, quiero hacer una mención al pasado día 31 de Marzo, cuando se celebró el día mundial de las copias de seguridad.

Si nos remitimos a las diferentes normas y buenas prácticas relativas a la seguridad de la información, en todas existe un apartado específico de copias de seguridad, sirva el presente post para referenciar algunas de dichas recomendaciones/obligaciones y ver algunos de los controles que se deberán implementar para estar alineados con lo indicado en dichas normas.

Empecemos con algo que (casi) todos conocemos: la norma ISO 27001, cuyo objetivo de control A.12.3 Copias de Seguridad, hace referencia a que se debe evitar la pérdida de datos. En la descripción del control se cita que se deben realizar copias de seguridad de la información, del software y del sistema y se deben verificar periódicamente de acuerdo a la política de copias de seguridad acordada. Parece bastante lógico.

[Read more…]

(N.d.A. Debido al revuelo que se ha montado a colación del post de hoy, nos vemos en la necesidad de aclarar que esta es una historia de ficción en la que nos hemos tomado ciertas licencias para justificar la intervención de lo que podría ser un equipo de seguridad externo (cuya colaboración en ocasiones se produce, no obstante). Todos los personajes y situaciones que aparecen en este y otros post de ficción 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.

En ningún caso se ha pretendido desmerecer la innegable labor de las FFCCSSE y el excelente trabajo que realizan día a día para proteger a los ciudadanos, tanto en el ámbito digital como en el físico. Asimismo, tampoco hemos querido poner en duda la preparación ni los medios de los expertos de seguridad de estos cuerpos, ya sea la Brigada de Investigación Tecnológica —BIT— o el Grupo de Delitos Telemáticos —GDT— de la Guardia Civil, con cuyos objetivos estamos totalmente alineados: ir a por los “malos”.)

Pocas cosas llaman tanto la atención como una buena dosis de morbo, con doble de sangre como acompañamiento y extra de drama. La noticia llevaba varios días en primera plana: Mª Adoración Puig de Parga Carral-Bryce, última descendiente de los Puig de Parga (una familia castellana poco conocida públicamente, pero poseedora de una considerable fortuna), había aparecido asesinada a cuchilladas en su chalet de La Moraleja.

Su marido, Ronald Green Hinojosa-Del Pinar, vicepresidente ejecutivo EMEA de Armand & Old, una conocida multinacional financiera, no se encontraba en casa en esos momentos (estaba al parecer en una importante reunión de trabajo), lo que ha hecho dispararse las teorías sobre el asesinato.

La que más ha calado, a bien seguro por su truculencia, es la que tiene al propio R.G. como responsable del crimen. Green es atractivo, inteligente, elegante y soberbiamente altivo, siempre con la barbilla ligeramente levantada y esa mirada de “soy mejor que tú, y lo sabes”. Maná caído del cielo para las tertulias de televisión y las redes sociales, que ya lo han apodado “El Mr. Grey español”.

[Read more…]