sábado, enero 21, 2017

Belgrano Latch: Una antena WiFi de gran potencia

Han pasado ya un gran número de artículos por este feed de posts desde que publiqué el artículo de Mandarache dedicado a la fabricación casera de Antenas WiFi de gran potencia, capaces de generar enlaces a 1.000 kilómetros de distancia. En aquel artículo se hablaba de un tipo de antenas que denominaron Belgrano.

Figura 1: Belgrano Latch. Una antena WiFi de gran potencia

Hoy sábado aprovecho para recordaros ese artículo - sobre todo a los más nuevos -, para que disfrutéis de la lectura y los vídeos que acompañan el artículo, pero sobre todo para dar las gracias al equipo que ha hecho esta Belgrano Latch tan chula.

Figura 2: Artículo sobre la fabricación de antenas WiFi de gran alcance

Como podéis ver, se trata de un antena WiFi del tipo que se explica en el artículo, muy útil para realizar proyectos de pentesting a redes inalámbricas desde ubicaciones bastante alejadas, al que han puesto un diseño de Latch.

Figura 3: Fabricación de las piezas de la Belgrano Latch

Tal y como se aprecia en las fotografías, el diseño ha sido realizado totalmente manual, e incluso se ha pintado con los colores que en ElevenPaths elegimos para nuestro querido Latch.

Figura 4: La antena con el logo de Latch. Mooola!

Yo no la tengo en mi poder, pero desde luego me encantaría poder tenerla y jugar con ella, así que si algún día me llega, os enseñaré una foto de ella en mi sitio en Telefónica, desde la "World Domination Room" que con una antena de estas características será más eficaz.

Figura 5: Antena Belgrano Latch conectada a un IBM ThinkPad para hacer un pentesting a distancia

Gracias por el trabajo y el cariño que le habéis puesto. Por desgracia esto no cuenta como parte del Concurso de plugins de Latch de este año, que ya tiene ganadores y que pronto comunicaremos públicamente. Disfrutad el fin de semana como voy a hacer yo, que el año se acelera rápidamente....

Saludos Malignos!

viernes, enero 20, 2017

Big Data Security Tales: ElasticSeach y Kibana objetivos del Ransomware #BigData

Cuando comenzó a funcionar económicamente el esquema del ransomware para los cibercriminales, era fácil de prever que esto iría mutando hacia el secuestro no solo de archivos - que sigue siendo un negocio de muchos BitCoins - sino de cualquier cosa que se pusiera por delante. Ya no basta con proteger los archivos de tus sistemas operativos Windows contra el ransomware, sino que hay que vigilar los programas críticos de la compañía, o de la la industria, ya que hemos visto ataques que han inutilizado hospitales o fábricas completas hasta que se ha pagado el rescate.

Figura 1: ElasticSearch y Kibana objetivos del ransomware

Supongo que en el proceso de cifrar archivos en los equipos, hubo un momento en que un ransomware cifró un archivo que era necesario para que funcionara una aplicación, y la víctima pago con diligencia, lo que hizo que se comenzara a focalizar este tipo de ransomware también en los sistemas industriales y las infraestructuras críticas, o como ya vimos, en los hospitales.

Figura 2: El ransomware se focalizó en los hospitales

Al final, el modelo de negocio de un ransomware es quitarte algo por lo que pagarías dinero por recuperar, ya sean las fotos de tus hijos, el teléfono de tu novia, los documentos de la empresa o el fichero con las contraseñas de tus cuentas bancarias. Si el ransomware te puede quitar algo así que necesites con urgencia, entonces tal vez sea más fácil para ellos hacer caja por devolvértelo.

Ransowmare focalizado en tu correo elecetrónico

Bajo esta premisa, el año pasado nosotros estuvimos trabajando en ver lo fácil que sería por un cibercriminal quitarte el correo electrónico que tengas almacenado en la nube, y jugando con el robo de Tokens OAuth publicamos el estudio de Sappo (Spear-Apps to Steal OAuth Tokens) y mostramos como un ransomware puede cifrarte el correo. Parece una locura, pero no en los tiempos que vivimos, e hicimos un estudio y una PoC para robarte el correo de Office 365, al que llamamos RansomCloud O365.

Figura 3: Demo de RansomCloud O365

Estos días, seguro que todos habéis oído hablar del ramsonware que se está llevando por delante las bases de datos MongoDB inseguras, aprovechándose de algo tan sencillo como el uso de credenciales por defecto en muchos de estos entonos - de lo que hablamos hace ya mucho tiempo en el artículo de "Vigila que tu MongoDB no le de los datos a cualquiera". Según las cuentas echadas, podrían ser más de 34.000 bases de datos las que hayan caído bajo este esquema de ransomware.

Ransomware a por ElasticSeach

