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!

El Departamento de Homeland Security tiene los mismos problemas de seguridad que muchas grandes empresas

La gestión de la seguridad de una organización grande suele ser algo complejo. El volumen de sistemas de información que se manejan crece día a día a una velocidad superior a la que se introducen los mecanismos de gestión y seguridad. Además, la obsolescencia continuada del parque informático, el cumplimiento normativo y legislativo, unido a los incidentes que surgen, hacen que el día a día de un equipo de seguridad de una organización sea una aventura en la que tienen que lidiar con los temas urgentes, los proyectos importantes y la visión a largo plazo. Una aventura que los CISO y los CSO de las organizaciones deben vivir con la cabeza fría para llevar a la compañía dentro de los límites de un "Riesgo Aceptable".

Figura 1: El DHS es como cualquier otra empresa u organización grande

Pero no penséis que esto es solo su trabajo. No, al igual que hay auditores fiscales y contables que revisan todo lo que tiene que ver con el movimiento de dinero y presupuestos dentro de las empresas, también están los auditores internos de seguridad que revisan si el trabajo de los CISO y los CSO está siendo el adecuado o no y si, está alineado y cumple con la normativa global, central o gubernamental. Estos informes suelen, además, sacar del plan de trabajo a los CSO y CISO ya que acaban en los más altos estamentos de la empresa y les rompe la planificación de su trabajo. 

Figura 2: Informe de auditoría de seguridad a los sistemas IT del DHS

En el gobierno de los Estados Unidos también hacen estos informes de auditoría, y han publicado el referente al mes de Noviembre que se ha realizado a los sistemas de información del DHS (Department of Homeland Security), con unos resultados que he visto en tantas y tantas organizaciones que me he sentido hasta "feliz". No feliz en el sentido de que disfrute con que un sistema de seguridad esté mal, sino feliz porque he estado con muchos - y cuando digo muchos, son muchos - CISO y CSO que sufren por las cosas que ellos saben que tienen mal y luchan contra viento, marea y presupuestos por ir avanzando poco a poco. Muchos de ellos, además, sufren pensando que están peor que otros, y ver que el DHS tiene exactamente los mismos problemas, me ha hecho animarme a publicar este artículo para mis amigos CISO y CSO.

Shadow IT - Mal inventariado de activos

El primer punto importante que dice este informe de auditoría seguro que los conocéis muchos. El informe de auditoría hace referencia a que los informes de activos consolidados de las distintas áreas no muestran los mismos activos que el informe del área de seguridad. En esto falla el DHS.

Figura 3: Mal inventariado de activos en los reportes

Esto también se produce porque no hay un sistemas centralizado de inventario o porque muchas áreas en las empresas empiezan a meter lo que se ha dado en llamar Shadow IT, o lo que es lo mismo, del Bring Your Own Device referido al terminal smartphone, muchos departamentos de las empresas empiezan a hacer cosas como Bring Your Own Cloud, Bring Your Own NAS, Bring Your Own WiFi Hotspot, etcétera, debido a que como muchos empleados tienen conocimientos avanzados de tecnología, comienzan a hacerse "sus cosas" cuando las necesitan, generando un problema de seguridad en la organización sin darse cuenta. Esto, por supuesto, da lugar a las famosas Hidden Networks dentro de las empresas.

Defence in Depth - Do the Basics

Si una empresa no está preparada para asumir su siguiente paso en el nivel de madurez de seguridad, entonces va a estar perdida. Siempre contamos que las empresas más inmaduras en seguridad tienden solo a invertir en Prevenir los incidentes de seguridad, por lo que basan muchas de sus inversiones en software de protección perimetral, con la esperanza de poder frenar todos los atacantes fuera de sus sistemas. Es como los padres que quieren proteger a sus hijos de todos los males sin asumir que no van a ser capaces de hacerlo siempre. 

Figura 4: Sistemas operativos sin soporte

