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.
Este comentario ha sido eliminado por el autor.
ResponderEliminarExcelente aporte!!! Muchas gracias.
ResponderEliminar@Henry, gracias a ti! Un saludo!!
ResponderEliminarJuanma 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.
ResponderEliminarOtra cosa es si fuese una empresa privada o una marca, donde estaría de acuerdo contigo.
Saludos.