Finalmente, tras haber repasado las técnicas y herramientas comúnmente utilizadas en la fase de footprinting dentro de un proceso de investigación actual, como ver las nuevas búsquedas inversas que hemos explorado y que no están disponibles en las herramientas de hoy en día, llegó la hora de entrar en materia de cómo abordar la solución técnica que cubra las necesidades que hemos ido identificando.
El primer problema que trataremos será de dónde recopilar toda la información existente en Internet para cubrir todos los vectores de footprinting descritos. Posteriormente continuaremos con cómo, utilizando tecnologías Big Data, fuimos capaces de desarrollar un proyecto que, siendo independiente de cualquier servicio de terceros, permitiera cumplir el único objetivo para el que fue diseñado, realizar un proceso de footprinting todo lo exhaustivo que sea posible.
Recopilación de información útil para el proyecto
Lo primero que había que cumplir en el desarrollo de este proyecto era no perder funcionalidad con respecto al resto de servicios de terceros, es decir, las técnicas de footprinting actualmente soportadas por el resto de herramientas y servicios de terceros debían estar soportadas en nuestro proyecto también.
Para ello necesitábamos disponer de información DNS a granel, por lo que recurrimos a la información existente en los proyectos Scans.io y Censys.io, que cada quince días más o menos, publican el resultado de sus escaneos sobre los servidores DNS de todo Internet en un archivo comprimido de unos 12 GB, el cual descomprimido se traduce en más de 80 GB de texto con información DNS y DNSSEC.
Entre toda esta información, nos interesamos por todos aquellos registros que cubrían tanto con las búsquedas soportadas por servicios de terceros como por las nuevas técnicas, es decir, dentro de los registros DNS nos quedamos con los A, AAAA, CNAME, MX, NS, PTR, SOA, SPF, TXT/DKIM, y dentro de los registros DNSSEC con los DNSKEY y DS.
En segundo lugar, era necesario disponer de los certificados X.509 existentes en Internet para poder realizar búsquedas por los campos CN, SAN, O y OU como ya habíamos comentado. Los proyectos Scans.io y Censys.io incluyen escaneos de varios puertos y recopilan en unos 500 MB en torno a 400.000 certificados.
¿Sólo 400.000 certificados con lo grande que es Internet? Fue en ese momento en el que nos montamos un sistema multi-nodo y con ayuda de ZMAP realizamos nuestro propio escaneo pasando de 400.000 a más de 9.000.000 de certificados X.509 incluyendo muchos más puertos que los escaneados por los proyectos de Scans.io y Censys.io.
Por otro lado, a la hora de obtener las bases de datos de Whois, la cosa se complicó bastante ya que no existe ningún sitio donde estén disponibles. Fue por este motivo por el que volvimos a utilizar un sistema multi-nodo para intentar saltarnos la limitación existente en algunos servidores de Whois que impiden realizar más de una petición por segundo desde la misma IP. Aun así, esto no impidió que nos cerraran más de un servidor independientemente del continente en el que estuviese por saturar algún que otro servidor de Whois.
Para terminar, y una vez obtenidas las bases de datos de los cinco Registros Regionales de Internet (RIR) para conocer qué rangos de direcciones IP están asignados a qué compañía, necesitábamos todo el código HTML disponible en Internet para poder extraer información de redes sociales y etiquetas de Web Analytics. Para ello recurrimos al proyecto Common Crawl, que cada mes publica cerca de 2 TB con el HTML que obtiene de realizar peticiones a sitios webs de todo Internet.
Obviamente, no toda la información obtenida era interesante a la hora de realizar las técnicas de footprinting, y tras analizar y filtrar toda la información, comprobamos que cada quince días, que es lo que tardan más o menos los proyectos Scans.io y Censys.io en actualizar con sus nuevos escaneos, generábamos cerca de unos 180 GB de datos útiles para cubrir con todos los vectores de footprinting propuestos pero, ¿cómo lograr que todos esos datos estén disponibles en tiempo útil? Es en este momento en el que entran en juego las tecnologías Big Data.
Big Data in action
Con vistas a cubrir la ingente cantidad de datos que generamos cada quince días, el proyecto Odin se diseñó apoyándose en tecnologías NoSQL y en asincronía basada en colas de mensajería. Esto permite una mayor capacidad de escalabilidad horizontal desde el punto de vista computacional así como desde el punto de vista del almacenamiento. La siguiente figura muestra un diagrama a altísimo nivel de la arquitectura del sistema.
El primer detalle a tener en cuenta es nuestra elección de ElasticSearch como motor de base de datos NoSQL. Dicha elección se debe a su capacidad para realizar búsquedas complejas de texto, lo cual era lo más importante ya que tanto la información extraída de DNS, como Whois o del resto de fuentes consiste en su totalidad en texto. Es por esto que esta pieza es la más importante ya que todos los cargadores que se encargan de analizar y filtrar la información en bruto que comentábamos en el punto anterior, vuelcan sus resultados en dicha base de datos.
Con vistas a independizar los módulos que se encargan de realizar las búsquedas inversas sobre nuestra base de datos, realizamos un recubrimiento mediante un API REST/JSON de la propia API del ElasticSearch. De esta forma, hemos podido ir realizando optimizaciones progresivamente sobre cómo y qué almacenábamos en nuestra base de datos sin que repercutiese de manera dramática en los módulos.
Por otro lado, como se puede ver en la arquitectura de la solución, existen dos tipos de módulos que hemos diferenciado en base a las etiquetas offline y online. Los módulos offline se encargan de realizar consultas sobre nuestra API que recubre nuestra base de datos. Esto permite realizar un análisis de cualquier compañía sin ser detectado ni dejar rastro ya que todas las consultas se realizan sin necesidad de servicios de terceros.
Por otro lado, los módulos online permiten aprovecharse de servicios de terceros como los que citamos en las anteriores entradas para encontrar y actualizar el análisis con nuevos activos no incluidos en la base de datos. Incluimos, entre otros, los módulos de dnsdumpster, subsearch y herramientas de fuerza bruta sobre DNS.
Todos los módulos, tanto offline como online, son completamente independientes y se fundamentan en el principio de responsabilidad única de igual modo que las arquitecturas orientadas a microservicios, es decir, realizan un solo tipo de búsqueda inversa y sólo una. Esto permite que dichos módulos puedan ser desarrollados de manera independiente y añadidos a la plataforma de manera transparente para el resto de componentes. También permite que los módulos computacionalmente más costosos sean fácilmente escalables horizontalmente, en caso de que fuese necesario, para aprovechar mejor la infraestructura.
Ambos tipos de módulos son orquestados por el motor de Odin mediante una cola de prioridades, para lo cual en nuestro caso utilizamos Apache Kafka. Esto permite que el motor pueda darle más peso a los mensajes de un análisis en curso que a los de otro, o incluso, darle más peso a algunos mensajes dentro del mismo análisis. Dichos mensajes, una vez priorizados, serán procesados por orden de prioridad por los distintos módulos y devueltos a la cola hasta que hayan sido completamente analizados por todos los módulos disponibles.
Es el motor de Odin el que también se encarga de evaluar los mensajes en vuelo que contienen los activos de una compañía gracias a la información proporcionada por los módulos. Si dicho activo pertenece a un dominio o rango de los RIR, o comparte algún MX, NS o dirección de e-mail aceptado por el usuario como válido, el activo se incluye al resultado final. Si por el contrario, el usuario hubiera marcado como no válido el dominio, el rango, o los MX, NS o direcciones de e-mail compartidos, dicho activo se excluye del resultado final evitando de manera automática expandir el árbol de búsqueda a través de dicho nodo.
Si el motor no dispone de información suficiente, presentará al usuario toda la información que dispone del nuevo activo, permitiendo al usuario aceptar esa información como válida o no para disminuir el número de falsos positivos de su análisis. Para terminar, este motor proporciona otra API REST/JSON sobre la cual hemos montado un frontend web que se encarga de facilitar la interacción con el usuario a la hora de la toma de decisiones durante el análisis.
Conclusiones
Tras más de un año de trabajo, podemos concluir afirmando que para hacer footprinting se pueden utilizar aproximaciones diversas, como hacer uso de datos ya procesados por otros servicios, o construir nuevas bases de datos usando las tecnologías de BigData para tener un entorno propio de investigación. En el siguiente vídeo se puede ver la presentación realizada en RootedCON del mismo.
Finalmente, comentar que en este proyecto hemos explorado nuevas técnicas de footprinting, pero no quiere decir que sean las únicas, ya que siempre existen vías de mejora e innovación, así que espero que os haya gustado este trabajo y que os anime a iniciar vuestra propia investigación.
***************************************************************************************************
Autores: Elías Grande (3grander) Alejandro Ramos (@aramosf) escritor de "Hacker Épico"
 |
| Figura 1: Odin, identificando el Shadow IT en la era del Big Data. Parte III: La construcción del Big Data |
El primer problema que trataremos será de dónde recopilar toda la información existente en Internet para cubrir todos los vectores de footprinting descritos. Posteriormente continuaremos con cómo, utilizando tecnologías Big Data, fuimos capaces de desarrollar un proyecto que, siendo independiente de cualquier servicio de terceros, permitiera cumplir el único objetivo para el que fue diseñado, realizar un proceso de footprinting todo lo exhaustivo que sea posible.
Recopilación de información útil para el proyecto
Lo primero que había que cumplir en el desarrollo de este proyecto era no perder funcionalidad con respecto al resto de servicios de terceros, es decir, las técnicas de footprinting actualmente soportadas por el resto de herramientas y servicios de terceros debían estar soportadas en nuestro proyecto también.
Para ello necesitábamos disponer de información DNS a granel, por lo que recurrimos a la información existente en los proyectos Scans.io y Censys.io, que cada quince días más o menos, publican el resultado de sus escaneos sobre los servidores DNS de todo Internet en un archivo comprimido de unos 12 GB, el cual descomprimido se traduce en más de 80 GB de texto con información DNS y DNSSEC.
Entre toda esta información, nos interesamos por todos aquellos registros que cubrían tanto con las búsquedas soportadas por servicios de terceros como por las nuevas técnicas, es decir, dentro de los registros DNS nos quedamos con los A, AAAA, CNAME, MX, NS, PTR, SOA, SPF, TXT/DKIM, y dentro de los registros DNSSEC con los DNSKEY y DS.
 |