Las empresas que están en un segundo nivel de madurez, asumen que los enemigos están en su red e invierten más en Detectar. Pueden ser atacantes que hayan logrado entrar por una red WiFi en una sucursal, por una impresora mal configurada en Internet, o por un simple Spear Phishing a la persona concreta, o directamente un empleado malicioso pero hay que asumir que el enemigo está dentro. Si no has preparado tus sistemas dentro del perímetro para ser "resilliance", entonces será un paseo militar por tu red. 

Figura 5: Software sin actualizar en los puestos de trabajo. Un regalo para un Metasploit

Mi recomendación es que no dejes de aplicar la política de Defensa en Profundidad en tu organización, y comienza por lo más básico. No dejes sistemas sin actualizar constantemente. No utilices sistemas operativos sin soporte y actualiza absolutamente todo el software que corra sobre los sistemas operativos. Si esto pasa, un atacante dentro de un equipo con un Metasploit va a destrozar tu sistema, tu red, y tu empresa como un cuchillo cortando mantequilla caliente. En esto, también falla el DHS, como muchas empresas. 

Procesos & Incident Response Plan

La gestión es importante en la seguridad. De hecho, supongo que estaréis todos hartos de escuchar que la seguridad no es un producto sino un proceso continuo de gestión que mezcla, Tecnología, Personas y Procesos. Si no tienes los procesos de seguridad bien incrustados en tu compañía, va a ser completamente inmanejable gestionar la seguridad y dentro de esos procesos deben estar los relativos al último nivel de madurez de una compañía: Asumir que el riesgo va a convertirse en realidad y tener un proceso para responder a ese incidente.

Figura 6: Malos procesos de gestión de incidentes de seguridad

¿Qué pasa si me roban los datos del servidor central?¿Qué pasa si un atacante encuentra un 0day en mi sistema expuesto a Internet? ¿Cómo voy a responder ante ese problema? Todos los Planes de Contingencia deben tener su Incident Response Plan, para poder gestionar y resolver correctamente el fallo. Las empresas maduras asumen que eso puede pasar y tienen un plan. Nosotros contamos el caso del bug de Jeep que Charlie Miller y Chris Valasek encontraron. La compañía no tenía previsto que apareciera un bug en el software y no contaba con un sistema de actualización, y le ha costado mucho dinero en tener que actualizar el software coche a coche.

Identity & Access Control

Otro de los puntos en el que el informe de DHS ha hecho hincapié ha sido en la mala gestión de la Identidad y el Control de Acceso. Desde contraseñas inseguras, hasta la falta de uso de Segundos Factores de Autenticación en los sistemas de información internos de la organización, pasando por una falta de control de cuentas privilegiadas.

Figura 7: Control de cuentas privilegiadas

Entre las cosas que cita hay una reflexión más que interesante que debería hacerte replantear los procesos legales de tu organización, y es que las cuentas que están autenticadas con usuarios y contraseñas las cataloga de "accesos anónimos", ya que el usuario y la contraseña puede ser robado de tantas y tantas formas que garantizar que la acción que hace una cuenta en un sistema ha sido realizada por la persona a la que se le entregó inicialmente es complicado.

Figura 8: Falta de Segundos Factores de Autenticación

Para eso, el plan incide en el establecimiento de segundos factores de autenticación y el control de cuentas privilegiadas, no solo en los sistemas internos, sino especialmente en los accesos remotos a los sistemas de información. Hay muchas organizaciones que tienen sistemas de información importantes para la empresa puestos en Internet y sin ningún segundo factor de autenticación y/o autorización todavía. Si te interesa este tema, te recomiendo que veas cómo lo vemos la identidad, la autenticación y la autorización en Eleven Paths con nuestras tecnologías.

Continuos Monitoring & Persistent Pentesting: Long Hanging Fruit

Controlar la seguridad de una organización con auditorías cíclicas cada 6 meses o cada año, es algo que deja una ventana de exposición muy amplia. Estas auditorías son una buena verificación de que se están haciendo bien las cosas, si ya has implantado un sistema de Continuous Monitoring que verifique día a día las vulnerabilidades de todos tus sistemas, o un sistema de Pentesting Persistente como nuestro Faast que va a estar buscando vulnerabilidades día a día con una análisis exhaustivo de todos los activos expuestos a Internet.

Figura 9: Long hanging fruit - Sin actualizar, passwords inseguras y SQL Injection

Que una organización como el DHS tenga Long Hanging Fruit en forma de SQL Injection en las webs de sus sistemas de información dice muy poco de sus sistemas de Continuous Monitoring y de Pentesting Persistente. Si quieres que te hagamos un piloto gratuito para tu organización de nuestro sistema de Pentesting Persistente Faast, ponte en contacto con nosotros y vemos cómo hacértelo.

Figura 10: Aplicación de Continuous Monitoring & Persistent Pentesting

Dicho esto, si eres un CSO o un CISO de una organización espero que este informe te sirva para hacer ver a los jefes lo complejo que es gestionar la seguridad de una empresa. Y si te sirve de algo mi opinión, en los presupuestos del año que viene huye de tecnología super-fashion que acaba de ganarse un espacio en un nuevo cuadrante mágico de algún analista y céntrate en afianzar las cosas fundamentales que yo creo que están bien recogidas en este artículo. 

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!

Buscando ataques DOS

Una de las pruebas que más preocupa siempre en las auditorías de seguridad es la de los ataques de Denegación de Servicio (DoS). Esta preocupación suele ser porque si el sistema no aguanta, entonces afecta directamente al negocio. Los proveedores de Internet que están dando hosting de servicios profesionales ya tienen obligatoriamente que tener algún servicio serio de mitigación para este tipo de ataques. Como sabéis, uno de los correos que yo leo siempre sobre las cosas que me piden tiene que ver con una petición de este tipo.

Figura 1: Petición de DOS

Mi compañero en Eleven Paths, David Barroso (@lostinsecurity) ha hablado muchas veces de este tipo de ataques, utilizando diferentes medidas de ataque, y de los servicios de CloudFlare para mitigar estas situaciones. Para ilustrar la importancia que cobran hoy en día, siempre pone este vídeo de los servicios DDOS que se anuncian en Internet.

Figura 2: Vídeo de anuncio de servicios DDOS profesionales

Los servicios de una empresa, cuando sean cores, no pueden estar desprotegidos contra este tipo de ataques, y además de las pruebas de pentesting continuo deben realizarse también las pruebas de DDOS. Entre esas pruebas, no solo hay que ver si el sistema aguanta el volumen de tráfico masivo, que para eso ya hay sistemas y soluciones que ofrecen esa protección, sino que hay que buscar los límites de carga de las aplicaciones hospeadas que pueden tirar los servicios.

La idea es tan sencilla como que ciertas operaciones complejas de una aplicación web pueden requerir de mucho trabajo en cuanto a cómputo, memoria o almacenamiento en disco, y con una petición sostenida sin necesidad de que sea masiva, sea posible tumbar el sitio. 

En una instancia de una base de datos configurada sin límites, es decir, con valores unlimited en el tamaño de memoria, el número de threads o el crecimiento de los tablespaces y los datafiles, cae con un ataque de SQL Injection con un simple 'or '1'='1 tras generarse el volcado de una consulta compleja que use varios joins y resulte en varios millones de registros. Si es lanzada cuatro o cinco veces puede conseguir tumbar los límites físico del servidor donde esta siendo hospeda.

Yo sin querer he tumbado alguna instancia haciendo pruebas con las consultas pesadas, y en Marathon Tool fue necesario poner un intervalo de tiempo de descanso para no tumbar las instancias que empezaban a dejar de responder después de tener que merendarse unas consultas de varios milloncejos de registros en consultas con ocho o diez tablas en join. 

