Security Art Work

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

(N.d.A. La información de este post está basado en gran parte en un paper de Wei Xu, Kyle Sanders & Yanxin Zhang titulado WE KNOW IT BEFORE YOU DO: PREDICTING MALICIOUS DOMAINS, que puedes descargar desde este enlace en PDF o ver aquí en html)

Comencemos diciendo que existen tres tipos de nombres de dominios DNS: buenos (o legítimos), malos y corruptos (es decir, nombres de dominios legítimos que han sufrido algún tipo de ataque).

Un nombre de dominio se puede considerar malicioso tanto por su contenido (malware, paginas web con exploits o con descargas automáticas, etc.) como por su comportamiento (comunicación con máquinas infectadas para el envío de información, lanzamiento de ataques, etc.). Hay que tener en cuenta que un dominio malicioso suele usarse durante un corto periodo de tiempo, ya que de este modo se abaratan costes además de dificultar su detección, puesto que son dominios creados específicamente con este propósito.

Además de las herramientas que todo el mundo conoce para el análisis de dominios DNS (Automater, URL Query, Virus Total, DNS Query, Domain Tools…), existen ciertas características y patrones que estos siguen que también nos pueden ayudar en la predicción del grado de legitimidad de un dominio. Basando nuestro análisis en el ciclo de vida del dominio DNS (preparación, activación, desactivación o bloqueo) y en la reutilización de recursos, encontramos ciertas características y patrones útiles para su detección, que veremos a continuación.

Las primeras alarmas vienen dadas por el hecho de que muchos dominios DNS maliciosos se reutilizan, después de su detección, para otras campañas de ataques. El intervalo de tiempo que suele haber entre su uso inicial y posterior es aproximadamente de un año, tiempo en el que los dominios previamente detectados han vuelto al mercado y han sido borrados de las DNBL. Además, durante el tiempo en el que permanecen desactivados, estos dominios suelen sufrir cambios en su registro y su contenido. Además, otra característica de los dominios DNS maliciosos es que la mayoría de estos resuelven como domain parking, es decir, no tienen asociado ningún servicio.

Si encontramos estas dos características por separado probablemente el dominio haya sido malicioso, pero hemos de tener en cuenta que la mayoría de ellos no se suelen reutilizar con malos propósitos.

Por lo que respecta a las peticiones DNS, podemos extraer ciertos patrones útiles en nuestra predicción antes de que dicho dominio sea usado o detectado. De estos, la mayoría están relacionados con la fase de preparación y test del dominio:

• Cambios en los registros DNS, como por ejemplo, activación de servidores, realizar un test de resolución de DNS, etc.
• Patrones temporales de peticiones DNS. Bien porque encontremos dominios cuyo número de peticiones DNS sufre un brote repentino en cuanto a volumen, o bien, porque las peticiones DNS sigan patrones periódicos.
• Patrones en QNAME (Query Domain Name). Tenemos este tipo de patrones cuando el dominio ha sido generado mediante un DGA (Domain Generation Algorithm), o si se asemeja a algún dominio malicioso conocido o a algún dominio popular y legítimo, sin tener ninguna relación.

Por supuesto, este tipo de características no son determinantes; los dominios también deben pasar un test de detección de contenido JS/HTML maliciosos y ser clasificados en base a las características extraídas de los registros DNS, las direcciones IP, etc. Si ambos tests devuelven positivo, entonces podemos considerar dicho dominio como malicioso. Además, si queremos diseñar una herramienta de detección debemos tener en cuenta que los tests que deberían pasar los dominios DNS son sensibles al tiempo.

Por otra parte, también podemos analizar las posibles conexiones entre los patrones de comportamiento de dominios maliciosos ya conocidos y los que estemos analizando:

Si su servidor de nombres (NS) coincide con el de un dominio malicioso conocido, podremos considerarlo un indicio siempre que descartemos NS legítimos como registradores de DNS, proveedores CDN (Content Delivery Network), web hosting (alojamiento web), etc.; y NS que abastecen a muy muy pocos dominios maliciosos. Para este tipo de análisis necesitaríamos recopilar y mantener una lista de servidores de dominios maliciosos conocidos, teniendo en cuenta el flujo de datos del Passive DNS, es decir, los registros de NS que apuntan a NS de la lista. Cualquier dominio que cumpla dicha condición podría ser considerado malicioso.

Si encontramos coincidencias en direcciones IP, podemos encontrarnos con dos casos:

• La primera, que coincidieran con direcciones IP utilizadas por dominios maliciosos conocidos, sabiendo que debemos descartar las direcciones IP utilizadas por diferentes dominios, como por ejemplo, direcciones IP en CDN o web hosting.
• La segunda, que encontrásemos coincidencias con direcciones IP infectadas e identificadas como sinkhole, es decir, direcciones IP utilizadas para cambiar el flujo de URL maliciosas mediante la inserción de una entrada falsa en el NS. Estas URL se pueden deducir de servidores C&C ya conocidos. Debemos tener presente que direcciones IP comerciales o de portales pueden tener estas mismas características y por tanto, se deben descartar.