| Figura 2: Escaneos de Scans.io |
En segundo lugar, era necesario disponer de los certificados X.509 existentes en Internet para poder realizar búsquedas por los campos CN, SAN, O y OU como ya habíamos comentado. Los proyectos Scans.io y Censys.io incluyen escaneos de varios puertos y recopilan en unos 500 MB en torno a 400.000 certificados.
¿Sólo 400.000 certificados con lo grande que es Internet? Fue en ese momento en el que nos montamos un sistema multi-nodo y con ayuda de ZMAP realizamos nuestro propio escaneo pasando de 400.000 a más de 9.000.000 de certificados X.509 incluyendo muchos más puertos que los escaneados por los proyectos de Scans.io y Censys.io.
Por otro lado, a la hora de obtener las bases de datos de Whois, la cosa se complicó bastante ya que no existe ningún sitio donde estén disponibles. Fue por este motivo por el que volvimos a utilizar un sistema multi-nodo para intentar saltarnos la limitación existente en algunos servidores de Whois que impiden realizar más de una petición por segundo desde la misma IP. Aun así, esto no impidió que nos cerraran más de un servidor independientemente del continente en el que estuviese por saturar algún que otro servidor de Whois.
Para terminar, y una vez obtenidas las bases de datos de los cinco Registros Regionales de Internet (RIR) para conocer qué rangos de direcciones IP están asignados a qué compañía, necesitábamos todo el código HTML disponible en Internet para poder extraer información de redes sociales y etiquetas de Web Analytics. Para ello recurrimos al proyecto Common Crawl, que cada mes publica cerca de 2 TB con el HTML que obtiene de realizar peticiones a sitios webs de todo Internet.
 |
| Figura 3: Escaneos disponibles en commoncrawl.org |
Obviamente, no toda la información obtenida era interesante a la hora de realizar las técnicas de footprinting, y tras analizar y filtrar toda la información, comprobamos que cada quince días, que es lo que tardan más o menos los proyectos Scans.io y Censys.io en actualizar con sus nuevos escaneos, generábamos cerca de unos 180 GB de datos útiles para cubrir con todos los vectores de footprinting propuestos pero, ¿cómo lograr que todos esos datos estén disponibles en tiempo útil? Es en este momento en el que entran en juego las tecnologías Big Data.
Big Data in action
Con vistas a cubrir la ingente cantidad de datos que generamos cada quince días, el proyecto Odin se diseñó apoyándose en tecnologías NoSQL y en asincronía basada en colas de mensajería. Esto permite una mayor capacidad de escalabilidad horizontal desde el punto de vista computacional así como desde el punto de vista del almacenamiento. La siguiente figura muestra un diagrama a altísimo nivel de la arquitectura del sistema.
 |