Figura 3: Pausas después de consultas en Marathon Tool

En estos ejemplos que estoy contando existen vulnerabilidades de SQL Injection, pero a veces el bug de denegación de servicio es el más que común cuadro de diálogo de búsqueda. En el caso de la página de búsqueda de sitios web hay algunas de ellas especialmente vulnerables a estos tipos de ataques porque:

1.- Permiten búsquedas que devuelven más datos de los que tienen sentido que se proporcionen a un usuario: Hasta los buscadores como Google o Bing ponen límites de resultados ofreciendo como mucho 1.000 por cada consulta - lo que nos obligó por ejemplo en FOCA a tener un tratamiento especial en los huge domains - . Una sitio web que permite consultas de búsqueda que devuelvan 444.000 resultados está cargando innecesariamente de trabajo al sitio web porque ningún usuario va a revisar todos esos resultados.

Figura 4: Buscador de web devulve 444.882 resultados en cada búsqueda

2.- Permiten lanzar consultas de grandes resultados con una única petición: Muchos sitios web permiten que la consulta se haga con una simple petición GET, lo que facilita sobre manera cualquier automatismo, e incluso el uso de los buscadores como arma de destrucción masiva, utilizando sistemas de amplificación de peticiones como los que mostramos allí. 

3.- No limitan el número de consultas por dirección IP y tiempo: Lo que ayuda a que el ataque sea sostenible el tiempo suficiente como para cargar el sitio web. 

Al final, las pruebas de DOS son más que necesarias en cualquier auditoría de seguridad, así que no debes dejarlas fuera de ellas, porque si no el sistema se puede caer en el momento menos deseado e incluso, alguna vez, por torpeza de los mismos usuarios.

Saludos Malignos!

¿Cada cuánto tiempo se debe realizar un pentesting?

Los más experimentados en el mundo de la gestión de sistemas informáticos no publican un nuevo servicio en Internet sin pasar previamente una auditoría de seguridad. Los más inexpertos siguen haciéndolo, como se puede apreciar en casos como la web del Senado de los 500.000 € o el famoso sitio web de la presidencia europea de España en el año 2010. Tras esa primera auditoría, la pregunta que hay que responder es ¿cuándo se debe hacer la siguiente auditoría?

Figura 1: XSS de Mr. Bean en la Web de la presidencia de EU 2010

Si eres lector de este blog ya sabes qué es lo que opino yo, pero dejadme que lo argumente de una manera más extensa para poder explicar cómo lo veo yo de forma más pausada.

¿Por qué hacer una auditoría de seguridad informática?

Tal vez parezca una perogrullada esta pregunta, pero seguro que la has escuchado alguna vez si has presentado un presupuesto al comité de la empresa. Tal vez incluso te pregunten si no vale con la auditoría que se hizo la última vez o la que se hizo cuando se puso en producción el servicio:

“¿No hicimos una auditoría y nos dijeron que estaba con una seguridad aceptable?”

Los motivos por los que se hace una auditoría informática suelen ser varios, pero se pueden reducir a dos: Para cumplir con los procedimientos o para evitar fallos de seguridad.

Al lector no experimentado puede parecer que el primero implica al segundo, pero no es así. El primero implica cumplir las normas, y no tener un objetivo que persiga la seguridad del proceso. Para ello se buscan auditorías que se contratan a precio de saldo, con cientos de direcciones IP por jornadas, automatizadas al máximo y aprovechando hasta el último día para cumplir con los procedimientos.

Estas auditorías se pueden hacer por cualquier normativa interna de la empresa, pero generalmente suele ser por cumplir con alguna auditoría externa, tipo ISO 27.001 o PCI-DSS, y los plazos que se aplican tienden a ser, habitualmente, de seis meses a un año, quedándose fuera de la auditoría todo aquello que no se considera “core” dentro de la certificación.

