Cómo gestionar el "Autonomous Continuous Attack" con Agentes IA en Offensive Security

Hoy os voy a contar lo que en FardaySec aprendimos construyendo un Pentester Autónomo basado en Inteligencia Artificial para hacer Continuos Attack a las empresas como parte de la gestión de la seguridad en el mundo de hoy. La confianza en el Pentesting Autónomo no se resuelve con un modelo más grande — se resuelve con evidencia, trazabilidad y gobernanza. Por eso el futuro no es Inteligencia Artificial reemplazando al pentester, o hacker, sino teniendo al hacker + Agente IA trabajando juntos.

Figura 1: Cómo gestionar el "Autonomous Continuous Attack"

con Agentes IA en Offensive Security

Hace aproximadamente un año y medio empezamos en Faraday con una pregunta bastante simple:

¿Hasta dónde podemos automatizar realmente el trabajo de un pentester utilizando Inteligencia Artificial?

No queríamos construir otro scanner. Tampoco un chatbot capaz de explicar vulnerabilidades. Queríamos darle a un agente un objetivo, herramientas ofensivas reales y suficiente autonomía para investigar, tomar decisiones y producir evidencias. Después de 157 engagements autónomos, más de 117.000 vulnerabilidades procesadas y más de 250 horas de testing, aprendimos algo que inicialmente no era tan evidente:

Encontrar vulnerabilidades no terminó siendo el problema más difícil.

El problema difícil fue decidir cuándo podíamos confiar en lo que el agente decía haber encontrado. Esta es probablemente la principal lección que nos dejó construir FaradAI.

Un LLM no es un pentester

Al principio parece tentador pensar que conectar un modelo con herramientas ofensivas alcanza. Pero un LLM normalmente produce algo parecido a:

Prompt → Modelo → Respuesta plausible

Un pentest necesita otra cosa:

Objetivo → Decisión → Ejecución → Evidencia → Hecho verificable

La diferencia está principalmente en esas últimas palabras: hecho verificable. En FaradAI cada ronda comienza con un objetivo. El agente analiza el contexto, decide una acción, utiliza herramientas a través de MCP, ejecuta y captura los resultados. Después ocurre la parte más importante:

la evidencia obtenida modifica el plan de la siguiente ronda.

Podemos simplificarlo así:

Figura 2: LLM genérico vs. loop de FaradAI

Las herramientas tampoco son particularmente novedosas. Nmap. Burp. Metasploit. Scripts propios. Las mismas herramientas que utiliza un pentester. Lo que cambia es quién decide cuál utilizar, cuándo utilizarla y qué hacer después con el resultado. Una herramienta empieza a operar herramientas.

Cuando volver a intentar se vuelve barato

Uno de los cambios que más nos llamó la atención fue el económico. En un engagement completo de web + red ejecutamos:

Figura 3: Datos del engagement en formato terminal

En todo el programa acumulamos más de 250 horas de testing autónomo por unos pocos miles de dólares de infraestructura y modelos. No significa que una hora de IA sea equivalente a una hora de un pentester humano. Claramente no lo es. Pero cambia otra variable mucho más importante: el costo de volver a intentarlo. 

Cuando probar nuevamente cuesta poco, podemos ejecutar continuamente. Y cuando podemos ejecutar continuamente, empezamos a enfrentarnos con otro problema:

¿Quién decide cuándo dejar de intentar?

El Agente IA que no sabía rendirse

En uno de nuestros engagements vimos al agente ejecutar un escaneo. No encontró nada nuevo. Cinco minutos después volvió a ejecutar prácticamente la misma técnica. Mismo resultado. Después otra variación. Y otra. Hasta que finalmente apareció:

Time limit reached

El Agente IA había pasado varios minutos insistiendo sobre un camino que no estaba generando ninguna señal nueva. Un pentester probablemente habría abandonado antes. El Agente IA no decidió detenerse. Lo detuvo la plataforma. Puede parecer un detalle de implementación, pero para nosotros fue una de las primeras señales de algo mucho más importante:

La autonomía no consiste en darle libertad ilimitada a un modelo. 

Consiste en construir límites alrededor de esa autonomía. Tiempo. Presupuesto. Scope. Cantidad de rondas. Herramientas permitidas. Acciones permitidas. El modelo puede razonar. Pero la plataforma tiene que gobernarlo.

El contexto es la mitad del producto

Otro aprendizaje importante apareció cuando empezamos a darle más información al Agente IA. El mismo Agente IA con diferente contexto parece otro Agente IA totalmente distinto. Si sólo conoce un target, explora en abanico. Prueba. Repite. Consume presupuesto. Pero si además conoce inventario, tecnología, findings anteriores, criticidad y contexto del activo, cambia completamente su comportamiento. Eso nos hizo revisar una pregunta bastante común cuando hablamos de Agentes de IA:

¿Qué modelo utilizan?

Después de nuestra experiencia, probablemente haya otra pregunta igual o más importante:

¿Qué contexto tiene disponible ese modelo?

Porque una Agente IA puede identificar correctamente dos vulnerabilidades, pero no necesariamente sabe que una afecta un microsite de marketing y la otra el sistema de facturación de la compañía. La vulnerabilidad está en la tecnología. La criticidad está en el negocio. Y ese contexto todavía necesita venir de algún lado.

Donde la IA nos sorprendió

Durante el desarrollo terminamos trabajando con dos tipos de Agentes IA muy diferentes. Uno intenta comportarse como un pentester: explora, prueba, encadena y eventualmente explota. El otro realiza triage sobre findings generados por scanners. Llegamos a un loop de validación con harnesses, y el resultado fue inesperado.

Figura 4: The Autonomous Attacker

Nuestro Agente IA de pentesting "The autonomous attacker" trabajó sobre unas mil vulnerabilidades durante cientos de horas. El Agente IA de triage procesó más de 116.000 vulnerabilidades en unas diez horas.

Figura 5: El Agente IA de Triage

Y probablemente ahí encontramos uno de los casos de uso más interesantes. No es el más cinematográfico. No hay shells. No hay exploits. No hay una demo espectacular. Pero permite analizar enormes cantidades de información, correlacionar resultados y reducir ruido antes de que llegue a un equipo humano.

Figura 6: Estadísticas finales con costes en FaradAI

Curiosamente, ahí vimos uno de los mejores retornos y uno de los menores riesgos. Quizás antes de darle autonomía completa a un Agente IA para atacar, exista muchísimo valor en dejarla trabajar sobre toda la información que nuestras herramientas de seguridad ya generan.

Las cuatro formas en que el Agente IA nos hizo perder tiempo

Después de cientos de rondas también empezamos a reconocer patrones de error.

1. Loops repetitivos: Repetir prácticamente la misma acción esperando obtener un resultado diferente.

2. Sintaxis inventada: Utilizar parámetros o flags que la herramienta no tiene, acompañados muchas veces por una explicación perfectamente razonable de por qué deberían existir.

 

3. Herramienta equivocada: Seleccionar una técnica que no corresponde con el objetivo que el propio agente había definido.

4. Presupuesto: Consumir buena parte de las rondas investigando una rama que dejó de generar señales útiles mucho antes.

Todos esos problemas hubo que ir resolviéndolos con Grapth Engineering, con MCPs claros que simplificaban la llamada a las herramientas, con Skills guiadas en procesos conocidos, y con routing adecuados de Prompts a modelos. Un trabajo de ingeniería fina. Pero hubo un problema todavía más importante.

Un finding falso puede parecer exactamente igual que uno verdadero

Este probablemente sea el punto más delicado. Un hallazgo inventado por un modelo puede tener: la misma estructura, el mismo tono, una severidad perfectamente razonable, una descripción convincente, y una recomendación correcta. Leyéndolos, pueden parecer exactamente iguales. 

Figura 7: Gestión de múltiples scans y findings en FaradAI

Durante el desarrollo revisamos informes muy buenos. Y falsos. Después de probar distintas aproximaciones llegamos a una regla bastante simple:

Figura 8: Mismo reporte, distinta evidencia

No es sufiente  con que el modelo diga que encontró una vulnerabilidad. Necesitamos saber: qué ejecutó, contra qué, qué respuesta recibió, cuándo ocurrió, y si otro investigador puede reproducirlo. Y ahí aparece, para nosotros, el verdadero desafío del Pentesting Autónomo.

The Autonomous Pentesting Trust Gap

Internamente empezamos a llamar a este problema: The Autonomous Pentesting Trust Gap. Hay dos capacidades que están creciendo a velocidades diferentes. Por un lado: lo que un Agente IA puede encontrar. Por otro: lo que puede demostrar de aquello que encontró. La primera está avanzando muy rápido. La segunda es bastante más difícil.

Y la distancia entre ambas probablemente determine cuánto podemos confiar realmente en los sistemas autónomos de Offensive Security. No creemos que esto se solucione simplemente utilizando un modelo más grande. Es principalmente un problema de plataforma, evidencia y gobernanza. Después de este año y medio terminamos reduciendo la confianza a cinco condiciones, que deben servir como Harness para cada finding.

Figura 9: Las cinco condiciones de confianza

Si falta alguna de estas piezas, corremos el riesgo de confundir un Pentester Autónomo con algo bastante diferente:

Un generador de respuestas plausibles conectado a herramientas ofensivas.

¿Entonces la IA puede reemplazar a un pentester?

Después de todo este trabajo, creo que esta pregunta empieza a perder sentido. Los Agentes IA ya pueden hacer cosas que antes necesitaban muchas horas de trabajo humano. Explorar. Ejecutar herramientas. Analizar resultados. Hacer triage. Repetir pruebas. Trabajar en paralelo. Pero seguimos viendo una diferencia importante cuando el problema deja de ser ejecutar una técnica y pasa a ser entender qué significa lo que encontramos.

• ¿Este activo realmente importa?
• ¿Vale la pena continuar este camino?
• ¿Para qué podría servir este acceso?
• ¿Existe una cadena mejor?
• ¿Cuál sería el impacto real para esta compañía?

Eso requiere contexto. Hipótesis. Creatividad. Y criterio. 

Por eso el modelo que más nos interesa hoy no es: AI → Pentest 

Sino: Hacker + AI Agent → Pentest

Figura 10: Historial de Engagements y Rounds del Agente IA en FaradAI

El Agente IA aporta escala y velocidad. El Hacker o Pentester aporta contexto, creatividad y criterio.

Lo que viene

Todavía estamos aprendiendo. FaradAI hoy es tanto un producto como un experimento permanente sobre cómo debería funcionar la próxima generación de Offensive Security. Aquí tienes una demo de cómo funciona nuestro sistema, y si quieres, contacta con nosotros para probarlo.

  

Figura 11: Demo de funcionamiento de FaradAI

çPero después de más de un año construyéndose hay algo de lo que estamos bastante convencidos: 

La IA ya puede encontrar vulnerabilidades.

Todavía necesitamos hackers para comprenderlas.

Quizás el futuro del pentesting no sea elegir entre humanos y máquinas. Quizás sea construir algo bastante más interesante:

Hackers humanos trabajando junto a Agentes IA de hackers.

Y cuando esa combinación pueda operar continuamente sobre toda una superficie de ataque, probablemente dejemos de preguntarnos cuándo fue nuestro último pentest. La pregunta será otra:

¿Qué está intentando comprometer nuestro Agente IA hacker ahora mismo?

Si quieres probar nuestro FaradAI, no dudes en ponerte en contacto con nosotros, o directamente conmigo, y hacemos una prueba de cómo funciona el Autonomous Continuous Attack con Agentes IA.

Autor: Martín Tartarelli, CEO — Faraday Security

Contactar con Martín Tartarelli

Faast: El servicio de Pentesting Persistente y el Reporte Responsable a Apple

Han pasado más de seis años desde que comenzamos a hablar de Pentesting Persistente, Pentesting Continuo, Pentesting By Design, en un momento en el que nadie hablaba de él, y donde muchas veces nos decían que era imposible. Hoy en día es una práctica muy común. Para implementar nuestra visión, nosotros cogimos el core de nuestra querida FOCA, lo transformamos en un entorno Cloud-Native, y creamos el Servicio de Pentesting Persistente Faast en ElevenPaths, del que hemos hablado muchas veces.

Figura 1: Faast: El servicio de Pentesting Persistente y el Reporte Responsable a Apple

Lejos de parar con esta visión, Faast no ha hecho más que crecer, mejorando los procesos e integraciones para ampliar la búsqueda de nuevos recursos, y optimizando los algoritmos de detección de vulnerabilidades y fallos de configuración.

Figura 2: Faast de ElevenPaths

Y aunque la idea fuese concebida en el año 2013, la evolución de la industria no ha hecho más que reforzar este planteamiento, donde los entornos mutan cada vez más rápido gracias al mayor uso de nubes, y al auge de tecnologías basadas en contenedores, cuales facilitan la puesta en producción de nuevos activos. A día de hoy muchas de las soluciones de detección de vulnerabilidades ofrecen este tipo de Pentesting Persistente, por los buenos resultaos que dan.


Figura 3: OWASP 2013 "¿Por qué los cibercriminales siempre ganan?" por Chema Alonso
Esto nos ha permitido reportar a las grandes tecnológicas diferentes vulnerabilidades que hemos encontrado analizando sus activos, como se puede ver en los agradecimientos de Microsoft y los reconocimientos de Apple, entre otras grandes empresas. Esto no es nuevo, ya antes se los daban a nuestra querida FOCA.

Figura 4: Agradecimientos de Apple a Faast Team en ElevenPaths

Pero ¿qué podemos encontrar en un análisis a una de las gandes como Apple? Lo lógico sería pensar que no encontraremos ningún problema ya que estas compañías invierten muchísimos recursos en mantener sus sistemas seguros. Pero se demuestra año tras año, la seguridad 100% no existe. En un scan rápido de Faast a la web WWW de Apple, podemos observar varias cosas que llaman la atención, algo que ya hemos visto muchas veces en el el pasado. Antes os dejamos los artículos del pasado:

- Think Different: Un Hostname sin Domain en los inversores de Apple
- Los certificados digitales que usa Apple en su CDN son de peor calidad
- Algunos backups de Apple son de una extensión "original"
- Una mirada "faast" a Apple buscando al caniche
- Un repaso al pentesting persistente tres años después en ElevenPaths
- Análisis de un HPP (HTTP Parameter Pollution) en Apple
- Apple atacada por la viagra en los servidores de iTunes
- Un HTTP Redirect no te libra de securizar un servidor web
- IIS Short Name Bug en los servidores de apple.com
- La FOCA se merece un iPad
- Un .SVN/Entries en Apple.com descubierto por la FOCA
- Apple se olvida de unas webs del siglo XX en sus servidores

En una reciente revisión, hemos visto aún muchas de las cosas que adolecía en el pasado, como podéis ver en este listado. Y ahora vamos con el presente

• Software desactualizado: en este caso un apache que en esa versión concreta dispone de ciertas debilidades, incluso detectadas este mismo año como se puede apreciar en los CVE asociados.

Figura 5: Versiones de Apache desactualizadas con CVEs

• Cabecera ‘Cross Origin’ demasiado permisiva: No es buena práctica aplicar wildcard (*) a este tipo de elementos, mejor mantener un listado de dominios permitidos.

Figura 6: Cabecera Cross Origin configurada con *

• Fichero dwsync.xml: clásico fichero que genera la aplicación Dreamweaver y no debería incluirse en un despliegue de la web. Nos puede proporcionar rutas o nombres de fichero que no deberían estar ahí.

Figura 7: Fichero DWSync.xml

• Target _blank phishing: en las etiquetas HTML <a> con el atributo target=’_blank’ no se está incluyendo la propiedad rel=’noopener’ (o noreferrer), la cual ya se comentó en este artículo que escribo Chema Alonso.

Figura 8: URLs con enlaces si rel='noopener'

• Metadatos: Una gran cantidad de metadatos, que revelan usuarios. Algunos de estos trabajadores son internos, y otros de compañías que prestan servicio a Apple. Además de diferente software con el que se crean estos documentos, que van desde las aplicaciones ofimáticas clásicas, a versiones concretas de librerías para la conversión de documentos a formato PDF.

Figura 9: Metadatos, Metadatos, Metadatos. Lista de usuarios.

• Cross-site scripting (XSS): Una vulnerabilidad de las más clásicas en entornos web. Se encuentra en el Top 10 de OWASP desde hace muchos años, y permite a cualquier visitante del sitio web ejecutar código Javascript inyectando en la propia URL del sitio web, o en alguno de sus campos de formularios.

Figura 10: XSS Reportado, corregido y agradecido por Apple (Figura 4)

Como es costumbre hemos vuelto a hacer una ‘Revelación Responsable’ de estos problemas, algunos considerados vulnerabilidades, y otros como relajación de la configuración. Apple lo ha recibido de buen grado y nos ha agradecido la colaboración para mantener sus servicios más seguros.

Figura 11: Client-Side Attacks: XSS, CSSP, SSRF, XSPA, SSJS

Por ahora tiene varias vulnerabilidades que está pendiente de corregir, así que os contaremos más de ellas cuando las hayan corregido. Os recomiendo el libro de Client-Side Attacks de Enrique Rando, que explica bien cómo descubrir y explotar estas vulnerabilidades.

Autor: Ioseba Palop, Senior Software Architect Faast team (Contactar con Ioseba Palop)

Cómo encontramos tu HTTP Response Splitting olvidado

Las vulnerabilidades de HTTP Response Splitting pueden ser utilizadas para hacer muchos ataques peligrosos. De hecho, están catalogadas con un nivel de criticidad alto y cuando aparecen se deben cerrar lo antes posible. La idea de una vulnerabilidad de HTTP Response Splitting es que un atacante es capaz de inyectar código en la cabecera de la respuesta HTTP y por tanto reescribir toda la página que llega al cliente. Esto se produce cuando se puede inyectar en un campo que va uno de los campos de la cabecera y el atacante decide escribir, en su inyección, campos HTTP para cambiar la respuesta por completo.

Figura 1: Cómo encontramos tu HTTP Response Splitting olvidado

Nosotros nos encontramos con uno de ellos hace poco utilizando nuestro sistema de Pentesting Persistente Faast con el que monitorizamos la seguridad de las webs haciendo pentesting 365 días al año de manera continua, y aplicando un algoritmo voraz, es decir probando todo lo que haya que probar en cada punto. La gracia en el artículo de hoy no está en la vulnerabilidad en sí, sino en cómo el sistema recursivo funcionó para localizar el bug, que ya está corregido, así que os lo cuento rápidamente hoy sábado.

Figura 2: Bug de HTTP Response Splitting detectado por Faast en un proyecto

El comienzo fue bastante sencillo. Como en cualquier proceso de Ethical Hacking, el motor de Faast tiene una fase de Discovery en la que busca en todos los lugares posibles los recursos expuestos en Internet. Por supuesto, también haciendo hacking con buscadores. En una de esas búsquedas apareció una URL que, como tantas otras, y al igual que se hace con FOCA, pasa a ser analizada por el motor de Faast.

Figura 3: Descubrimiento de una URL indexada y extracción de URLs para Spidering

El código HTML de la página de respuesta de esa URL se pasa por una serie de plugins, y uno de ellos lo que hace es, por supuesto, buscar nuevas URLs a partir de enlaces en la página. Esto es una tarea básica en cualquier pentesting. Hacer spidering a partir de una URL, tal y como se explica en el libro de Hacking Web Technologies. Nosotros, antaño, lo hacíamos con Burp y luego lo pasábamos a FOCA.

Figura 4: Proceso de Spidering con Burp

De esa URL sacamos más URLs con directorios y recursos enlazados. Y, por supuesto, cada directorio que es descubierto se pasa por una serie de plugins de forma recursiva. En búsqueda de cosas como fallos de Directory Listing, de IIS Shortname, Múltiple Choices, errores no controlados, etcétera.

Figura 5: Descubrimiento de un DWSync.xml

Una buena batería, donde también se buscan los sensitive files, tipo .DS_Store, WS_FTP.log o ficheros .listing, por poner algún ejemplo. En este caso, lo que apareció fue un DWSync.xml de los que se quedan cuando alguien sube una web usando Dreamweaver, como ya hemos hablado muchas veces.

Figura 5: Descubrimiento del fichero CGI olvidado por medio de Spidering

Esto es un leak en sí mismo, y como tal quedó reportado en el proyecto para los responsables de seguridad, pero de él sacamos nuevas URLs, como la que se puede ver en la captura del mismo.

Conclusiones

Al final, ese CGI (Common Gateway Interface) resultó ser vulnerable a HTTP Response Splitting. Un fichero que hacía mucho tiempo que se había quedado sin utilidad en la web, pero que aún estaba presente en el servidor. No lo habían limpiado, y el motor de Faast, buscando de manera persistente dio al final con él. 

Figura 6: Encadenamiento recursivo de plugins en Faast hasta llegar al HTTP Response Splitting

Si quitas algo de la web, quítalo. Este es uno de los errores más comunes que encontramos en los proyectos de pentesting persistente - como los que os dejé de Apple - y a partir de ellos se pueden localizar muchas cosas peligrosas. En este caso, un HTTP Response Splitting. Si quieres, puedes pedirnos un piloto de Faast sin compromiso para tu empresa a través de nuestra web de contacto de ElevenPaths.

Saludos Malignos!

Un repaso al "Pentesting Persistente" 3 años después en @elevenpaths #pentesting #faast

Han pasado poco más de tres años desde que comenzamos a trabajar en una idea que yo tenía en la cabeza: Hacer que el Pentesting no fuera un proyecto que se ejecuta cada año, sino algo que se ejecuta de forma continua y que se contempla desde la fase de diseño. Es decir, que desde el minuto 1 que un servicio está en producción, y hasta el último de los días en que el servicio está funcionando, está siendo sometido a un escrutinio de seguridad con la visión de un pentester. Es lo que llamamos el Pentesting Persistente.

Figura 1: Un repaso a la visión de "Pentesting Persistente"

En aquel entonces, cuando comenzamos a trabajar en ello, tuvimos la suerte de que las tecnologías de BigData, el Cloud Computing y las herramientas para procesar OSINT estaban ya en una fase madura, así que comenzamos a trabajar en cómo pasar el funcionamiento inicial de FOCA (origen de esta idea de automatizar al máximo todas las tareas de un pentester) a un entorno en modo servicio que fuera capaz de hacer Pentesting Persistente a todos los activos expuestos a Internet de una organización, y lo llamamos Faast. 

Figura 2: Detección de vulnerabilidades como un proceso continuo

El nombre de este motor de penstesting que corre en la nube es un juego de palabras entre Fast (veloz) y lo que para nosotros era "FOCA as a Service by Telefónica". Las principales características de esta visión, y lo que lo hace diferente al resto, son las siguientes:

1. Algoritmo Voraz

La idea era la misma con la que se concibió FOCA:

Por cada activo descubierto hacer todas las pruebas posibles que un pentester realizaría para saber si hay un solo bug o debilidad que deba ser analiza o reportada. 

Esta visión comienza por el activo inicial con el que auditamos una organización: El nombre de dominio principal. Desde ahí, hay una serie de tareas de "Discovery" para descubrir la infraestructura expuesta a Internet de la organización. Y metemos todos los plugins de descubrimiento que como pentesters se nos ocurrirían.


Desde "machacar los DNS" con todo tipo de pruebas, hasta buscar todas las referencias en los buscadores, pasando por los leaks de información que haya en los certificados digitales, en las bases de archive.org, haciendo escaneos de todo tipo en los rangos de direcciones, buscando referencias en bases de datos de terceros, referencias en aplicaciones móviles, etcétera. Cada vez que se publica una nueva forma de buscar posibles referencias a activos de una organización, lo implementamos como un plugin de Discovery.

Así, cuando se da de alta un nuevo proceso de Pentesting Persistente para un dominio, se lanzan las primeras tareas de Discovery, generándose decenas de procesos que devolverán activos en forma de servidores.

Figura 3: Algunos plugins de las tareas de Discovery

La gracia del proceso de Pentesting Persistente es que por cada nuevo activo se repite el proceso de lanzar aboslutamente todas las tareas de auditoría que nosotros vamos definiendo. Y cuando digo todas, es que son todas las que forman la base de conocimiento de estos años y que vamos ampliando día a día con nuevos plugins. Así, cuando se descubre un servidor hacemos lo que haría cualquier pentester, es decir, buscar cualquier referencia al mismo en cualquier fuente OSINT de Internet (footprinting), escanear todos los servicios que están asociados a él (fingerprinting), descubrir todas las posibles vulnerabilidades que tengan esos servicios (exploiting). Por cada servidor se lanzan tareas de forma recursiva para saber qué servicios tiene.

Figura 4: Algunos plugins de las tareas de Analysis

Por cada servicio descubierto se lanzan sus tareas de seguridad también. Es decir, si un servidor tiene abierto un puerto LDAP, se lanzan todos los plugins de seguridad LDAP como por ejemplo sacar al versión del software y miramos los CVE asociados, los algoritmos de autenticación que soporta mirando la negociación con RootDSE para ver si alguno es débil, miramos si permite el acceso anónimo para extraer información, lanzamos la búsqueda de paneles de administración tipo phpLDAPAdmin, etcétera...

Esto será diferente si lo que se encuentra es un servidor web, donde lo que habrá que lanzar son tareas totalmente distintas para localizar URLs presentes y pasadas,  lanzar procesos para listar todos los posibles archivos del servidor web, hacer fuzzing, buscar leaks en ficheros de todo tipo que van desde .DS_Store, hasta Thumbs.db, pasando por los leaks de cualquier framework de Internet como Magento, phpMyAdmin, Moodle o Drupal.

Y por cada URL, que también es un activo, se generan todas las tareas de forma recursiva que habría que realizar. Buscar todos los leaks de información, sacar los parámetros buscar los bugs de SQL Injection, XSS, SSRF, HPP, etc... buscar los backups, buscar directorios en todas las rutas del path, buscar leaks de código, sacar nuevas URLs, analizar los HTTP Headers de las peticiones, descubrir si hay contenido externo vinculado sin firmar, conexiones mixtas HTTP/HTTPs, protecciones anti ClickJacking, etcétera, etcétera, etcétera. En total, decenas y decenas de nuevas tareas por cada URL.

Y cada tarea devolverá información de la prueba, y nuevos activos en forma de nuevas URLs, de nuevos servicios, de nuevos servidores descubiertos, de nuevos certificados digitales que hay que analizar que generarán nuevas tareas. Y habrá un proceso "worker" que deberá hacer cada una de esas tareas.

Figura 5: Un ciclo de auditoría con más de 5 Millones de tareas de pentesting

Para nosotros, la forma de modular la velocidad y el impacto del servicio de Pentesting Persistente se basa en elegir el número de tareas en paralelo que queremos ejecutar sobre un dominio. O lo que es lo mismo, cuántos workers queremos tener haciendo tareas al mismo tiempo.

En total, para que os hagáis una idea, un ciclo completo de auditoría de un sitio de más de 3.500 servidores expuestos en Internet, con todos sus servicios, que van desde servicios de infraestructura típicos como HTTP, FTP, DNS, RDP, BBDD, LDAP, etcétera hasta dispositivos IoT para localizar el Shadow IoT, puede durar, con 20 workers, unos dos meses de trabajo, y puede generar unos 7 millones de tareas - más o menos - con todos los plugins activos. Un ejemplo distinto, en un sitio como cdn-apple.com el ciclo completo puede durar unas 24 horas con el mismo número de workers.

2.- Pentesting en caliente / Reporte contínuo

Cada día hay cambios en los sistemas a auditar, cada día aparecen nuevos hacks o tricks de pentester, cada día aparecen nuevas vulnerabilidades a probar. Un día a aparece el bug del Time Info-Leak en OpenSSH, y al día siguiente sale HTTPoxy, y otro día te despiertas con un hack sobre Drupal o nuevos servicios en servidores web como HTTP2 o QUIC que debes probar y evaluar. Por eso la Knowledge Base con la que trabaja Faast se actualiza en caliente. 

Figura 6: Reporte de vulnerabilidades y debilidades continua (parte 1)

Los plugins se dan de alta, y desde el mimos instante que un plugin se ha dado de alta como tarea que se dispara tras el descubrimiento de un activo bajo una circunstancias, el plugin está funcionando y generando conocimiento. Así, cada día que ampliamos la base de datos de plugins el sistema detecta más y más cosas para conseguir limpiar al máximo y dejar lo más fortificado posible el entorno de auditoría.

Figura 7: Reporte de vulnerabilidades y debilidades (parte 2)

Para ello, el servicio Faast está pensando en hacer reporte continuo de fallos de seguridad y debilidades que pueden ser mejoradas. Está diseñado para, ante la duda de una prueba, reportar y que sea un analista de nuestro SOC el que verifique si esa vulnerabilidad existe o no existe. Como en el caso del HPP de Apple que os conté. El servicio Faast reporta que hay un posible bug de HTTP Parameter Pollution y luego un auditor lo verifica. Esto permite a los equipos de seguridad de las empresas priorizar los esfuerzos a la hora de corregir los fallos, a la hora de incluir nuevos requisitos de seguridad en los nuevos desarrollos o a la hora de tomar decisiones sobre la fortificación del entorno.

3.- Visión circular de los activos

La forma en la que un servicio se presenta frente a un usuario cambia dependiendo del punto de vista del usuario. Si pensamos en una página web, esta puede cambiar dependiendo del usuario con que se tenga iniciada la sesión, o por el navegador web que se esté utilizando, o por la dirección IP desde la que se esté conectando o por la hora a la que se realice la prueba o por la identificación vía WebBrowsing fingerprinting que se haya realizado. No se va a obtener la misma web en un smartphone o un cliente WAP que en un navegador como Google Chrome.

Por eso en nuestra visión del Pentesting Persistente se debe realizar la misma auditoría cambiando el punto de vista de los activos en cada ciclo de pentesting. Una vez simulando ser un navegador para un entorno enriquecido, otra vez siendo un dispositivo móvil con limitaciones. Una vez desde Europa, otra vez desde USA. No siempre se obtienen los mismos resultados, y no siempre son los servidores iguales.

Figura 8: hostnames de cdn-apple.com en medio de un ciclo de auditoría

Como ya os he contado, puede ser que la configuración de todos los servicios de una CDN no sean iguales de la misma manera que puede que todos los servidores de un cluster no estén configurados de la misma forma. Hay que aplicar el algoritmo voraz también para sacar el máximo partido de los activos que nos va a ir mostrando la infraestructura.

4.- Pentesting Persistente + Hacking Manual + BugBounty

Con esta visión no creemos que se reemplace totalmente el trabajo de los auditores de seguridad que hacen pentesting manual. Ni mucho menos. De hecho, pensamos que la información que este sistema genera es útil para que un pentester pueda buscar aquello que es tan singular como para perder tiempo analizando los detalles.

El trabajo debe ser ir más allá que descubrir un XSS Reflejado de libro, un SNMP sin autenticación o un SQL Injection de cajón en una web. Eso debería estar erradicado desde el minuto uno en que el servidor se pone público en Internet y el trabajo del pentester sería llegar más allá. Llegar a esas cosas tan particulares que solo un atacante con tiempo y conocimiento pudiera localizar. 

Por último, un buen complemento sería añadir a la ecuación un Bug Bounty en alguna plataforma que fomente esta última parte, tipo HackerONE, para fomentar que los mejores investigadores de seguridad localicen esos bugs a los que no se llega con:

a) El Pentesting Persistente
b) Las auditorías constantes con tus equipos Red Team internos o externos

Por supuesto, esto es un camino de madurez que debes recorrer, ya que no tiene sentido que abras una BugBounty si te van a sacar 100 XSS y enecientos bugs de no haber hecho un "Fix The Basics". Por eso la recomendación que damos es: Automatiza el Pentesting Persistente, realiza auditorías periódicas con tus equipos Red Team y cuando estés satisfecho con los resultados obtenidos, abre las Bug Bounties. 

Tres años después: Virtual Patching

Con esta visión seguimos trabajando, día a día incluimos nuevos plugins de Discovery, Analysis y Exploitation. Cada día seguimos vigilando la infraestructura expuesta a Internet de casi centenares de grandes empresas. Y cada día seguimos evolucionando la manera en que hacemos las cosas. Hoy en día es uno de nuestros servicios bandera, y yo le dedico todos los días un rato. Además, nuestros partners lo empiezan a integrar para hacer parcheo virtual en caliente en los Firewalls y WAFs, de tal forma que si un bug es descubierto por Faast y verificado en el SOC, se distribuye automáticamente una regla a los Firewalls y WAFs para evitar su explotación, tal y como presentó nuestros compañero Victor Mundilla en el Security Day con el equipamiento de Fortinet

Figura 9: Virtual Patching con Faast & Fortinet

Y seguimos día a día incrementando su potencia, de hecho, con la publicación de cada plugin solemos encontrar fallos en las empresas que son Hacking Friendly o que tienen Bug Bounties abiertas para reportárselos, y como os podéis imaginar, cuando más grande es la empresa y más grande su infraestructura, más fácil es que se quede algo por ahí vulnerable que acabamos reportándole, con su consiguiente agradecimiento.

Saludos Malignos!

Fugas de información por sincronización de DreamWeaver

Lo bueno de trabajar con gente más lista que tú es que siempre aprendes cosas nuevas, incluso cuando menos te lo esperas. Ayer por la tarde en Eleven Paths tuvimos una reunión de seguimiento de Faast, nuestro sistema de Pentesting Persistente, y entre el repaso de las cosas nuevas salió un pequeño detalle de un fichero que se había incluido entre muchos otros entre los que producen fugas de información y que yo no conocía. Su nombre era: dwsync.xml

Figura 1: Faast - Servicio de Pentesting Persistente

Tras la reunión me picó la curiosidad y quise saber más sobre él para entender por qué representaba una fuga de información. Tras leer un poco en Internet, resultó que es un archivo en formato XML que se usa para controlar la sincronización de archivos entre el cliente de Adobe DreamWeaver y  el servidor web en el que se guarda la lista de ficheros que se han subido al servidor y cuándo fue la última vez que se hizo.

Figura 2: Ejemplo de un fichero dwsync.xml

Este fichero no debería estar nunca en el servidor web, pero sin embargo, como sucede con otros archivos en ejemplos similares de fuga de información, como el caso de Fantastico, los famosos archivos .listing - y su aparición en las webs - o los muy comunes ficheros .DS_Store y Thumbs.db, algunos administradores y/o desarrolladores de sitios web acaban subiéndolos por error o desconocimiento, lo que produce por tanto fugas de información que afectan a la totalidad de ficheros subidos como a rutas locales del cliente no deseadas.

Adobe tiene un artículo en la knowledge base sobre su funcionamiento y los riesgos de seguridad asociados, ya que buscando en Internet es posible acceder a muchos de ellos subidos en repositorios de código como como GitHub, carpetas _notes del cliente de DreamWeaver que acaban completas en los servidores web o sitios insospechados. En el siguiente ejemplo, un fichero dwsync.xml cacheado en Google tras ser buscado y abierto por una WebShell.

Figura 3: fichero dwsync.xml cacheado en Google al ser abierto por una WebShell

Jugando con ellos anoche, estuve mirando si era muy costoso encontrar ficheros "ocultos" en un servidor web a partir de estos ficheros dwsync.xml, con el objeto de añadir este archivo a mi lista de técnicas para listar los ficheros de un servidor web, y la verdad es que es bastante sencillo.

Figura 4: Ficheros dwsync.xml indexados en Google

En este ejemplo se puede ver cómo se ha subido un fichero dwsync.xml al servidor web y cómo en él hay una lista de ficheros .mno - archivos de información que también se crean con DreamWeaver -. Es decir un fichero llamado archivo.aaa.mno guarda información relativa al fichero archivo.aaa.

Figura 5: Fichero dwsync.xml con información de sincronización de archivos .mno

En este caso, es posible localizar el archivo de información y ver datos como la dirección de correo electrónico del usuario que creo dicho fichero usando DreamWeaver.

Figura 6: Archivo .mno subido al servidor web

Al final este fichero dwsync.xml es un punto más de fuga de información dentro de un servidor web y es normal que el equipo de Faast lo hubiera metido en la lista de ficheros con fugas de información a revisar en un proceso de Pentesting Persistente. Ten cuidado si usas DreamWeaver en tu organización para que no te afecte una fuga de información tan sencilla como esta.

Saludos Malignos!

Evaluar la calidad de un escáner de vulnerabilidades web

Como ya os he contado, en Eleven Paths estamos creando una nueva cosa que internamente llamamos Foca as a Service. No es nada más que una FOCA mutada para encargarse de hacer los servicios de Pentesting Continuo que vamos a empezar a ofrecer desde el próximo mes de septiembre para crear una nueva forma de hacer auditorías continuas a los sitios web de las organizaciones que lo contraten.

Ayer tuve la ocasión de sentarme a ver en detalle los resultados que estamos obteniendo, y la verdad es que estoy muy contento de la cantidad de pruebas que se hacen en un sitio, y los resultados obtenidos en cada una de las prueba contra sitios que ya habían tenido una auditoría previa. Ahora bien, en los scanners de vulnerabilidades web siempre queda la pregunta que te hace un cliente.

¿Cómo saber que este escaneo de un escáner de vulnerabilidades es suficientemente bueno?

Es difícil de valorar, y dependiendo de la naturaleza de las vulnerabilidades que tenga el sitio web unos encontrarán más o menos resultados. En un trabajo del 2013 realizado por Fernando Román Muñoz y Luis Javier García Villalba en la Universidad Complutense de Madrid titulado "METHODS TO TEST WEB APPLICATION SCANNERS" se hacía una curiosa comparativa sobre varios tests de comparación de resultados sobre escáners de vulnerabilidades web.

Figura 1: Clasificación de escáners web en 4 comparativas distintas

En él se concluye al final que es necesario crear un conjunto de vulnerabilidades de referencia en aplicaciones web que vayan adaptándose a la realidad del tiempo, es decir, que vaya cambiando el conjunto de referencia a medida que avanza el estudio de nuevas vulnerabilidades o técnicas de descubrimiento.

Figura 2: Tipos de vulnerabilidades que se evalúan en las diferentes comparativas

En PCI DSS, el famoso estándar para los medios de pago con tarjetas de crédito, existe la figura del ASV (Approved Scanning Vendors) que no es más que escáners de vulnerabilidades aprobados por PDI DSS para ser utilizados en la búsqueda de vulnerabilidades para pasar la certificación PCI. Estos escáners deben buscar y encontrar un conjunto de vulnerabilidades antes de conseguir el nivel de aprobación, y estas van desde nivel de red o versiones de software desactualizadas hasta las que aparecen en aplicaciones web.

La descripción de las vulnerabilidades que debe buscar y encontrar un ASV las podéis ver en la guía "Payment Card Industry (PCI) Approved Scanning Vendors" donde en la parte relativa a web se describe lo siguiente:

Figura 3: ¿Qué vulnerabilidades web debe encontrar un ASV?

Por supuesto, los ASV no tienen necesariamente que ser los mejores del mundo, pero sí que han pasado al menos un conjunto estandarizado de vulnerabilidades que eliminarían las que PCI ha definido como más importantes.

En un entorno real, puede que la vulnerabilidad sea muy gorda, pero ningún escáner sea capaz de localizarla. De hecho, hace tiempo hicimos una comparativa con los escáners más populares y las Inverted Queries, es decir, consultas SQL escritas al revés con vulnerabilidades de SQL Injection, y los resultados fueron bastante sorprendentes.

Figura 4: How "·$% developers defeat the web vulnerability scanners de Chema Alonso

Al final, la recomendación más efectiva es utilizar cuantos más escáners se pueda mejor para buscar las vulnerabilidades, porque no todos utilizan las mismas técnicas de detección y no buscan las mismas vulnerabiliades y fallos en las aplicaciones web, que estas pueden aparecer y ser encontradas de formas muy diversas.

Saludos Malignos!