Visto que el esquema funciona, ¿por qué no seguir con cualquiera de los muchos servicios que están publicados en Internet con contraseñas por defecto? Hay muchos servicios abiertos a Internet con datos críticos para sistemas que pueden ser cifrados por un ransomware y secuestrar la información. En esta serie de Big Data Security Tales ya hemos hablado de algunos paneles de administración que adolecían de esta vulnerabilidad, o haciendo uso de los sistemas - aún vulnerables - a Connection String Parameter Pollution (CSPP) se podrían gestionar muchas aplicaciones que acabaran con las bases de datos relaciones adminsitradas por ellos.
Una de las víctimas que ha comenzado a ser utilizada en este esquema ha sido el servicio de ElasticSearch, muy común en los entornos de Big Data. Este motor de búsqueda es clave en el alto rendimiento de muchas aplicaciones que funcionan en entornos de alto rendimiento, ya que su capacidad de generar índices para acceder a los datos almacenados en sistemas de clave-valor es fundamental para que sea factible el manejo de los volúmenes de datos con los que trabajamos hoy en día.

Figura 5: Mensaje en un índice de ElasticSearch víctima de un ransomware

Son muchos los que están expuestos con credenciales por defecto y sin credenciales de acceso, lo que permite a los atacantes buscarlos, conectarse a ellos y cifrar el contenido de los índices para que aparezca un único mensaje en texto claro como el que veis en la imagen superior.

ElasticSeach & Kibana en Shodan

Estos servicios de ElasticSeach son fáciles de localizar haciendo un poco de hacking con buscadores, y en Shodan, hay miles de ellos solo con buscar el puerto por defecto Well-Known que usan: El 9200. Una conexión al servidor y se accede al JSON que indica que el servicio está Up & Running y accesible.

Figura 6: Servicios de ElasticSearch descubiertos en Shodan

No es necesario ni conectarse para saber que está abierto, ya que si lo está, en Shodan aparecerá en la información que se muestra junto con el puerto, el nombre del cluster, el número de nodos, el número de índices, el tamaño y el estado en que se encuentra el índice.

Figura 7: Conexión a un servicio de ElasticSeach abierto en Internet

Como se puede ver es un entorno basado en comunicación JSON, pero se puede poner más bonito usando otro servicio muy popular que es Kibana. Este servicio no es nada más que un entorno cliente de conexión a los índices de ElasticSearch que permite trabajar "in a friendly way". También es fácil localizarlo, buscando por el puerto 5601 y haciendo una petición web. 

Figura 8: Búsqueda de servicios Kibana en Internet

Si lo tiene abierto, el servicio dejará explorar, buscar y gestionar los índices con los que ElasticSearch está funcionando, lo que atrae la atracción de un posible atacante hacia tu entorno de Big Data.

Figura 9: Servicio Kibana abierto a Internet descubierto con Shodan

Al final, los cibercriminarles van a buscar eso que tú más quieres e intentar quitártelo. No para siempre si pagas, pero te lo van a quitar el tiempo suficiente para que tú desembolses los BitCoins que ellos quieren obtener de este negocio. Ten cuidado con tus activos.
- Big Data Security Tales: ¡Vigila que tu MongoDB no le de tus datos a cualquiera! (Level 100)
- Big Data Security Tales: Cómo funcionan las MongoDB Injection
- Big Data Security Tales: MongoDB y Cassandra (Level 101)

- Big Data Security Tales: Apache Hadoop expuesto por no configurar HUE (Level 102)
- Big Data Security Tales: Django en HUE en modo DEBUG y con Directory Listing (Level 103)
- Big Data Security Tales: Las Interfaces de acceso al HDFS
- Big Data Security Tales: Apache Amabari Default Admin
- Big Data Security Tales: WSO2 Carbon y la ayuda para el Login
- Big Data Security Tales: Los Known-Bugs en WSO2 Carbon Server
Post Data: Recuerda que para tus documentos en Windows puedes probar Latch ARW que protege las carpetas con una capa adicional de seguridad que evita que te puedan cifrar el contenido con un ransomware que use tus credenciales de usuario.

Saludos Malignos!

jueves, enero 19, 2017

Odin, identificando el Shadow IT en la era del Big Data. Parte III: La construcción del Big Data

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.

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"

miércoles, enero 18, 2017

Cómo buscar exploits automáticamente para elevar privilegios en GNU/Linux #Linux #Pentesting

La automatización es uno de los procesos más necesarios en muchas de las tareas técnicas, y en el mundo del pentesting no es, por supuesto, un tema menor. En otras ocasiones hemos comentado cómo automatizar el uso de los payloads en un proyecto de Ethical Hacking a través de herramientas como WinPayloads, cómo se pueden automatizar los ataques de Pharming con dispositivos de red o cómo generar un proceso automatizado para la búsqueda de vulnerabilidades en repositorios de código fuente a través de la detección de funciones potencialmente vulnerables.

Figura 1: Cómo buscar exploits automáticamente para elevar privilegios en GNU/Linux

Es muy común, en el día a día, buscar la posibilidad de llevar a cabo la automatización de cualquier tarea de gran tamaño, pesada o que se repite con frecuencia y, como he comentado anteriormente, en el pentesting o en las investigación de seguridad, es algo que hacemos con regularidad, e incluso en ElevenPaths tenemos automatizada la mayor parte de las pruebas de seguridad que hacemos en los servicios de Pentesting Persistente que damos con Faast y Vamps, que luego un auditor de seguridad gestiona.

Figura 2: Panel de control de evolución de vulnerabilidades en Faast