Cuando se suele contratar una de estas auditorías se busca un informe, lo más gordo y rápido posible, que se adjuntará a la documentación del servicio y que suele ser lo más automatizado posible, utilizando escaners de vulnerabilidades y herramientas certificadas para tal tarea. Un tramite automatizado.

Las segundas auditorías, las que se realizan para estar seguro, son de otra forma. Suelen estar impulsadas por los equipos de seguridad y buscan descubrir de verdad cuál es el estado real de la seguridad. Suelen ser incómodas para negocio, ya que si sale algo severo obliga a trabajar a toda la empresa. En ellas se buscan equipos serios, se hacen a veces con equipos en paralelo que buscan a la vez los fallos de seguridad y presentan resultados que permiten a los responsables buscar no solo las deficiencias, sino una garantía de que el resultado al final de la auditoría será bueno.

¿Cada cuánto tiempo se debe hacer una auditoría de seguridad?

Si lo que buscas es una auditoría del primer tipo, como ya he dicho, las normas suelen ser laxas y permiten periodos de un año. Tener un sistema expuesto a Internet durante un año sin realizar auditorías de seguridad – por mucho mantenimiento de sistemas y actualización de parches que se haga – es una temeridad.

Figura 2: Recomendaciones de frecuencia de auditorías según PCI-DSS

Hoy en día, los cambios del software base son constantes, y el entorno sobre el que correo una aplicación web en un instante de tiempo T1 no se parecerá al entorno de software en el que correrá en un instante de tiempo T1+1 año. Durante ese periodo el sistema operativo habrá actualizado cientos de parches, cambiado componentes internos y modificado pequeñas funciones en componentes que habrán sido modificados. Habrá cambiado el software que utiliza el cliente y el software de toda la electrónica de red que conecta desde el usuario final, hasta el almacén de datos.

No solo habrá cambiado el software base, sino que se habrán producido decenas o cientos de cambios pequeños en la web que sumados generarán un cambio sustancial en el código de la aplicación. Se habrán añadido nuevos interfaces de usuario para soportar los últimos gadgets, se habrá cambiado la plantilla de la web para adaptarse a los cambios de diseño y se habrán tocado pequeñas o grandes funcionalidades en la web, que sumados todos harán que el código de todo el sistema se parezca poco al que había en el T1 original.

Pero lo más importante es que durante todo ese periodo habrán sido publicadas tropecientas conferencias de seguridad ofensiva que mostrarán nuevas técnicas de hacking, nuevas herramientas o nuevo conocimiento sobre la tecnología existente, se habrán publicado miles de artículos en blogs, congresos académicos y revistas técnicas y habrán aparecido cientos de vulnerabilidades en el software publicadas en foros, listas de correo o bases de datos de expedientes de seguridad.

La suma de estos tres factores, es decir, el software base de la aplicación web sobre la que corre el servicio, los cambios en el código de la aplicación y el avance del conocimiento en técnicas de ataque, hacen que en un año el resultado de una auditoría web en T1 y en T1+1 año pueda resultar “inseguramente” distinto.

La ventana de tiempo importa

Este periodo de tiempo es lo que permite que cuando se hace una auditoría de seguridad, por regla general, siempre aparezcan cosas de nivel crítico. Es común auditar un sistema y acabar encontrando cosas de alta criticidad. Si has hecho auditorías de seguridad ofensiva, estarás acostumbrado a que en el 90 % de los casos acabes entrando hasta la cocina usando las últimas herramientas que traiga para pentesting Kali, los últimos exploits de Metasploit o buscando fallos de SQL Injection en las últimas páginas web añadidas.

Esta ventana de tiempo es también uno de los elementos que permite que, como decía en la presentación, los ciberespías siempre ganen, ya que si el malo descubre un fallo antes que lo descubra el pentester o el auditor de seguridad, entonces ya habrá ganado.

Pentesting Continuo, Pentesting by Desing

Es por esto por lo que para que un sistema esté “razonablemente” seguro, decía yo que los auditores tienen que ser más rápidos encontrando los fallos de un sistema que los malos explotándolos. Para ello es necesario que cada vez que se cambia el software de base o se realiza un cambio en una aplicación un pentester pruebe todas las técnicas conocidas, además de que cada vez que se descubre un nuevo bug, una nueva técnica de hacking o un nuevo fallo de una tecnología, esta se revise sobre todo el sistema.

Con estas ideas es con lo que en Eleven Paths estamos trabajando en hacer de la FOCA una solución “FOCA as a Service”, para revisar la seguridad de una aplicación web constantemente, revisando todos los días todos los fallos conocidos sobre el sistema. Evolucionando el Pentesting Driven by FOCA a un Pentesting Done by FOCA añadiendo día a día nuevas pruebas de auditoría. Es decir, revisando una base de conocimiento K1 sobre un sistema en los instantes de tiempo T1, T2,T3, … Tn, pero al mismo tiempo que se realiza ese análisis constante en tiempo, la base de datos de conocimiento irá creciendo día a día, pasando a ser K2, K3, … Kn a lo largo del tiempo.

Figura 3: Arquitectura versión "alpha" de FOCA as a Service

Esto nos dejaría que un sistema informático deberá soportar el pentesting by desing, permitiendo que se revise el conocimiento de seguridad Kn en un instante de tiempo Tn. Es decir, la auditoría de seguridad de un sistema debe ser algo lineal y constante, que mantenga el nivel de intensidad a lo largo del tiempo.

¿Es sostenible esta revisión continua de la seguridad?

A día de hoy muchos sistemas no están preparados para esta intensidad de auditoría. Ya muchos administradores se ponen nerviosos con pensar sólo en que llega “la semana de la auditoría” o “la noche de la prueba de DDOS”, como para escuchar que se van a estar realizando estas pruebas de forma continuada. Lo sé. Pero es a donde creo que debemos llegar, a que realizar un proceso de auditoría de seguridad continuado sea algo habitual que se realiza antes de publicar el servicio en Internet.

Saludos Malignos!

Pentesting Persistente, Pentesting Contínuo, Pentesting by Desing

Cuando se hace la auditoría de seguridad a una empresa lo más probable es que siempre acabes entregando un informe en el que se demuestra que ha sido posible entrar - si no a todo - a zonas importanters del sistema. Además, siempre aparecen vulnerabilidades menores que ayudan a preparar ataques más importantes al sistema o fallos de configuración en el entorno que abren definitivamente la puerta.

Esto en la vida real se puede ver fácilmente en lo sencillo que es encontrar vulnerabilidades en sitios web de grandes compañías como Apple, o en webs de proyectos de importancia como el Senado o la web de la famosa Presidencia Europea de España, que acaban sufriendo por errores fácilmente detectables en una auditoría de seguridad.

Aún así, muchos de los sitios webs que acaban siendo vulnerados han pasado alguna auditoría de seguridad en algún momento de su ciclo de vida, lo que hace dudar más si cabe, sobre si el modelo de auditoría de seguridad externa que contratan muchas empresas tiene sentido o no. O lo que es lo mismo, responder a la pregunta de por qué en la mayoría de los casos en los que se hace una auditoría de seguridad, se descubren cosas graves. La respuesta a esta pregunta es sencilla:

El pentesting no debería ser un proceso puntual que se contrata, sino un servicio de ataque 24x7 durante todo el ciclo de vida de tu sistema.

Todos los días a todas horas debería estar el sistema informática bajo el ataque del pentester. Para ello tu sistema tiene que estar diseñado con soporte para Pentesting desde la fase de diseño. Y si no, pues perderás la guerra y acabarás owneado.

Mi teoría es que mientras te ataquen más los más malos que los buenos, tienes las de perder, y para ello es necesario contar con un proceso de pentesting diferente. No se puede contar con una grupo de pentesters durante una semana que vengan y te demuestren que pueden colarse en tu sistema. Así lo único que estás contrastando es que en la próxima auditoría que te obliguen a hacer dentro de un año volverás a ser comprometido - si no totalmente, al menos parcialmente -.

