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!