Debe ser el auditor o el pentester el que aporte inteligencia y rigor a la hora de tomar decisiones, de interpretar resultados, de confirmar lo que una herramienta sugiere o afirma. El auditor debe controlar en todo momento el proceso que lleva a cabo, apoyándose en las herramientas automáticas solo para mejorar el alcance y posibilidades reales. Aún así, hay muchas tareas en los procesos de pentesting que si no se automatizan, hacen que sea infinita o, en su defecto, insuficiente, las jornadas de trabajo de un profesional para mantener de forma actualizada un foto de la seguridad de un sistema.

Figura 3: Conferencia sobre la búsqueda de vulnerabilidades en repositorios de código

En el artículo de hoy, hablaré de una herramienta interesante como es AutoLocalPrivilegeEscalation. Esta herramienta, disponible en un script de bash o en un script de Python, que proporciona al auditor la posibilidad de buscar en un repositorio de exploits, como es exploit-db, aquellos que pueden tener potencial para aprovecharse de vulnerabilidades que provoquen la escalada de privilegios en sistemas más o menos fortificados de GNU/Linux.

Figura 4: AutoLocalPrivilegeEscalation en GitHub

AutoLocalPrivilegeEscalation utiliza por debajo la herramienta searchsploit, disponible en Kali Linux 2. Searchsploit permite realizar búsquedas de exploits sobre la base de datos en local de exploit-db, es decir, si nos fijamos, en Kali Linux se tiene almacenado en la ruta /usr/share/exploit-db todos los exploits disponibles en la web, cada uno escrito en el lenguaje original en el que fue escrito.

Por ejemplo, la mayoría de los exploits locales para Linux estarán escritos en Lenguaje C muy común en los amantes del Linux Exploiting, pero si echamos un ojo también encontraremos algunos escritos en Ruby. Estos escritos en Ruby realmente son módulos escritos para Metasploit con el objeto de aprovecharse de las funciones de las sesiones remotas y escalada de privilegios.

Instalando AutoLocalPrivilegeEscalation

Para obtener esta herramienta de automatización podemos utilizar git clone para descargarlo en nuestro sistema Kali Linux 2. No requiere instalación, solamente tenemos que descargarlo y podemos ejecutar tanto el script en bash auto_priv_exploit.sh y el script en Python auto_searchsploit.py.

Figura 5: Instalación de AutoLocalPrivilegeEscalation

Una vez descargado tenemos disponible la herramienta, cuyo uso es prácticamente trivial. De todos modos, se puede consultar la ayuda en el sitio de Github de la propia herramienta. Hay que tener en cuenta que searchsploit debería estar lo más actualizado posible.

Buscando los exploits potencialmente válidos

La herramienta tiene un parámetro de entrada que es la versión del kernel del que se quiere encontrar un exploit potencialmente válido. Para mirar la versión del kernel, se puede ejecutar en una consola de Linux el comando uname -a o uname -r.

Figura 6: Búsqueda de exploits. Se necesita la versión del kernel

Para realizar búsquedas, simplemente se debe ejecutar el script con el parámetro de la versión del kernel de Linux sobre el que queremos obtener exploits potenciales. Como se puede ver en la imagen, tras indicar una versión del kernel, se obtiene un listado de exploits, la mayoría en Lenguaje C. Es importante mantener actualizada la base de datos de exploit-db, y por ello se recomienda actualizar searchsploit.

Figura 7: Lista de posibles exploits para la versión del kernel 2.6

Lógicamente, esto nos ofrece una ayuda a la hora de buscar los exploits adecuados, pero al final debemos mirar la información adecuada para cada caso. En el caso de DirtyCow, la cual ya la hemos visto en este blog, es sencillo. Con el uso de la herramienta AutoLocalPrivilegeEscalation nos sale la posibilidad y llevamos a cabo la compilación.

Figura 8: Ejecución de DirtyCow para elevar privilegios

Además, hay que tener en cuenta que AutoLocalPrivilegeEscalation proporciona la posibilidad de obtener los exploits para dicha versión del kernel y nos preguntará si queremos llevar a cabo la compilación.


Figura 9: Demostración de DirtyCow


En definitiva, como vimos en su día con herramientas como Exploit Suggester para buscar exploits para MS Windows, la automatización o simplificación de procesos puede ayudar. Esta herramienta nos permite optimizar o automatizar el uso de searchsploit y la búsqueda de exploits. Sin duda, otra herramienta que debemos tener a mano en la mochila en un pentesting ante la posibilidad de tener una shell en Linux y no disponer de una shell como root.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell

martes, enero 17, 2017

Odin, identificando el Shadow IT en la era del Big Data. Parte II: Las búsquedas inversas a implementar

Continuando con la recopilación de conocimiento y lecciones aprendidas durante el desarrollo del proyecto Odin que comenzamos en la entrada anterior donde hablamos de las herramientas y técnicas de footprinting, en esta parte describiremos los nuevos vectores de identificación de activos de una compañía que hemos explorado en el proyecto. Antes de comenzar, el concepto de búsqueda inversa debe quedar claro, ya que todas las técnicas utilizadas se basan en el cruce de información para dotar al servicio de esta capacidad.

Figura 1: ODIN, Identificando el Shadow IT en la era del Big Data. Parte II.

