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.