Algunas herramientas de este tipo basan el filtrado principalmente en la localización y la información de asignación de las direcciones IP y el conocimiento de los posibles dominios de CDN/web hosting/otras empresas.

En cuanto a la información de registro, podemos establecer una conexión entre dominios maliciosos si encontramos similitudes entre nombres de los titulares de registros de dominios maliciosos o coincidencias entre las direcciones, los teléfonos o los emails de los titulares de los registros.

En definitiva, si queremos diseñar un sistema de detección de dominios DNS maliciosos, además de integrar las típicas herramientas de análisis de dominios DNS que todos conocemos, debemos analizar un conjunto de características que sin duda harán de nuestro sistema una herramienta más robusta.

(N.d.E. Interrumpimos la programación habitual para anunciar una noticia de la que nos sentimos muy orgullosos)

Desde que S2 Grupo comenzó su andadura hace ya unos cuantos años, los que formamos parte de ella hemos visto cómo años tras año ha sido galardonada con diferentes premios y reconocimientos, incluyendo el premio que este mismo blog recibió hace ya unos años.

En este caso, es la revista SIC la que, en la duodécima convocatoria de sus Premios SIC y coincidiendo con la edición XXVI del congreso global de ciberseguridad, seguridad de la información y privacidad Securmática, concede a S2 Grupo uno de sus premios por su “apuesta firme por la excelencia en la prestación de servicios de seguridad de la información, incluyendo la I+D+i y los servicios gestionados“.

La revista SIC, con una experiencia en el sector de más de 20 años y organizadora de Securmática, Respuestas SIC y Espacio TiSEC, reconoce a través de este premio el buen hacer en materia de seguridad de la información de nuestra empresa.

Desde S2 Grupo queremos agradecer a la revista SIC que nos haya concedido este premio, comprometiéndonos a seguir trabajando duro para que no sea el último.

¿Por qué tres millones de euros? Porque, como veremos a lo largo del post, los costes de un ataque informático están en torno a esa cifra. Prevenirnos frente a este tipo de pérdidas es, más que una opción, una necesidad.

Cuantificar qué cantidad de tiempo y dinero debe dedicar una empresa u organismo a impedir los ataques a su infraestructura IT es siempre una cuestión complicada. Por un lado hay que tener en cuenta el apetito por el riesgo que tenga la organización en cuestión y por otro hay que calcular qué precio va a tener la reparación de los daños que provoque un posible ataque informático. A este último tema va dedicado este post: ¿qué coste tiene un compromiso en los sistemas de IT? ¿Cuánto nos va a suponer en robo y fraude directo, multas, pagos a terceros perjudicados, y costes de nuestra IT interna? Vamos a arrojar un poco de luz sobre este tema recordando algunos casos.

Los compromisos de datos en el pasado se ocultaban hasta que eran descubiertos por un tercero, los clientes, los partners, auditores… con lo que tener información sobre los costes de unos compromisos en la mayor parte de los casos no conocidos era tarea difícil. Poco a poco se ha extendido la conciencia de que dar luz a estos hechos es una buena práctica para evitarlos y un derecho de los posibles perjudicados cuyos datos están en manos de terceros no autorizados. Más aún, en ciertos países, sobre todo anglosajones, la ley obliga a informar de las brechas en la seguridad. De esta forma hay diferentes casos publicados (ver por ejemplo http://datalossdb.org).

[Read more…]

Una de las características más interesantes de Maltego, herramienta ya potente de por sí, es la posibilidad de desarrollar nuestras propias transformadas, o transforms, para ampliar sus capacidades.

De forma simplificada, una transform no es más que una “caja negra” que toma como entrada una entidad (o entity), y produce como salida una o más entities. Estas entities, ya sean de entrada o de salida, son de cierto tipo (por ejemplo, de tipo Person, EmailAddress, etc.) y deben tener un valor (o value) determinado. Adicionalmente, una entidad puede tener cero o más campos (o fields) extra que pueden enriquecer su valor semántico (cada field está formado por un nombre y un valor).

Las transforms pueden ser locales o remotas: las primeras se ejecutan en la misma máquina donde corre el propio programa cliente de Maltego, mientras que las segundas residen en los llamados servidores TDS (Transform Distribution Service), de forma que el programa cliente de Maltego envía la entity de entrada y recibe de los servidores la entity o entities de salida.

Centrándonos ya en la programación en sí de las transformadas, objeto de la presente entrada, el interfaz para el desarrollo de las transforms locales es sumamente sencillo: cualquier programa que reciba como parámetros el value de la entity de entrada (y, opcionalmente, los nombres y valores de los fields extra), y genere código XML en el formato de especificación de las entities de salida (con sus respectivos valores, etc.), puede registrarse en el programa cliente de Maltego y funcionar como una transform más.

[Read more…]