Un ejemplo de búsqueda inversa sería la siguiente: si un dominio tiene asociado un servidor de correo, probablemente los dominios que compartan dicho servidor pertenezcan a la misma compañía así que, ¿qué otros dominios tienen asociado el mismo servidor de correo? Es decir, algo similar a utilizar el servicio IP de Bing para saber qué sitios web comparten la misma dirección IP.

Búsquedas inversas clásicas y nuevas búsquedas

En primer lugar, el proyecto no debía perder funcionalidad en comparación con los servicios de terceros ya citados en la anterior entrada, por lo que de inicio se debía permitir realizar las búsquedas inversas clásicas como son:
• NS compartido, por registro del tipo NS en la configuración DNS o por servidores DNS configurados en el registrador de whois. 
• MX compartido, consultando la información indexada de DNS. 
• Búsqueda de subdominios, ya sea en certificados x509, en DNS o indexados en Internet. 
• Búsquedas inversas de dominios, buscando mediante el correo electrónico en la información almacenada de whois.
En segundo lugar, y con vistas a explorar nuevas técnicas de footprinting, implementamos nuevos métodos no utilizados hasta la fecha por otras herramientas, como son la búsquedas inversas de etiquetas de redes sociales y aplicaciones de Google Analytics, de registros DNSSEC, usando los campos “O” y “OU” de los certificados X.509, y por último, incluimos las búsquedas inversas en base al registro DKIM descrito en la especificación DNS.

Búsqueda inversa mediante redes sociales

El objetivo es relacionar los nombres de usuario corporativos de redes como Twitter, Facebook e Instagram con los dominios y subdominios que los contienen. De esta forma, si una web incluye un enlace con el botón “Follow Me” de Twitter, es posible identificar el usuario corporativo.

Figura 2: Primera búsqueda por Redes Sociales

Una vez almacenada toda la información y su relación, la búsqueda inversa se realiza por el nombre de usuario de la red social y se obtienen otros dominios con el mismo estilo de enlace “Follow Me”, y por lo tanto, pertenecientes a la misma compañía. Un ejemplo de este tipo de búsqueda se muestra en la siguiente captura de pantalla del host “www.simulator-orgeffectiveness.com” que tiene un enlace a su Twitter: “strategyand”.

Figura 3: Búsqueda inversa por Redes Sociales

Una vez obtenido el usuario corporativo de Twitterstrategyand”, en la segunda captura, se puede observar como una web de desarrollo con nombre “strategyand-dev01.atlasworks.com” perteneciente a otro dominio tiene el mismo botón de twitter al mismo usuario “strategyand” y, por lo tanto, es posible relacionarla con la anterior si hiciéramos una búsqueda inversa.

Búsqueda inversa de registros DNSSEC

DNSSEC (del inglés Domain Name System Security Extensions) es la versión segura del servicio de resolución de nombres de dominio DNS. Del mismo modo que con el DNS, dispone de varios registros sobre los que se puede realizar búsquedas inversas, como son el registro DNSKEY y el registro DS:
• El registro DNSKEY contiene la clave pública usada en las operaciones de firma de zonas. 
• El registro DS es usado para identificar la clave de firmado de zonas delegadas.
Tanto la clave pública DNSKEY como los hash de los registros DS son índices de consultas inversas y permiten conocer qué otras zonas utilizan esa misma información.

Figura 4: Búsqueda inversa por información del servicios DNSSEC

En el siguiente ejemplo podemos observar como el registro DNSKEY del dominio “cryptoserver.org” y del dominio “hopfenblatt.de” es el mismo y, por lo tanto, sería posible relacionarlos si hiciéramos una búsqueda inversa.

Búsqueda inversa en certificados x509

Es común el uso de la información que incluyen los certificados en los campos “CN” y “SAN” para identificar subdominios o dominios alojados en una misma dirección IP, como hace FOCA para identificar el nombre de todos los dominios para los que posible utilizar un mismo certificado digital.

Figura 5: Nombres de dominio localizados en FOCA con los certificados digitales

Pero además de estos datos, también es posible realizar búsquedas de otros dominios llevando a cabo consultas de aquellos certificados que comparten los campos O (Organizational) y OU (Organizational Unit) y que juntos identifican a la compañía.

Figura 6: Búsqueda inversa por certificados X.509

En el ejemplo mostrado en la Figura 6 se muestra el certificado de la web “www.upwork.com” y en el que su campo Organizational (O) del certificado es “Upwork Inc”. Si realizamos una búsqueda de ese valor en todos los certificados, se detectaría un nuevo dominio “elance.com” para la misma compañía, tal y como muestra la imagen de la derecha.

Búsqueda inversa por ID de Google Analytics

Al igual que ocurre en las redes sociales, los sistemas de Web Analytics disponen de un código único que se debe insertar, generalmente como javascript, en la página web de la que se desea obtener estadísticas. Por ejemplo, Google Analytics utiliza el formato “UA-XXXXXX-Y” que es un código único por cada uno de sus usuarios:
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
 
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
</script>
A continuación se mostrará el ejemplo de búsqueda inversa por el identificador de Google Analytics en las páginas “www.riotgames.com” y “oce.leagueoflegends.com”. En primer lugar si hacemos la búsqueda en el HTML de “www.riotgames.com”, encontramos el identificador “UA-5859958” (se omite el último número ya que identifica el activo concreto de la cuenta de usuario UA-5859958)

Figura 7: Extracto HTML de www.riotgames.com

Si realizamos la misma búsqueda en el HTML de “oce.leagueoflegends.com”, encontramos el mismo identificador “UA-5859958

Figura 8: Extracto HTML de oce.leagueoflegends.com

Generando una base de datos con todos los dominios y los códigos de este estilo, se puede realizar una búsqueda por el código para obtener un listado de los dominios que la utilizan. Esto mismo es aplicable a otras aplicaciones como Woopra, Google ADs, Yandex Metrica, Piwik, KissMetrics, MixPanel, Bizible, Segment, Amplitude, etcétera.

Búsqueda inversa de registros DKIM de DNS

El registro DKIM (DomainKeys Identified Mail) se utiliza para identificar la legitimidad de los e-mails enviados desde un dominio y contiene la clave pública utilizada para la verificación de la firma digital de dicho dominio en cada uno de los mensajes. No está muy extendido todavía, pero sigue la filosofía de los registros DNSKEY de DNSSEC. 

Figura 9: Firma DKIM de un mensaje enviado desde un servidor de Yahoo!

En el siguiente ejemplo podemos observar como el registro DKIM incluido en los registros TXT del dominio “77covers.com” y del dominio “77vines.com” son el mismo y, por lo tanto, es posible relacionarlos si hiciéramos una búsqueda inversa.

Figura 10: Búsqueda inversa por información DKIM

Finalmente, tras haber identificado estas consultas técnicas no implementadas hasta la fecha por ningún servicio de terceros, se generan dos necesidades en el desarrollo del proyecto Odin:
• Recopilación de toda la información existente en Internet necesaria para cubrir todos los vectores de footprinting descritos. 
• Un desarrollo propio que apoyado en tecnologías Big Data permita la viabilidad del proyecto, siendo completamente independiente de cualquier servicio de terceros para su funcionamiento.
En la siguiente y última entrada abordaremos cómo la solución propuesta para realizar dicho proyecto nos cubrió las dos necesidades comentadas.

***************************************************************************************************
- 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"

lunes, enero 16, 2017

El BUG de WhatsApp que permite que te espíen mensajes... y te roben las llamadas de WhatsApp Call

Tras ver todos los casos de espionaje publicados tras los documentos filtrados por Edward Snowden, no hace falta decir que la sensibilidad de todo el mundo con el tema de la privacidad es alta. Por eso, los sistemas de mensajería cifrada extremo a extremo (e2e encryption) aparecieron por muchos rincones de Internet. WhatsApp fue uno de los que añadió esta capacidad - a pesar de que en iPhone la base de datos permanece sin cifrar en el dispositivo - a sus sistemas de comunicación, haciendo uso del protocolo que implementa Signal, la herramienta de mensajería con e2e encryption diseñada por Moxie Marlinspike.

Figura 1: El BUG de WhatsApp que permite que te espíen mensajes

Ahora, la polémica ha venido cuando el investigador de seguridad Tobias Boelter ha publicado un bug en WhatsApp que, por motivos de usabilidad, permite a un atacante acceder a los mensajes que no han llegado aún a su destinatario por la forma en la que la implementación de WhatsApp permite hacer regeneración de claves de cifrado automáticamente para usuarios offline. Esto es fácil de entender, vamos a verlo paso a paso, y nada complicado de implementar para aquellos que quieran espiar WhatsApp.

El bug de reenvío de mensajes en WhatsApp

A día de hoy WhatsApp usa cifrado e2e, por lo que cada conversación entre dos personas va cifrada con las claves públicas del destinatario. Es decir, cada mensaje que se cifre con la clave pública del destinatario solo podrá descifrarse si se posee la clave privada asociada, que es generada por cada usuario en el dispositivo. Esto quiere decir que, cuando una persona instala y configura WhatsApp en su teléfono, automáticamente se genera un par de claves pública y privada nuevas. La pública será enviada a todos los contactos y la privada permanece en el dispositivo. 

Cualquier contacto puede verificar, vía WhatsApp, que las claves de cifrado públicas que se están utilizando en la conversación son las correctas tal y como se explica en este artículo [Verificar claves de cifrado de contactos de WhatsApp] y además, cada usuario podrá activar en las opciones de WhatsApp->Seguridad la posibilidad de recibir un mensaje cada vez que se cambien las claves. Esta opción hay que ponerla siempre, como parte de las recomendaciones que existen para Proteger WhatsApp a prueba de balas, pero como vamos a ver aquí, no es suficiente.

Figura 2: Opciones de Seguridad de WhatsApp para recibir alertas

Ahora bien, ¿qué pasa si tú envías un mensaje a un terminal y este está apagado? Pues aquí viene el fallo en la implementación de WhatsApp. Supongamos el siguiente escenario. Yo soy un objetivo de un ataque porque soy un presidente de una empresa que está sufriendo un APT o un objetivo político de un gobierno que va a tomar un avión que le va a llevar de Madrid a Washington D.C. para una reunión. Mi teléfono va a estar en modo avión durante 7 u 8 horas, por lo que ningún mensaje que me envíen por WhatsApp me va a llegar.

Todos los mensajes que me envíen durante el tiempo que estoy en modo vuelo aparecerán en el terminal de los emisores con un solo tic, y en los servidores de WhatsApp cifrados con la clave pública de mi teléfono. Algo que por seguridad, podría haber verificado con todos mis contactos.

Figura 3: Verificación del código de cifrado con mis contactos

Ahora pongamos por un momento que los atacantes han conseguido una copia de la tarjeta SIM o han hecho un SIM Swapping, o si es el gobierno del país, ha solicitado un duplicado de la misma con una orden judicial. En ese momento la NSA - suponiendo que fuera ese gobierno USA y los tiempos de los que hablaban los documentos de Edward Snowden - podría registrar mientas el objetivo está volando, la cuenta de WhatsApp en un nuevo dispositivo. Ahí viene el fallo.

Pues bien, la característica implementada por Facebook hace que, automáticamente los servidores de WhatsApp recibirán una notificación de cambio de clave pública del destinatario de los mensajes y, para que la experiencia de usabilidad sea mejor, pide a todas las apps de WhatsApp de los emisores de los mensajes que cifren y envíen - automáticamente y sin capacidad de pararlo - otra vez todos los mensajes que aún no han sido entregados, pero cifrados con la nueva clave pública del destinatario.

Si el usuario ha activado la opción de recibir alertas de seguridad, entonces DESPUÉS de haber enviado los mensajes, el emisor recibirá una alerta que explica que se han cambiado las claves - probablemente por un cambio de dispositivo - y que puede verificarlas otra vez.

Figura 4: El emisor recibe la alerta después, pero el mensaje se envía antes

Esto es un bug que permite a un atacante interceptar mensajes de sus víctimas en ciertas circunstancias, pero la queja de los expertos en criptografía no es solo referida a este fallo - que WhatsApp puede cambiar simplemente pidiendo confirmación de que quiere enviar los mensajes al destinatario con la nueva clave ANTES de enviarlos, sino que al ser una app de código cerrado, es difícil verificar todo el proceso. 

No es el caso, pero una app de cifrado e2e en mensajería podría decir en su interfaz que está usando unas claves, y luego estar usando otras o, directamente, enviar el mismo mensaje varias veces y cada vez cifrado con una clave distinta. Por eso, muchas organizaciones activistas recomiendan no usar bajo ningún concepto software criptográfico que no sea OpenSource para que pueda ser revisado completamente el proceso.

Figura 5: Recomendación de The Guardian para dejar de usar WhatsApp

Como se puede ver online, el periódico The Guardian recomienda directamente NO utilizar WhatsApp si te preocupa de verdad el cifrado e2e en los mensajes y dejar de usarlo, ya que esta forma de funcionar no garantiza que el mensaje que has enviado con una clave de cifrado vaya a ser el que se utilice al final para ello. No hay que olvidar que The Guardian fue el primer medio que publicó los documentos filtrados por Edward Snowden, y que Facebook aparecía como parte de los participantes del programa PRISM para espiar de forma automática perfiles en Internet.

Figura 6: Diapositiva del programa PRISM filtrada por The Guardian

En el vídeo de la demostración puede verse cómo funciona el proceso completo, y además es muy fácil de probar. Puedes además acceder a las diapositivas de Tobias Boelter que explica paso a paso el bug y al blogpost [WhatsApp Retransmission Vulnerability] que lo detalla.

Figura 7: Vídeo de la demostración del bug por Tobias Boelter

Internamente hemos probado el bug, y hemos hecho este vídeo que explica exactamente lo mismo pero en Español, para que no se quede nada sin entender de lo que está sucediendo.


Figura 8: Demostración del bug explicada en Español

Este comportamiento explica muchas de las preguntas que yo hacía en el caso de la desaparición de una joven en la que los cuerpos de seguridad del estado podrían haber accedido a los mensajes no recibidos de la chica desaparecida, y por lo tanto podrían llegar a conseguirse los logs de los envíos y reenvíos - direcciones IPs, ubicaciones, y horas  - de los terminales usados por las personas que enviaron los mensajes mientras el terminal estaba apagado.

Figura 9: Mensaje de Signal antes de re-enviar los mensajes

Como nota final, hay que decir que Signal, la herramienta original de cifrado de mensajes e2e no tiene este bug en la implementación y avisa de esta circunstancia antes de que se envíe el mensaje al destinatario con las nuevas claves recibidas.


Figura 10: Demostración del bug con WhatsApp Call

Actualización: Como se puede ver, el bug también afecta al servicio de WhatsApp Call, por lo que es posible recibir las llamadas que se envían cuando el terminal está offline. En el vídeo, el investigador Tobias Bolter hace la demostración

Saludos Malignos!

domingo, enero 15, 2017

Odin, identificando el Shadow IT en la era del Big Data. Parte I: Técnicas y Herramientas de footprinting

Durante este año hemos presentado en la edición de RootedCON Madrid, en la edición de la RootedCON Valencia y en la  edición de Navaja Negra el proyecto "Odin",  cuya única misión es impulsar la identificación de todos los activos que una empresa tiene en Internet apoyándose para ello en tecnologías Big Data. Es por eso, que haremos una recopilación del trabajo de un año entero sobre todas las lecciones aprendidas durante el desarrollo de este proyecto para poder compartir así dicho conocimiento.

