> 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/dockerlabs/facil/redirection.md).
# Redirection
## Introduccion
En este laboratorio de DockerLabs se trabaja una maquina centrada en vulnerabilidades de Open Redirect.
La parte web consiste en superar varios laboratorios de redireccion, primero con una redireccion abierta directa y despues abusando de validaciones debiles sobre el destino permitido. Al completar los retos se obtienen credenciales SSH para el usuario `balu`.
La escalada local encadena la lectura de un archivo sensible, el salto al usuario `balulito` y una regla `sudo` peligrosa sobre `/bin/cp`, que permite sobrescribir `/etc/passwd` y conseguir una shell como `root`.
***
## Reconocimiento
Comenzamos con un escaneo completo de puertos y versiones con Nmap:
```bash
nmap -sVC -Pn -n -p- 172.17.0.2
```
El escaneo muestra dos puertos abiertos:
| Puerto | Servicio | Version |
| ------ | -------- | -------------------------- |
| 22/tcp | SSH | OpenSSH 9.2p1 Debian |
| 80/tcp | HTTP | Apache httpd 2.4.62 Debian |
Al acceder al puerto 80 aparece el laboratorio principal de Open Redirect:
```
http://172.17.0.2/
```
La pagina indica que los niveles se encuentran en rutas como `/laboratorio1`, `/laboratorio2` y `/laboratorio3`.
***
## Laboratorio 1 - Open Redirect basico
El primer laboratorio muestra un enlace que redirige a otro sitio:
Interceptando la peticion se observa que el destino se controla mediante el parametro `url`:
```http
GET /laboratorio1/redirect.php?url=http://172.17.0.2/laboratorio2 HTTP/1.1
Host: 172.17.0.2
```
La respuesta devuelve una redireccion `302 Found` hacia el valor recibido:
```http
HTTP/1.1 302 Found
Location: http://172.17.0.2/laboratorio2
```
Esto confirma el primer fallo: la aplicacion toma el parametro `url` y lo usa directamente en la cabecera `Location`.
***
## Laboratorio 2 - Bypass con userinfo
El segundo laboratorio introduce una restriccion y solo deberia permitir redirecciones hacia Google:
Al probar una URL que no pasa la validacion, la aplicacion bloquea la redireccion:
```
Redireccion no permitida. Solo puedes redirigirte a Google.
```
La validacion es debil porque se puede abusar del formato `usuario@host` de las URLs. Si el filtro solo comprueba que la cadena empieza por `https://www.google.com`, acepta un valor como este:
```
https://www.google.com@www.amazon.es
```
En esa URL, `www.google.com` queda como parte de la seccion de usuario, mientras que el host real al que navega el navegador es `www.amazon.es`.
Revisando el enlace desde las herramientas del navegador se ve el payload usado:
```html
Ir a Google
```
Al pulsarlo, el navegador termina en Amazon:
***
## Laboratorio 3 - Validacion por dominio
En el tercer laboratorio se vuelve a revisar el enlace desde el inspector del navegador.
El destino configurado apunta a un subdominio de Google Workspace:
```html
Ir a Google
```
Al seguir la redireccion, el navegador llega a `workspace.google.com`:
Con los laboratorios completados, el boton final de la pagina principal permite obtener credenciales SSH para el usuario `balu`.
Credenciales obtenidas:
```
balu:balulero
```
***
## Acceso inicial
Se accede por SSH con las credenciales obtenidas:
```bash
ssh balu@172.17.0.2
```
Ya tenemos una shell como el usuario `balu`.
***
## Enumeracion local
Primero revisamos si `balu` puede ejecutar comandos con `sudo`:
```bash
sudo -l
```
El sistema indica que el usuario no tiene permisos de `sudo`. Tambien se buscan binarios SUID:
```bash
find / -perm -4000 -type f 2>/dev/null
```
No aparece una ruta clara de escalada por SUID, asi que se continua enumerando el sistema de archivos. En la raiz aparece un archivo interesante:
```bash
ls -la /
cat /secret.bak
```
El archivo contiene nuevas credenciales:
```
balulito:balulerochingon
```
Con esa password se cambia al usuario `balulito`:
```bash
su balulito
```
***
## Escalada de privilegios
Como `balulito`, se revisan los permisos de `sudo`:
```bash
sudo -l
```
El usuario puede ejecutar `/bin/cp` como cualquier usuario y sin password:
```
(ALL) NOPASSWD: /bin/cp
```
Esta configuracion es peligrosa porque permite sobrescribir archivos criticos del sistema. Se copia `/etc/passwd` al directorio actual, se edita la linea de `root` para dejarla sin hash de password y despues se reemplaza el archivo original usando `sudo /bin/cp`:
```bash
cp /etc/passwd .
nano passwd
sudo /bin/cp passwd /etc/passwd
```
Tras modificar `/etc/passwd`, se cambia a `root`:
```bash
su root
whoami
```
La maquina queda comprometida con una shell privilegiada.
***
## Resumen
La ruta completa de la maquina queda asi:
1. Escaneo con Nmap para detectar SSH y HTTP.
2. Acceso al laboratorio de Open Redirect en el puerto 80.
3. Abuso del parametro `url` en `/laboratorio1/redirect.php`.
4. Bypass de la restriccion del segundo laboratorio usando `https://www.google.com@www.amazon.es`.
5. Revision del tercer laboratorio y redireccion hacia `workspace.google.com`.
6. Obtencion de credenciales SSH para `balu`.
7. Acceso por SSH.
8. Lectura de `/secret.bak` para obtener `balulito:balulerochingon`.
9. Revision de permisos `sudo` de `balulito`.
10. Abuso de `sudo /bin/cp` para sobrescribir `/etc/passwd`.
11. Acceso final como `root`.
| Fase | Tecnica | Resultado |
| ------------------ | -------------------------- | ------------------------------ |
| Reconocimiento | Nmap | SSH y HTTP expuestos |
| Web | Open Redirect | Laboratorios completados |
| Bypass | URL userinfo con `@` | Redireccion a host externo |
| Credenciales | Recompensa del laboratorio | Usuario `balu` |
| Movimiento lateral | Lectura de `/secret.bak` | Usuario `balulito` |
| Escalada | `sudo /bin/cp` | Sobrescritura de `/etc/passwd` |
| Root | `su root` | Shell privilegiada |
### Recomendaciones
* Validar redirecciones con una allowlist estricta de hosts y esquemas.
* Parsear URLs con librerias seguras antes de comparar dominios.
* No usar comprobaciones por substring o `startsWith` para autorizar destinos.
* Evitar archivos sensibles legibles por usuarios no privilegiados.
* Revisar reglas `NOPASSWD` y no permitir binarios capaces de sobrescribir archivos criticos.
---
# 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/dockerlabs/facil/redirection.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.