| Figura 4: Arquitectura a alto nivel del proyecto Odin |
El primer detalle a tener en cuenta es nuestra elección de ElasticSearch como motor de base de datos NoSQL. Dicha elección se debe a su capacidad para realizar búsquedas complejas de texto, lo cual era lo más importante ya que tanto la información extraída de DNS, como Whois o del resto de fuentes consiste en su totalidad en texto. Es por esto que esta pieza es la más importante ya que todos los cargadores que se encargan de analizar y filtrar la información en bruto que comentábamos en el punto anterior, vuelcan sus resultados en dicha base de datos.
Con vistas a independizar los módulos que se encargan de realizar las búsquedas inversas sobre nuestra base de datos, realizamos un recubrimiento mediante un API REST/JSON de la propia API del ElasticSearch. De esta forma, hemos podido ir realizando optimizaciones progresivamente sobre cómo y qué almacenábamos en nuestra base de datos sin que repercutiese de manera dramática en los módulos.
Por otro lado, como se puede ver en la arquitectura de la solución, existen dos tipos de módulos que hemos diferenciado en base a las etiquetas offline y online. Los módulos offline se encargan de realizar consultas sobre nuestra API que recubre nuestra base de datos. Esto permite realizar un análisis de cualquier compañía sin ser detectado ni dejar rastro ya que todas las consultas se realizan sin necesidad de servicios de terceros.
Por otro lado, los módulos online permiten aprovecharse de servicios de terceros como los que citamos en las anteriores entradas para encontrar y actualizar el análisis con nuevos activos no incluidos en la base de datos. Incluimos, entre otros, los módulos de dnsdumpster, subsearch y herramientas de fuerza bruta sobre DNS.
Todos los módulos, tanto offline como online, son completamente independientes y se fundamentan en el principio de responsabilidad única de igual modo que las arquitecturas orientadas a microservicios, es decir, realizan un solo tipo de búsqueda inversa y sólo una. Esto permite que dichos módulos puedan ser desarrollados de manera independiente y añadidos a la plataforma de manera transparente para el resto de componentes. También permite que los módulos computacionalmente más costosos sean fácilmente escalables horizontalmente, en caso de que fuese necesario, para aprovechar mejor la infraestructura.
 |
| Figura 5: Diagrama de cola de prioridades |
Ambos tipos de módulos son orquestados por el motor de Odin mediante una cola de prioridades, para lo cual en nuestro caso utilizamos Apache Kafka. Esto permite que el motor pueda darle más peso a los mensajes de un análisis en curso que a los de otro, o incluso, darle más peso a algunos mensajes dentro del mismo análisis. Dichos mensajes, una vez priorizados, serán procesados por orden de prioridad por los distintos módulos y devueltos a la cola hasta que hayan sido completamente analizados por todos los módulos disponibles.
Es el motor de Odin el que también se encarga de evaluar los mensajes en vuelo que contienen los activos de una compañía gracias a la información proporcionada por los módulos. Si dicho activo pertenece a un dominio o rango de los RIR, o comparte algún MX, NS o dirección de e-mail aceptado por el usuario como válido, el activo se incluye al resultado final. Si por el contrario, el usuario hubiera marcado como no válido el dominio, el rango, o los MX, NS o direcciones de e-mail compartidos, dicho activo se excluye del resultado final evitando de manera automática expandir el árbol de búsqueda a través de dicho nodo.
 |
| Figura 6: Dashboard del proyecto Odin |
Si el motor no dispone de información suficiente, presentará al usuario toda la información que dispone del nuevo activo, permitiendo al usuario aceptar esa información como válida o no para disminuir el número de falsos positivos de su análisis. Para terminar, este motor proporciona otra API REST/JSON sobre la cual hemos montado un frontend web que se encarga de facilitar la interacción con el usuario a la hora de la toma de decisiones durante el análisis.
Conclusiones
Tras más de un año de trabajo, podemos concluir afirmando que para hacer footprinting se pueden utilizar aproximaciones diversas, como hacer uso de datos ya procesados por otros servicios, o construir nuevas bases de datos usando las tecnologías de BigData para tener un entorno propio de investigación. En el siguiente vídeo se puede ver la presentación realizada en RootedCON del mismo.
Figura 7: Presentación en RootedCON 2016 del proyecto Odin
Finalmente, comentar que en este proyecto hemos explorado nuevas técnicas de footprinting, pero no quiere decir que sean las únicas, ya que siempre existen vías de mejora e innovación, así que espero que os haya gustado este trabajo y que os anime a iniciar vuestra propia investigación.
***************************************************************************************************
- Odin Parte 1: Técnicas y Herramientas para footprinting***************************************************************************************************
- Odin Parte 2: Las búsquedas inversas a implementar
- Odin Parte 3: El Big Data y el Servicio de investigación
Autores: Elías Grande (3grander) Alejandro Ramos (@aramosf) escritor de "Hacker Épico"
footprinting se pueden utilizar aproximaciones diversas.
ResponderEliminar