Bypass de autenticación
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
La explotación de vulnerabilidades de HTTP Verb Tampering suele ser un proceso relativamente sencillo. Solo tenemos que probar métodos HTTP alternativos para ver cómo los gestionan el servidor web y la aplicación web.
Aunque muchas herramientas de análisis de vulnerabilidades automatizadas pueden identificar de forma consistente vulnerabilidades de HTTP Verb Tampering provocadas por configuraciones de servidor inseguras, normalmente no identifican vulnerabilidades de HTTP Verb Tampering provocadas por una codificación insegura. Esto se debe a que el primer tipo se puede identificar fácilmente una vez que pasamos por alto una página de autenticación, mientras que el otro necesita pruebas activas para ver si podemos pasar por alto los filtros de seguridad establecidos.
El primer tipo de vulnerabilidad de HTTP Verb Tampering es causado principalmente por configuraciones inseguras de servidores web, y explotar esta vulnerabilidad puede permitirnos eludir el mensaje de autenticación básica HTTP en ciertas páginas.
En el ejemplo de esta sección tenemos una aplicación web básica File Manager, en la que podemos agregar nuevos archivos escribiendo sus nombres y pulsando enter:
Sin embargo, supongamos que intentamos eliminar todos los archivos haciendo clic en el botón rojo Reset. En ese caso, vemos que esta función parece estar restringida únicamente a los usuarios autenticados, ya que aparece el siguiente mensaje: HTTP Basic Auth
Como no tenemos ninguna credencial nos aparecerá una página 401 Unauthorized:
Entonces, veamos si podemos evitar esto con un ataque de HTTP Verb Tampering. Para ello, necesitamos identificar qué páginas están restringidas por esta autenticación. Si examinamos la solicitud HTTP después de hacer clic en el botón Reset o miramos la URL a la que nos lleva el botón después de hacer clic en él, vemos que está en /admin/reset.php. Por lo tanto, o bien el directorio /admin está restringido solo a usuarios autenticados, o solo lo está la página /admin/reset.php. Podemos confirmarlo visitando el directorio /admin y, de hecho, se nos solicita que iniciemos sesión nuevamente. Esto significa que el directorio /admin completo está restringido.
Para intentar explotar la página, necesitamos identificar el método de solicitud HTTP que utiliza la aplicación web. Podemos interceptar la solicitud en Burp Suite y examinarla:
Como la página utiliza una solicitud GET, podemos enviar una solicitud POST y ver si la página web permite solicitudes POST (es decir, si la autenticación cubre las solicitudes POST). Para ello, podemos hacer clic derecho en la solicitud interceptada en Burp y seleccionar Change Request Method, y automáticamente cambiará la solicitud a una solicitud POST:
Una vez que lo hagamos, podemos hacer clic Forward y examinar la página en nuestro navegador. Lamentablemente, aún se nos solicita que iniciemos sesión y accederemos a una página 401 Unauthorized si no proporcionamos las credenciales:
Entonces, parece que las configuraciones del servidor web cubren tanto las solicitudes GET como las solicitudes POST. Sin embargo, como hemos aprendido anteriormente, podemos utilizar muchos otros métodos HTTP, en particular el método HEAD , que es idéntico a una solicitud GET pero no devuelve el cuerpo en la respuesta HTTP. Si esto tiene éxito, es posible que no recibamos ningún resultado, pero la función reset debería ejecutarse de todos modos, que es nuestro objetivo principal.
Para ver si el servidor acepta solicitudes HEAD, podemos enviarle una solicitud OPTIONS y ver qué métodos HTTP se aceptan, de la siguiente manera:
Como podemos ver, la respuesta muestra Allow: POST,OPTIONS,HEAD,GET, lo que significa que el servidor web acepta solicitudes HEAD, que es la configuración predeterminada para muchos servidores web. Por lo tanto, intentemos interceptar la solicitud reset nuevamente y, esta vez, usemos una solicitud HEAD para ver cómo la maneja el servidor web:
Una vez que cambiamos POST a HEAD y reenviamos la solicitud, veremos que ya no obtenemos un mensaje de inicio de sesión ni una página 401 Unauthorized, sino una salida vacía, como se espera con una solicitud HEAD. Si volvemos a la aplicación web File Manager, veremos que todos los archivos se han eliminado, lo que significa que activamos correctamente la funcionalidad Reset sin tener acceso de administrador ni credenciales:
Intente probar otros métodos HTTP y vea cuáles pueden eludir con éxito la solicitud de autenticación.
Intenta usar lo que aprendiste en esta sección para acceder a la página 'reset.php' y eliminar todos los archivos. Una vez que se hayan eliminado todos los archivos, deberías obtener la flag.
Al acceder por el navegador llegamos al File Manager:
Si intentamos resetear los elementos nos salta la ventana de login y nos redirige a /admin/reset.php:
No nos da ningún método alternativo válido. Al probar con POST nos devuelve una flag:
