Storm Breaker: ¿Qué me puede pasar con sólo hacer clic en un enlace?

Hace unos meses, Chema Alonso fue entrevistado por Antonio Fernandes en su canal de Youtube sobre "Cultura de la Ciberseguridad". En el minuto 47:30 de la entrevista, Lord Draugr, un Youtuber que centra su contenido en investigaciones de todo tipo, hace un cameo para preguntarle a Chema sobre los peligros que puede correr alguien por el simple hecho de hacer clic en un enlace.

Figura 1: Storm Breaker: ¿Qué me puede pasar con sólo hacer clic en un enlace?

Si quieres, puedes ver la entrevista completa, que está publicada en Youtube, así que si te animas a pasar un rato con Chema y Antonio, aquí la tienes, que hablan de muchas cosas interesantes.


Figura 2: Entrevista a Chema Alonso en Cultura de Ciberseguridad
Sobre esta pregunta que os comentaba, yo siempre estoy dándole vueltas a ver qué me puedo automatizar o qué puedo crear para mis andanzas en los programas de Bug Bounty, que ya sabéis que al final Chema Alonso me lío para hacer incluso un libro de esto en 0xWord titulado "Bug Bounty: De profesión Cazarecompensas", y recientemente me ha venido a la cabeza al descubrir una utilidad desarrollada para obtener información sensible de cualquier equipo que se conecte a una determinada URL.

Figura 3: Libro de Bug Bounty: De profesión "Cazarrecompensas"

en 0xWord, escrito por Pablo García

Esta herramienta llama la atención por la facilidad de uso y la poca interacción que hace falta por parte de la víctima, ya que no requiere ningún tipo de instalación en el teléfono o en el ordenador personal de la víctima, solo que haga clic en un enlace. O que visite una URL en la que estén incluidas las funciones de esta utilidad, llamada "Storm-Breaker".

Storm-Breaker

Los fans de Marvel recordaréis este nombre por el arma que utiliza Thor en "Avengers: Endgame" y en "Avengers: Infinity War", y es que en ella se inspiraron los creadores de esta herramienta. Esta utilidad permite obtener de la víctima información muy sensible como su ubicación, capturas de la cámara, grabaciones del micrófono… sin necesidad de instalar nada en el dispositivo.

Figura 4: Storm-Breaker en GitHub

Storm-Breaker se puede encontrar gratuitamente en su directorio de GitHub, y su instalación es rápida y sencilla a través de los siguientes comandos:

$ git clone https://github.com/ultrasecurity/Storm-Breaker

$ cd Storm-Breaker

$ sudo bash linux-installer.sh

$ python3 -m pip install -r requirments.txt

$ sudo python3 Storm-Breaker.py

Tras ejecutar el programa, este generará una URL dinámica con Ngrok (*.ngrok.io) que apuntará al localhost del atacante y que una vez haya sido ejecutada generará un template con una web diseñada específicamente para cada tipo de información que el atacante desee obtener de la víctima, como por ejemplo:

- Localización de la víctima (URL de Google Maps con sus coordenadas) 

- Contraseña del Sistema Operativo (Windows 10) 

- Capturas de pantalla de la webcam o de la cámara del teléfono en tiempo real.

- Grabaciones en tiempo real del micrófono del dispositivo.

La víctima accederá a una web desde la que se le pide simplemente que haga clic en el enlace para continuar, y será entonces cuando el atacante reciba la información en su máquina.

Reflexiones

Como veis, no es necesario instalar un APK en un teléfono o un ejecutable en un ordenador para infectar un dispositivo y obtener información de él. Tampoco es necesario dominar Metasploit o Kali Linux - aunque si lo dominas, es un extra, cómo no, que Storm-Breaker funciona en Kali Linux - para utilizar herramientas como esta, que pueden ser igualmente peligrosas-

Figura 5: Demo de Storm-Breaker en Kali Linux

Los cibercriminales cuentan con una amplia gama de herramientas y que cada vez es más democrática en el mal sentido, ya que está dando acceso a un mayor número de atacantes de los que protegerse. Ante este panorama, merece la pena estar siempre atentos ante cualquier señal de sospecha y evolucionar igual de rápido que lo hacen las técnicas de phishing que cada día son más avanzadas y peligrosas.

Un saludo,

Autor: Pablo García Pérez

Contactar con Pablo García

Un pentesting usando OWASP Top Ten 2017: Sensitive Data Exposure, Security Misconfiguration & Code Injection

En los últimos exámenes de las convocatorias de las becas Talentum Startups de Telefónica, una de las preguntas que realizamos a los candidatos, para ver qué tipo de contacto o conocimientos tienen sobre seguridad informática, es qué prioridad tiene la exposición de datos sensibles frente a otro tipo de amenazas, todas ellas, recogidas en el informe Top Ten de la OWASP.

Figura 1: Un pentesting usando OWASP Top Ten 2017:
Sensitive Data Exposure, Security Misconfiguration & Code Injection

A veces nos encontramos con que las vulnerabilidades de inyección de código, situadas en las primeras partes de la lista son las más importantes, pero como se ve en el libro de Hacking Web Technologies, otro tipos de vulnerabilidades menores pueden ser el indicio para encontrar fallos que permitan llegar al corazón del sistema. En el informe OWASP TOP TEN 2017, la exposición de datos sensibles ocupa el sexto lugar.

Figura 2: Posición de "Sensitive Data Exposure" en el ranking OWASP Top Ten 2017

A priori, puede parecer que la exposición de datos sensibles puede tener poco peso específico en comparación con otro tipo de riesgos recogidos en el informe, pero, como veremos en el siguiente artículo, la exposición de datos sensible puede desvelar otros vectores de ataque por los cuales un atacante puede obtener información realmente crítica de una organización, simplemente haciendo correctamente la fase de footprinting de toda auditoría.

Transferencia de Zona

En un ethical hacking realizado dentro de un entorno donde se haga uso de un servicio de DNS a nivel interno de la organización, una de las cosas que siempre hay que mirar es si el servidor que soporta la resolución de nombres está bien configurado, por ejemplo, no permitiendo que el servidor primario de una zona revele nombres y direcciones IP de las máquinas que forman esa zona. Para ello, basta detectar la máquina que aparezca en el registro SOA y ésta sera quién tenga conocimiento de los nombres y direcciones IP de la zona.

Figura 3: Servidor primario DNS y dirección e-mail del administrador del dominio.

Una vez detectado el servidor de nombres que conoce la zona, el siguiente paso es hacer que sea nuestro servidor de nombres y realizarle la petición de transferencia de zona preguntándole por todas las máquinas que están bajo el nombre de dominio principal donde él se encuentra.

Figura 4: Petición de transferencia de zona del dominio objetivo

Si el servidor de nombres primario de la zona no está bien configurado, arrojará todos los hostnames y las direcciones IP de las máquinas que forman la zona que él controla, como sucede en este caso:

Figura 5: Extracto de la información de la zona devuelta por el DNS primario

Aunque, como recoge la OWASP Top Ten, no salgan a priori datos confidenciales, la transferencia de zona nos aporta una información más que interesante para probar otros vectores de ataque, como veremos a continuación y, por supuesto, es un fallo de seguridad que se debe evitar en la configuración de cualquier servidor DNS de una organización.

Inyección de código

Tal y como recoge el Top Ten de OWASP, en 2017 la vulnerabilidad con más criticidad en entornos web sigue siendo la inyección de código. La transferencia de zona anterior nos revela una web que puede que sea vulnerable a inyección de código SQL.

Figura 6: Sitio web posiblemente vulnerable a SQLi

Automatizando el ataque SQLi con la herramienta sqlmap que viene con Kali Linux 2, parece que hay un parámetro enviado por GET al servidor donde poder inyectar código SQL y JavaScript.

Figura 7: Posible parámetro GET vulnerable a SQLi y XSS

Al final, se comprueba cómo realmente es posible inyectar código SQL por el parámetro indicado, junto con los diferentes payloads que aprovechan la vulnerabilidad señalada para, en este caso, extraer información del motor de la base de datos.

Figura 8: Parámetro vulnerable a SQLi y payloads que pueden aprovechar el bug

Ejecutando el comando sqlmap -u http://157.xxxxxxx.xxxx.php?Curso=2009 -p Curso --tables -T Miembros –dump es posible obtener los datos confidenciales almacenados sobre los miembros de la organización, como su cuenta de correo electrónico y su contraseña sin cifrar, algo que en el OWASP TOP Ten del año 2007 estaba catalogado en puesto 8: Insecure Cryptographic Storage.

Figura 8: Información confidencial de algunos miembros de la organización

Conclusiones

Puede parecer que la exposición de datos sensible, dentro del ranking establecido por la OWASP TOP Ten 2017 tenga menos importancia que el resto de vulnerabilidades que la preceden, pero gracias a esta relevación de información, a veces es posible descubrir y explotar otras vulnerabilidades con más peso dentro del Top Ten.

Figura 9: Security Misconfiguration en OWASP Top Ten 2017

Además, aunque la OWASP no incluya de manera explícita dentro de la Exposición de Datos Sensibles la información a la que se puede acceder por culpa de un servidor de nombres mal configurado, puede arrojarnos pistas muy útiles a seguir en un test de intrusión y este fallo queda reflejado en el elemento 5: Security Misconfiguration.

Autor: Amador Aparicio de la Fuente (@amadapa)
Escritor del libro "Hacking Web Technologies"

Sé qué Torrents se han descargado desde tu empresa (o tu casa)

El otro día leí un artículo sobre el sitio I know what you download, una web que monitoriza los trackers de los Torrents que se distribuyen con la el protocolo BitTorrent. Estos trackers se utilizan para localizar y enlazar las fuentes en una descarga P2P con los clientes que desean descargarse los paquetes, y salvo que utilices un servidor Torrent privado, esta información es accesible por todo el mundo, lo que te puede generar un problema de privacidad, o algo más.

Figura 1: Sé qué Torrents que se han descargado desde tu empresa (o tu casa)

El funcionamiento de la web I know what you download es muy sencillo, basta con que introduzcas la dirección IP que quieras monitorizar y listo, te la información de todas las descargas de Torrents que se han podido descubrir.

Figura 2: Desde esta dirección IP se han descagado dos Torrents.
Se tiene la fecha y la hora exacta de la detección.

No están todas, ni mucho menos, pero tiene más de 400.000 Torrents y de cada uno de ellos las direcciones IP de los clientes que se han conectado a las fuentes para descargarse el contenido, con lo que es muy sencillo para cualquiera monitorizar tanto lo que pasa con una dirección IP como lo que pasa con un contenido.

Figura 3: Todas las direcciones IP monitorizadas en un Torrent concreto.
Una compañía podría usar esa información para ejercer acciones legales contra tu empresa.

No solo es un problema para la privacidad personal, sino que si alguien monitoriza las direcciones utilizadas por una empresa, puede llegar a saber mucho de los empleados, además de poder meterle en un problema a la compañía.

Figura 4: Por cada dirección IP está la lista de contenidos detectados.
Si es la puerta de salida a Internet de tu empresa puede ser un problema.

Además, alguien podría saber si tú o un empleado de tu empresa está haciendo descargas y cuáles simplemente consiguiente la dirección IP por medio de un enlace en un correo electrónico al que se hiciera clic. Este es un servicio que ellos mismos proporcionan desde su web.

Figura 5: Para generar un e-mail de tracking

Si eres administrador de una empresa u organización que cuenta con direcciones IP fijas es fácil que pruebes a ver cuál es el informe de resultados que obtienes y lo monitorices de manera regular, porque puedes llegar a descubrir malos hábitos de trabajo, malas prácticas de seguridad, uso inadecuado de la red de trabajo o incluso que puedes estar expuesto a un problema mayor.

Saludos Malignos!

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"

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 7ª edición de RootedCON Madrid, en la 3ª edición de la RootedCON Valencia y en la 6ª 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 escaning, escaneo 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"

La higiene en los mensajes de error de la web. Un ejemplo con Microsoft.com

A lo largo de los últimos años he hablado mucho de los mensajes de error en las aplicaciones web. Mucho y de muchas formas distintas, así que si quieres pasar un buen rato leyendo, hazte algunas búsquedas sobre los posts de los últimos diez años que seguro que te salen muchos resultados. Los mensajes de error son fabulosos en la fase de footprinting y fingerprinting de una auditoría de seguridad, y te pueden llevar a descubrir pequeños bugs en los sitios adecuados para conseguir encontrar el camino directo al gran bug, por eso yo suelo pedir a mis compañeros que sean muy cuidadosos con ellos.

Figura 1: La higiene en los mensajes de error. Un ejemplo con Microsoft.com

En el evento de ayer, en la Dot Net Conference, - donde he de reconocer que me lo pasé como un niño pequeño con tanto amigo y gente buena - utilicé como primera parte de la charla sobre "Some dirty, quick and well-known tricks to hack your bad .NET WebApps" una referencia y una demo a la importancia de la higiene con los mensajes de error. Aquí tenéis las diapos de la charla.

Figura 2: Some dirty, quick and well-known tricks to hack your bad .NET WebApps

La primera de las demos la hice con la web de Microsoft.com, en la que, dependiendo de cómo fuerces los errores obtienes resultados diferentes. Estos son los ejemplos.

Figura 3: Error con redirección tras pedir https://www.microsoft.com/foca.aspx

Figura 4: Error controlado y consistente con el error controlado. Sin redirección

Figura 5: Error generado por el Engine de PHP. Totalmente inconsistente.

Figura 5: Error generado por Request Filtering

Figura 6: Error no controlado del framework .NET al detectar un ataque de HTML Injection

Figura 7: Error generado por el WAF. En este caso por el WAF de Akamai que gestiona la CDN

Como podéis ver, seis mensajes de error distintos para el mismo dominio. La culpa es porque hay muchos elementos que pueden interceptar la petición de error y dar la respuesta ante cada situación. Una buena política higiénica debería devolver siempre los mismos mensajes.

Figura 8: Momentos durante mi charla de ayer }:)

Aprovecho para mandar un saludo, un fuerte abrazo y un beso a tod@s los que os acercasteis a mí para saludarme, pedirme una foto o charlar un rato dentro del evento. Hicisteis que me volviera a sentir como esperaba sentirme cuando regresé de mis vacaciones. Si no te saludé, deberías haberte acercado a decir "hola", que seguro que me hubiera encantado hacerlo.

Saludos Malignos!

Cómo forzar Errores HTTP 405 en servidores web

Como ya os he contado muchas veces, llevo tiempo jugando con cómo sacar el máximo de información a los mensajes de error configurados por defecto en los servidores web de una organización. Esta es una pieza que utilizamos en nuestro sistema de pentesting persistente Faast para localizar qué infraestructura hay por detrás. Encontrar respuestas a situaciones de error no controladas por los administradores de un sitio web pueden ayudar a conocer mucho más en detalle el software que da soporte al servicio y cómo está montado en esa implantación en concreto.

Figura 1: Cómo forzar Errores HTTP 405 en servidores web

En esta ocasión pasé un rato jugando con los Errores HTTP 405, que básicamente se producen cuando se solicita la ejecución de un método HTTP que no está soportado por el recurso que se solicita. Para ello, utilizando el Repeater de Burp puedes configurar algo tan sencillo como un POST a un recurso que no tenga habilitado el método en concreto. Para saber los métodos que están permitidos en cada recurso puedes utilizar el método OPTIONS y descubrir qué se permite y qué no se permite.

Figura 2: Mensaje de Error 405 en Google.com

Jugando con esto, es decir, con hacer un POST a recursos que no lo tenían habilitado se pueden obtener los mensajes configurados para el Error 405, que muchas veces serán los de por defecto, como el de IIS en este servidor de un dominio .mil.

Figura 3: Error 405 por defecto de IIS 7

En algunas otras webs puedes ver páginas de configuración de error por defecto de los servicios de Akamai, de nginx o de cualquier otro servidor de aplicaciones. En este caso la hacer el POST se obtuvo un mensaje de error por defecto del servidor HTTP de IBM.

Figura 4: Error en un servidor HTTP de IBM

Los mensajes de error pueden cambiar e incluso puede que aparezcan mensajes reutilizados de otros errores que habría que interpretar para ver qué significan realmente.

Figura 5: Un mensaje de error personalizado

En este último caso que os traigo, un dominio perfectamente configurado en todos los mensajes de error, cuando se producía un Error 405 devolvía la página de Welcome a IIS7, pero sin cargar el famoso logotipo, lo que deja claro que algo estaba raro.

Figura 6: Un mensaje de Welcome al forzar un Error 405

Al final, generar los mensajes de error para obtener información no es más que una prueba que en las fases de footprinting y fingerprinting debes realizar sí o sí, para ver qué datos eres capaz de recolectar de la infraestructura a la hora de hacer un pentesting. Fácil, barato e ilustrativo.

Saludos Malignos! 

Atacar un sitio web usando sus estadísticas: Pentesting, Hacking & doxing

Cuando se está analizando la seguridad de una aplicación web en un proceso de pentesting, las fugas de información son muy útiles y pueden llegar a abrir la puerta de par en par. Desde un simple directory listing, pasando por los múltiples juicy files que te puedas encontrar - .DS_Store, thumbs.db, .svn/entries, etcétera, etcétera - hasta llegar a los paneles de monitorización o administración "ocultos" por unos robots.txt muy "verbose".

Figura 1: Atacar un sitio web usando sus estadísticas

La gestión de las estadísticas de tráfico puede convertirse también en una fuga de información jugosa que utilizar a la hora de hacer crawling de URLs ocultas, de descubrir el direccionamiento interno de la red una organización, a la hora de hacer un ataque de watering hole esperando la conexión de un determinado cliente o simplemente como fase de recogida de información útil para ataques dirigidos. Pero puede dar más juego.

1.- Estadísticas como servicio: Contenido externo, Watering Hole y Doxing

Hoy en día muchos sitios web tienden a utilizar servicios en cloud para gestionar sus estadísticas. Para ello, en cada web se hace una carga de un contenido externo en forma de fichero JavaScript que va recapitulando todos los datos de navegación. Después el dueño de la web visita un panel de control en el servicio de estadísticas y revisa el tráfico de su sitio.

Figura 2: Esquema de ataque a visitantes de RSA Conference vía servidor de estadísticas

Cuando se tiene este esquema al final, la seguridad del sitio web está delegada a un tercero, por lo que como se vio en el caso de la RSA Conference, atacar el servicio de estadísticas podría llegar a ser más sencillo que atacar la web oficial. 

No solo se pueden utilizar las estadísticas para atacar a los visitantes del sitio como en el caso de la RSA Conference, sino que podrían utilizarse los paneles de administración de estadísticas para atacar a los administradores del sitio web, por medio de ataques CSRF, Tabnabbing, XSS o ClickJacking. Por ejemplo yo me topé con que el panel público del contador de visitas que usa El lado del mal es vulnerable a ataques XSS, y además por defecto es público, así que se puede atacar a curiosos con él.

Figura 3: XSS en Bravenet

En el caso del famoso Google Analytics, muy utilizado para hacer el seguimiento de estadísticas en muchos sitios web, el identificador que se usa para recoger los datos permite saber cuántos sitios están controlados por la misma persona, lo que ayudaría a saber quién está posiblemente detrás de un blog si gestiona las estadísticas con el mismo ID.

Figura 4: IDs de Google Analytics

Esto es sencillo ya que si una misma persona quisiera tener más de un sitio web dentro del mismo panel de control de Google Analytics, el código que genera el servicio es igual, pero con un valor consecutivo tras el guión. Es decir -2, -3, -4 y subsiguientes, lo que ayudaría a hacer doxing de bloggers.

2.- Estadísticas como módulo parseador de logs

En muchos sitios aún se pueden ver las estadísticas de una web como un módulo que parsea logs. Lejos del concepto de aplicación en sí mismo, se usan programas que filtran los logs y los muestran de forma gráfica. Estos módulos de parseo de log carecen de una estructura completa de aplicación con gestión de usuarios y similares, por lo que la seguridad del acceso a ellos está restringida a la configuración que haga el administrador en el servidor web.

Figura 5: Awstats. Datos de clientes con conexiones IPv6 incluso

Clásicos que se pueden encontrar son Awstats, fácil de localizar filtrado en ficheros robots.txt, que muestra información detallada de clientes, partes de la web y datos transmitidos. De siempre, este fichero ha sido un jugoso aliado a la hora de hacer una fase de footprinting/fingerprinting en un proceso de pentesting.

Figura 6: Clientes mostrados con WebAlyzer

Por supuesto, Webalyzer es otro clásico a localizar, que también suele estar publicado en las webs bajo rutas como /stats/, /webalyzer/, /mystats/ o /sitestats/, y donde se puede sacar un poco de todo para analizar una web.

Figura 7: Datos de tráfico con WebAlyzer

Algún dato tan curioso como la web que más datos transmite en una petición GET, lo que puede ayudar a alguien que quiera planear un ataque DDOS a saber cuál es la parte de la web que hace enviar más datos desde ese servidor, por si alguien quiere enlazarlo con una amplificación.

Figura 8: Wusage aún se usa en muchas webs

El último de los que quería hablar en esta categoría es Wusage, un parseador de estadísticas muy antiguo, pero que todavía está disponible en muchas webs, y que buscando en robots.txt se encuentra abierto para todo el mundo.

3.-Estadísticas como aplicación web

La última de las partes que quería citar en este artículo, es cuando en lugar de utilizar un parseador como los citados anteriormente se utiliza una aplicación web completa. Esto quiere decir que dentro del servidor se mete un software con su base de datos, su gestión de usuarios, su código server-side, etcétera.

Figura 9: Trace Watch se publica en /twatch/. Arquitectura LAMP.

Para esta categoría hay muchas, desde módulos de frameworks de Internet hasta aplicaciones más o menos maduras. En ellas hay que tener mucho cuidado con la gestión de la seguridad, ya que hay nuevas identidades que proteger que dan acceso a un motor de bases de datos que podría ser utilizado por un atacante. Un ejemplo de esto es el exploit de Time-Based Blind SQL Injection para Solar Empire usando el campo de User-Agent en las estadísticas de los visitantes.

Figura 10: Piwik, otro ejemplo de aplicación para estadísticas

Algunos de estas implantaciones adolecen de problemas habituales como contraseñas por defecto, no protección contra ataques de fuerza bruta o software no actualizado con bugs conocidos. Mucho cuidado si haces uso de alguno de ellos.

Saludos Malignos!