Faast, módulos y plugins

Faast dispone de múltiples módulos o “plugins” que se encargan de realizar una o varias comprobaciones para adaptarnos a nuevos medios (sistemas, páginas o frameworks) o con el fin de añadir rápidamente pruebas específicas para vulnerabilidades conocidas. Así, hemos creado de forma rápida plugins para Heartbleed, Shellshock, FREAK, MS15-034, etc…

Aprovechando el sistema modular, se ha implementado un sistema similar para reutilizar todas las peticiones web que realiza Faast hacia los activos de la organización y analizar esas respuestas. Esto permite retroalimentar la auditoría de forma continua, tal y como realiza un pentester profesional. Comentemos algunos de estos módulos.

Crawling: Mapa de activos y fugas de información

Es el encargado de la esencial parte de Crawling para completar el mapa de activos. Gracias a la infraestructura de Faast, no solo permite capturar enlaces, sino además correos electrónicos ubicados en cualquier archivo público, completándose con otras vías de obtención de correos electrónicos como pueden ser la búsqueda en directorios PGP o la recolección de metadatos gracias a Metashield.

Ejemplos de correos extraídos por Faast

Tras la aparición del módulo de Crawling, se han ido añadiendo módulos “complementarios”. Por ejemplo el de fugas de información. Las fugas de información pueden referirse tanto a los datos personales como a los característicos errores de programación PHP o de configuración del servidor que permiten al atacante conocer mejor la infraestructura y preparar mejor otros ataques posteriores.

Este sistema de módulos se vuelve muy versátil cuando se combinan los módulos entre sí. Por ejemplo, para provocar fugas en este sentido, se utilizan distintas técnicas como: realizar conversiones de tipo en las variables la cadena de consulta (query string), inyecciones a motores de base de datos o simplemente introducir caracteres especiales en la petición. Estas acciones pueden provocar un comportamiento inesperado en las aplicaciones web con fugas de información.

Ejemplo de reporte de fuga de información

Reinterpretación de las fugas

Ante las fugas de información es necesario interpretar y comprenderlas para mejorar el escaneo. Por ejemplo, en los errores de PHP podemos destacar la recuperación del usuario en los errores de autenticación de SQL. También podríamos destacar el error que el servidor muestra cuando el código del desarrollador intentar acceder a una variable que no ha sido asignada. Por defecto será null y esta excepción se mostrará en la web de esta forma:

Ejemplo de vulnerabilidad con la variable URL sin definir

Esta variable es capturada y reportada como dentro de la URL tanto en la cadena de consulta (query string) para que posteriormente el resto de módulos de Faast realicen las pruebas pertinentes sobre ella.
Siguiendo con el esquema de análisis del contenido de los archivos que procesa Faast, cabe destacar la detección de las fugas de código fuente. Como se comentó en post anteriores sobre la subida de repositorios de código a entornos de producción, es habitual que el servidor no este configurado adecuadamente o se realicen copias de seguridad de archivos. Estas acciones provocan que la plataforma no detecte los archivos como archivos interpretables (como es el caso de PHP) y este código quede accesible.

Fuga de información en el código fuente

La detección de fugas de información se complementa con la detección de servidores que están en modo depuración. Este módulo se encarga de detectar configuraciones que solo deberían estar presentes en entornos de desarrollo y que no deberían usarse en entornos de producción reportando una recomendación cuando se detecta esta configuración.

Dependiendo de la plataforma, esta recomendación puede ser más o menos crítica. Podríamos citar el caso del framework Laravel, que en caso de tener los errores habilitados puede ofrecer mucha información sobre el código.

Y no sólo con el HTML o peticiones web


Aprovechando la estructura modular, en Faast no nos hemos limitado a los módulos que analizan las peticiones HTML, sino que también se evalúan los archivos binarios. En el caso de ficheros ejecutables se valora si están o no firmados digitalmente.

Recomendación sobre archivos ejecutables no firmados

En el caso de ficheros comprimidos, Faast no solo es capaz de detectar copias de seguridad de carpetas y archivos basándose en el original, sino que de forma transparente, estos son evaluados en busca de código fuente o de archivos relevantes. Se reportan para que el cliente evalué si esos ficheros son legítimos o realmente suponen un riesgo para la organización.

Módulos para recursos externos

Cargar recursos de forma externa puede suponer una vía de ataque para los atacantes. Un ejemplo es el ataque que sufrió la RSA Conference sufriendo una “desfiguración” por cargar una librería externa de JavaScript. Al hacerlo, se delega el control a un tercero. Faast reporta los enlaces a imágenes, librerías JavaScript u hojas de estilo CSS que se deleguen a otras organizaciones.

Teniendo en cuenta la política CORS, también se valoran los enlaces que no cumplan esta política. Dependiendo de la configuración del navegador del cliente, puede que muestre la web incorrectamente. Por ejemplo, cargar elementos por HTTP cuando se navega a través de HTTPS provocaría una alerta en el navegador.

Y no solo eso, Faast reporta vulnerabilidades o recomendaciones valorando la configuración de las cabeceras que implementa el servidor, como por ejemplo la ausencia de la cabecera X-Robots-Tags en el caso del fichero Robots.txt para evitar su indexación, la ausencia de las cabeceras Content Security Policy, o la ausencia de la cabecera X-FRAME-OPTIONS para evitar posibles ataques de clickjacking. Además de, como añadido, malas configuraciones en cabeceras como podrían ser el desactivar la protección contra XSS de los navegadores con la cabecera XSSProtection o ser muy permisivo con la configuración CORS con la cabecera Same-Origin Policy.

Óscar Sánchez

oscar.sanchez@11paths.com