lunes, mayo 29, 2017

Cómo usar las novedades en ZAP 2.6.0 para hacer pentesting con FOCA de @elevenpaths

ZAP es una herramienta gratuita empleada en test de intrusión en aplicaciones WEB que ayuda en la búsqueda y explotación de vulnerabilidades a la que dedicamos muchas páginas en el libro de Hacking Web Tecnhologies. No solo son de utilidad para un pentester, y también es por eso una herramienta muy utilizada durante el proceso de desarrollo por los programadores de las aplicaciones web, antes de su puesta en producción, en búsqueda de fallos que corregir.

Figura 1: Cómo usar las novedades en ZAP 2.6.0 para hacer pentesting con FOCA

La última versión, la 2.6.0 publicada recientemente presenta algunas características interesantes que me gustaría contaros a continuación, integrándola con la FOCA de ElevenPaths, para sacarle partido en casos como el que os presento hoy.

JxBrowser

Se trata de un contenedor sobre Chromium que viene integrado directamente en esta versión y permite directamente introducir URLs para que ZAP vaya capturando las peticiones/respuestas HTTP. En las versiones anteriores no venía directamente integrado en ZAP y había que instalarlo como un complemento a parte. Ahora lo tienes a golpe de icono.

Figura 2: Icono para lanzar JxBrowser

Presenta la ventaja de que no es necesario configurar de manera manual las opciones de navegación con proxy en un navegador externo a ZAP. Además, introduce por defecto su propia CA para poder monitorizas las peticiones/respuestas que vayan bajo HTTPS con técnicas de Bridging HTTPs.

Figura 3: Mensaje que aparece al lanzar JxBrowser

Para capturar peticiones y respuestas HTTP/HTTPS, únicamente hay que introducir la URL de la web a auditar y ZAP empezará a monitorizar en intercambio de mensajes entre cliente y servidor.

Figura 4: Envío y captura de peticiones HTTP desde JxBrowser

Exportación de las URL detectadas por el spider a un fichero

Una de las características de reporte más demandada hasta el momento y que incorpora esta nueva versión es la posibilidad de exportar en un fichero de texto todas las URL que el spider ha ido encontrando durante el rastreo de la web.

Figura 5: Exportación de las URLs descubiertas a un fichero de texto

Como veremos más adelante, esta funcionalidad puede resultar bastante útil porque, junto con otras herramientas como FOCA, puede ayudar a detectar vulnerabilidades que puede que inicialmente pasen desapercibidas para ZAP, como por ejemplo, localización de métodos HTTP inseguros en el servidor web, listado de directorios abierto, etcétera.

Codificar/Decodificar/Hash

Una característica interesante es la opción de Codificar o Descodificar información. Esta funcionalidad puede ser útil, por ejemplo, en las fases de desarrollo de una aplicación web mientras se prueba el sistema en busca de fallos y se necesita codificar información en formato Base64 o hexadecimal, descodificar una URL.

Figura 6: Herramienta de Codificar/Descodificar/Hash

Figura 7: Diferentes opciones de codificación y decodificación

Figura 8: Opciones de cálculo de Hashes (resúmenes)

A veces puede que necesitemos generar un hash en formato MD5 o SHA1 (nunca obtener el texto claro que genera el hash) para manipular el resumen que aparece en una petición al servidor web.

Prueba de Concepto: ZAP & FOCA

En esta pequeña prueba de concepto vamos a poner en práctica la utilidad de reporte comentada anteriormente: volcar a un fichero de texto las URLs localizadas por el motor de spidering en la fase de descubrimiento de recursos y utilizarlas en la FOCA para la búsqueda de vulnerabilidades en el servidor web, tal y como se podía hacer con las URLs de Burp. Las pruebas se realizarán con algunas de las sedes electrónicas de diversos ayuntamientos españoles.

Figura 9: Documento de la sede electrónica de uno de los ayuntamientos

Tras seleccionar el objetivo y enviar peticiones HTTP/S usando JxBrowser, capturamos las peticiones/respuestas de servidor web y ejecutamos el spider para que busque todos los activos en función del código que se vaya encontrando por las páginas que visita y exportamos las URL localizadas por el spider.

Figura 10: Exportación de URLs a un fichero de texto

Una vez generado el fichero con todas las URLs, lo utilizamos con FOCA para que ésta realice los escaneos oportunos en segundo plano en busca de vulnerabilidades web.

Figura 11: Importando en FOCA las URLs desde un fichero de texto

Una vez que la FOCA se pone a analizar las URLs, vemos como localiza diversas vulnerabilidades: Directory listing, métodos HTTP inseguros y la vulnerabilidad de ShortName presente en el IIS de ciertas versiones de Microsoft Server, y que permite que se listen los ficheros de las carpetas en formato 8:3 haciendo un ataque a ciegas, aún cuando el administrador del sitio haya configurado el servidor para que no se muestren los listados de directorios.

Figura 12: Diversas vulnerabilidades detectadas por FOCA

Analizando la URLs donde FOCA detecta Directory listing, podemos ver cosas tan curiosas como la posibilidad de subir un fichero de texto al sistema sin la necesidad de estar autenticado en la sede electrónica.

Figura 13: Subir un fichero a la sede electrónica sin estar autenticado

También es posible ver ficheros importantes de configuración de la sede electrónica, como el Web.config, ConfigWizard.xml, y algunos ficheros de las fases de prueba y de configuración.

Figura 14: Ficheros importantes de configuración de la sede electrónica

Figura 15: Ficheros .def con información sensible de la configuración

Figura 16: Más directorios con ficheros expuestos

Además, navegando por la URL, es posible llegar hasta el formulario de acceso a la sede electrónica.

Figura 17: Formulario de acceso a la sede electrónica

Si no se han tomado las medidas de protección adecuadas y alguno de los usuarios ha utilizado el mismo login y password, es posible acceder a la sede electrónica.

Figura 18: Acceso a la sede electrónica de un ayuntamiento

Autor: Amador Aparicio (@amadapa), autor del libro "Hacking Web Technologies"

PD: tanto el ayuntamiento como la empresa que ha programado la sede electrónica han sido informadas de estas vulnerabilidades.

4 comentarios:

  1. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  2. Excelente aporte!!! Muchas gracias.

    ResponderEliminar
  3. @Henry, gracias a ti! Un saludo!!

    ResponderEliminar
  4. Juanma Rodrigo, la transparencia en la cosa pública está bien. Ese ayuntamiento y los demás se mueven con dinero público, y los ciudadanos debemos tener derecho a saber en que, como y con que resultados invierten nuestros cuartos.
    Otra cosa es si fuese una empresa privada o una marca, donde estaría de acuerdo contigo.
    Saludos.

    ResponderEliminar