> For the complete documentation index, see [llms.txt](https://itskode.gitbook.io/pentesting/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://itskode.gitbook.io/pentesting/bunkerlabs/muy_facil/clientbypass.md).
# ClientBypass
> **Dificultad:** Muy facil | **Servicio:** Web | **IP:** 172.17.0.2
***
## Introduccion
En este laboratorio de BunkerLabs se compromete una aplicacion web que implementa un flujo de login con MFA. La vulnerabilidad principal no esta en adivinar el codigo OTP, sino en confiar demasiado en la respuesta que recibe el navegador.
Tras iniciar sesion con las credenciales de demo, se intercepta la validacion del MFA con Burp Suite y se modifica la respuesta JSON del servidor para convertir un intento fallido en un resultado exitoso desde el punto de vista del cliente.
***
## Reconocimiento
Se comienza identificando los servicios expuestos con Nmap:
```bash
nmap -sVC -Pn -n -T4 172.17.0.2
```
El escaneo muestra un unico puerto abierto:
| Puerto | Servicio | Version |
| -------- | -------- | ------- |
| 8000/tcp | HTTP | uvicorn |
Nmap tambien detecta que el recurso principal redirige o apunta hacia:
```
/login
```
Por tanto, la enumeracion se centra en la aplicacion web del puerto `8000`.
***
## Login Web
Al acceder a la ruta `/login` aparece un formulario de autenticacion:
```
http://172.17.0.2:8000/login
```
La propia pagina muestra credenciales de demo:
```
admin:password123
```
Con estas credenciales se supera el primer paso de autenticacion, pero la aplicacion solicita un segundo factor.
***
## MFA
Despues del login se carga la ruta `/mfa`, donde se pide un codigo OTP:
Se prueba un codigo cualquiera para observar como valida la aplicacion:
```
111111
```
La peticion se captura con Burp Suite. El endpoint encargado de validar el codigo es:
```http
POST /api/verify-mfa HTTP/1.1
Host: 172.17.0.2:8000
```
En el cuerpo viaja el parametro `code`:
```
code=111111
```
La respuesta del servidor indica que el codigo es incorrecto:
El detalle importante esta en el JSON:
```json
{
"success": false,
"message": "Invalid MFA code"
}
```
Esto sugiere que el frontend decide si debe avanzar o no basandose en el valor de `success`.
***
## Bypass Desde El Cliente
Para comprobar si el control se puede manipular desde el cliente, se configura una regla de **Match and Replace** en Burp Suite sobre el cuerpo de la respuesta:
| Campo | Valor |
| ------- | ------------------ |
| Type | Response body |
| Match | `"success":false,` |
| Replace | `"success":true,` |
Con la regla activa, se vuelve a enviar un codigo OTP invalido. El servidor sigue rechazando el MFA, pero Burp modifica la respuesta antes de que llegue al navegador. De esta forma, el cliente interpreta la validacion como correcta.
La aplicacion redirige al dashboard:
Una vez dentro, se obtiene la flag:
```
OHGDS8FOG8
```
***
## Resumen
La ruta completa queda asi:
1. Escaneo con Nmap para identificar `uvicorn` en el puerto `8000`.
2. Acceso a `/login`.
3. Uso de credenciales de demo `admin:password123`.
4. Captura de la validacion MFA en Burp Suite.
5. Deteccion de la respuesta JSON con `"success": false`.
6. Creacion de una regla Match and Replace para cambiar la respuesta a `"success": true`.
7. Bypass del MFA desde el navegador.
8. Acceso al dashboard y obtencion de la flag.
***
## Recomendaciones
* No basar decisiones de autenticacion o autorizacion en valores que el cliente pueda modificar.
* Validar el MFA completamente en el servidor antes de crear una sesion privilegiada.
* Evitar exponer credenciales de demo en entornos accesibles.
* Hacer que el dashboard compruebe en servidor que el usuario tiene MFA validado, no solo que el navegador recibio un `success`.
* Registrar intentos fallidos de MFA y aplicar controles de rate limiting.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://itskode.gitbook.io/pentesting/bunkerlabs/muy_facil/clientbypass.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.