Pentesting Persistente/ Pentesting Continuo

Entre el tiempo que pasa entre un proceso de pentesting y otro tu sistema informático va a sufrir cientos de mutaciones provocadas por actualización del software de los servidores, el software de los clientes y/o toda la electrónica de red. También habrá actualizaciones y cambios en el código de tus sitios web que habrán realizado tus desarrolladores. Tus certificados digitales se habrán hecho un poco más viejos, algunos hasta habrán caducado, y las contraseñas de tus usuarios habrán sido usadas de forma insegura en cientos de sitios. Por supuesto, tu sistema informático habrá crecido en tamaño, quieras o no, un buen porcentaje.

A todo esto, habrá que sumar unos cuantos miles de charlas en conferencias de seguridad y hacking en las que se habrán publicado cientos de herramientas, cientos de nuevos trucos de hacking y cientos de bugs en componentes que utilizas en tus sistemas.

Todos estos cambios, todas estas nuevas herramientas, todo este nuevo conocimiento estará ya en el arsenal de un pentester que habrá seguido estudiando Kung-Fu para darle una buena paliza a tu sistema la próxima vez que te encuentre.

¿Y si tengo el al equipo de pentesting interno?

Genial. Si tienes un equipo de seguridad haciendo pentesting todo el día, con formación continua, con capacidad de lanzar una prueba contra un sistema todos los días a cualquier hora, sin necesidad de pasar una enorme lista de restricciones antes, entonces estarás haciendo lo que te digo: Pentesting Continuo. 

Pero si tu equipo de pentesting interno no puede hacer una prueba de D.O.S. cuando quiera para testear el sistema, o no puede pegarle fuerte y duro a una web porque el servicio puede dejar de funcionar, entonces estás perdido, ya que tu sistema no cuenta con Pentesting by Desing.

Tus sistemas tienen que estar diseñados para soportar el acoso 24x7 de los ataques de los malos, y por tanto debería estar diseñado para soportar el acoso 24x7 de los buenos. Si no es así, los malos ya han ganado y es cuestión de tiempo que acabes con un defacement de LulzSec - u otro grupo - o una portada en los medios de comunicación por un bug de renombre.

Yo sistematicamente pruebo los bugs nuevos que aparecen con sitios que deberían tener un cierto nivel de preocupación con estos temas, como los metadatos con la Misile Defense Agency o en las agencias de inteligencia mundiales, los .DS_Store con Apple y Google, o los fallos de IIS Short Name en webs de Beijing y Washington D.C. Al final ni ellos tienen un sistema de Pentesting continuo 24x7.

Pentesting by Design

Para que puedas tener un proceso de auditoría que sea más rápida y efectiva que los ataques de los malos tienes que hacer que tu sistema cuente con el Pentesting by Design. Esto quiere decir que el dimensionamiento de la memoria, el almacenamiento y el ancho de banda de la línea de comunicaciones en tu sistema esté diseñado con el porcentaje necesario para dar una calidad de servicio adecuada a tus usuarios, más el porcentaje destinado al ataque continuo de los malos, más el porcentaje necesario para que tu sistema pueda sufrir un proceso de Pentesting Continuo 24x7 desde el primer día.

¿Es suficiente esto?

Pues no, por supuesto. El Pentesting by Desing te permitirá realizar un Pentesting Persistente de tu equipo, lo que te permitirá sólo que los procesos de auditoría de seguridad tengan las mismas oportunidades que un atacante malo, pero luego deberás seguir haciendo los deberes en todas las fases de gestión de la seguridad de tus sistemas.

Actualización: La implementación de esta idea la llevamos finalmente a la realidad con nuestro servicio de Pentesting Persistente Faast que ofrecemos a grandes empresas e industrias.

Saludos Malignos!