Figura 1: Odin, identificando el Shadow IT en la era del Big Data. Parte I

Esta recopilación de conocimiento se dividirá en tres partes: introducción y estado del arte de las herramientas existentes, nuevos vectores de identificación de activos de una compañía, y finalmente, cómo las tecnologías Big Data han sido necesarias a la hora de hacer viable la identificación de activos de una compañía en base a la gran cantidad de información existente en la Internet.

En primer lugar, la identificación por completo de todos los activos que una compañía tiene públicos en Internet, es decir, descubrir el Shadow IT de la compañía, no es un problema nuevo. Todo cuenta a la hora de ir incrementando este mal en la empresa, ya sea por culpa de servidores antiguos no inventariados cuyos responsables ya no forman parte de la empresa o nuevos proyectos iniciados por departamentos como Marketing, RRHH u otros, que al contar con sus propios presupuestos dentro de la organización, a veces no informan a los departamentos de IT y/o Seguridad de sus nuevos servicios, dificultando que sean analizados a tiempo, fortificados y se apliquen sobre ellos todas las medidas de seguridad de las que disponga la organización.

Es llamativo que en una sociedad que inventariamos cada prenda de ropa, cada lata de comida o incluso cada persona, no seamos capaces de inventariar cuantos servidores tiene una empresa públicos en Internet, algo que queda patente en los múltiples programas de bug bounty de HackerOne, y en los ejemplos de pentesting persistente que muchas veces vemos por aquí

Figura 2: Servidor olvidado en Pornhub

Si la compañía es de ámbito internacional, compuesta por decenas de empresas, miles de direcciones IP y centenares de dominios, es prácticamente imposible que exista un repositorio único y centralizado con esta información tan básica. Por este motivo, en algunas ocasiones, los métodos de descubrimiento de activos con técnicas de pentesting - la herramienta Faast de ElevenPaths tiene esta característica entre sus mayores fortalezas -, o también llamados de footprinting, son los encargados de alimentar los inventarios internos o bases de datos de gestión de la configuración.

Introducción al footprinting

Desde una perspectiva de ataque externo, el objetivo fundamental del footprinting es aumentar la superficie de exposición, inventariando todas las direcciones IP y dominios que componen la presencia de la organización en Internet, así como el descubrimiento de servicios y versiones que tienen cada una de ellas, con vistas a encontrar “la gacela herida” de la compañía de la que habla tanto Chema Alonso en sus conferencias. Entre las técnicas más relevantes y comúnmente utilizadas para obtener información de una compañía están:
• El uso y abuso de consultas DNS.
• Datos de los Registros Regionales de Internet (RIRs)
• Información de dominios (whois)
Si somos capaces de gestionar la información obtenida durante el footprinting de una compañía en distintos momentos temporales, su valor será mucho mayor ya que aquellos elementos nuevos serán los susceptibles de disponer de vulnerabilidades no gestionadas.

Uso y abuso de consultas DNS

Los servidores DNS no permiten más consultas que las reflejadas en la propia definición del DNS [RFC-1035], lo cual impide búsquedas inversas con el fin de cruzar datos. Para ejecutar dichas búsquedas inversas es necesario utilizar servicios de terceros, como el servicio robtex.com o dnsdumpster.com ya que es requisito tener toda la información indexada previamente para poder saltarse las restricciones de consultas DNS no definidas.

Figura 3: Servicio DNSDumpster

Mediante estos servicios de consultas DNS se buscan todos los dominios y subdominios de una compañía, utilizando para ello distintos métodos complementarios entre sí.
• NS compartido: dado el host de un servidor de nombres conocido, identificar que otros dominios aloja.
• MX compartido: dado el host de un servidor de correo electrónico de entrada, detectar que otros dominios lo comparten.
• SOA compartido: dado el correo electrónico del registro SOA, buscar que otros dominios usan el mismo correo.
• Dominios que apuntan a la misma IP: dada una dirección IP detectar que otros dominios apuntan (registro A) a esa misma dirección IP.
• Subdominios: buscar todos los subdominios existentes, ya sea porque están indexados en la web y son conocidos o porque se buscan mediante fuerza bruta.
Herramientas como FOCA hacen uso intensivo de esta explotación del DNS, buscando también los registros SRV, los Primary Master, haciendo PTR escaningescaneo con Robtex de registros PTR, registros TXT que delatan los servicios de correo, y hasta el análisis de la caché de los servidores DNS, etcétera.

Figura 4: Módulo de DNS Cache Snooping en FOCA

Hacer un uso abusivo de las consultas y opciones de los servicios DNS puede llegar a servir hasta para hacer un fingerprinting del software de los propios servidores DNS, como se explica en este artículo. Todas estas técnicas son también usadas en los módulos de DNSRecon que viene dentro de la distribución para pentesting Kali Linux.

Datos de los Registros Regionales de Internet

Los Registros Regionales de Internet son los organismos encargados de asignar y gestionar el direccionamiento IP en Internet. Están divididos por zonas geográficas, RIPE para Europa, ARIN para América del Norte, APNIC para Asia y Oceanía, LACNIC para América Latina, y AfriNIC para África.

Figura 5: Registros Regionales de Internet

Consultando estas bases de datos es posible identificar los rangos que tiene asignados una compañía, ya sea preguntando por una dirección IP para obtener el rango al que pertenece o haciendo la consulta sobre un nombre de compañía para obtener todos los rangos de los que dispone.

Figura 6: Uso de operador net: en Shodan

Estos datos pueden ser cruzados después con los motores de búsqueda, y hacer un poco de hacking con buscadores con Google o Shodan, para haciendo uso de los comodines en Google o el NetRange en Shodan, cualificar los servidores que ya han sido descubiertos por los bots de estos buscadores dentro del rango de la empresa.

Información de dominios (whois)

Cada vez que se compra un dominio nuevo, el registrador almacena en su propia base de datos información del propietario, como son los correos electrónicos del personal “administrativo”, “técnico” y “registrante” o la información de los servidores DNS que se encargarán de su resolución.

Estos datos son usados para hacer búsquedas inversas, es decir, dado un correo electrónico conocido de un dominio, encontrar otros dominios registrados con la misma dirección. Para este tipo de consultas hay servicios online como whoisology.com o viewdns.info

Figura 7: Servicio de ViewDNS.info

Además, se pueden utilizar los servicios avanzados que muestran no son los datos actuales en las bases de datos, sin los datos de los registros whois históricos en herramientas como whois.ws o domaintools.

Figura 8: Datos del registro Whois de Apple en 2009 y 2013 (derecha)

Juntando todos estos datos, es posible obtener y cruzar información de muchas fuentes que a día de hoy no están cruzadas.

Estado del arte de las herramientas de footprinting

En la actualidad ya existen decenas de herramientas para llevar a cabo el footprinting de forma manual y también de forma automática. Algunas son pequeñas utilidades y otras son grandes proyectos. La gran mayoría de estas aplicaciones utilizan servicios de terceros y se alimentan de la información que estos les proveen.

Si observamos las utilidades más significativas, ninguna de ellas tiene como único objetivo llevar a cabo el footprinting y abarcan tareas mucho más complejas como el descubrimiento de vulnerabilidades, la inteligencia de fuentes abiertas (OSINT) o la investigación de información relacionada a una IP, como por ejemplo el análisis del origen de un malware. Entre algundas de las utilidades más significativas que ya conocemos, podemos destacar las siguientes (aunque hay muchas más y cualquiera que dejes en los comentarios será bienvenida)
FOCA: herramienta que permite obtener el direccionamiento y dominios de una compañía, además de algunas vulnerabilidades y metadatos. Su método de uso es prácticamente automático. Si no has visto esta charla en DefCON sobre FOCA, toca verla hoy - además es un plus ver a un Chema Alonso de hace 8 años sin gorro dando una conferencia -

Figura 9: [2008] The FOCA Strikes Back

Spiderfoot: utilidad que obtiene información de decenas de fuentes distintas y modulables, muy activa y extensivamente utilizada. Su uso también es automático.
Maltego: aplicación gratuita y comercial que permite llevar a cabo investigaciones o footprintings. Representa gráficamente los resultados pero está orientado a un uso manual y mucho más exhaustivo. Es una plataforma de investigación completa que puede usarse para cualquier tarea de investigación. Los datos de las apps que recoge la base de datos TACYT (Direcciones IP, URLs y direcciones de e-mail) también se pueden integrar con la herramienta.
Figura 10: Integración de datos de Tacyt en Maltego

La complejidad de las plataformas tecnológicas y cómo se relaciona la información DNS, con la información de empleados y con otros datos de la compañía, puede provocar que estas herramientas automáticas, mezclen datos, confundan e interpreten erróneamente las respuestas, dando lugar siempre a la necesidad de revisar manualmente los datos obtenidos. Estas situaciones se dan por ejemplo en los siguientes casos:
• Un empleado usa su correo profesional para registrar un dominio privado.
• La compañía usa un hosting compartido con otras empresas.
• El uso de redes CDN, con configuraciones compartidas entre empresas y configuraciones DNS complejas.
• Una empresa de nombre similar tiene información en un RIR.
Finalmente, tras realizar un estudio previo, identificamos en este proyecto que se necesitaba aportar nuevas ideas en cuanto a vectores de footprinting mediante un sistema que estuviera focalizado única y exclusivamente en este objetivo de descubrimiento de activos de una compañía.

También es por todos sabido, que la cantidad de falsos positivos de las herramientas actuales es proporcional al nivel de automatización de la herramienta, por lo que era necesario pensar en un automatismo controlado de tal forma que si un analista de inteligencia utilizara el proyecto, le fuera sencillo podar los árboles de búsqueda para minimizar dichos falsos positivos. En las siguientes entradas abordaremos tanto los nuevos vectores de footprinting como la solución propuesta para realizar dicho proyecto.

***************************************************************************************************
- 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"

Entrada destacada

Actividades de formación Online y eventos para Enero

Poco a poco voy volviendo al ritmo de combate en mi actividad natural. Ha sido solo una semana desde que me volví a poner en la casilla de ...

Entradas populares