nginx-rift-private-lab

Laboratoire privé Nginx Rift ASLR, chaîne d'exploitation et enregistrements de démonstration

Vous voulez trouver des problèmes comme celui-ci dans votre propre code ? Essayez le même système sur https://depthfirst.com/open-defense.

Le bug (TL;DR)

Le moteur de script de NGINX utilise un processus en deux passes : d'abord calculer la taille de tampon requise, puis copier les données. Le drapeau is_args est défini sur le moteur principal lorsqu'un remplacement rewrite contient ?, mais la passe de calcul de longueur s'exécute sur un sous-moteur fraîchement remis à zéro. Donc :

• Passe de calcul de longueur voit is_args = 0 → renvoie la longueur de capture brute.
• Passe de copie voit is_args = 1 → appelle ngx_escape_uri avec NGX_ESCAPE_ARGS, en développant chaque octet échappable en 3 octets.

La copie fait déborder le tampon tas sous-dimensionné avec des données URI contrôlées par l'attaquant. L'exploitation utilise du heap feng shui inter-requêtes pour corrompre le pointeur cleanup d'un ngx_pool_t adjacent (sprayé via des corps de requêtes POST, car les octets d'URI ne peuvent pas contenir d'octets nuls), le redirigeant vers un faux ngx_pool_cleanup_s qui invoque system() lors de la destruction du pool.

En savoir plus sur ce bug dans notre analyse technique.

Versions concernées et corrigées

Avis de sécurité complet du fournisseur : https://my.f5.com/manage/s/article/K000160932

Fork de recherche privé : chaîne de laboratoire à distance avec ASLR activé

Ce fork conserve le PoC de divulgation original intact, mais ajoute une seconde piste de recherche axée sur une question plus réaliste :

Le bug peut-il être exploité contre une véritable VM Linux x86_64 avec ASLR activé, sans dépendre d'offsets Docker/lab codés en dur ?

La réponse dans ce fork de recherche est oui, avec d'importantes contraintes. Les chaînes fonctionnelles ne désactivent pas l'ASLR et n'utilisent pas les adresses tas/libc codées en dur d'origine. Elles dérivent plutôt l'état d'exécution via des primitives accessibles par HTTP sur le même port, puis sélectionnent la cible tas finale à partir des données de divulgation obtenues à distance.

Il existe désormais deux pistes d'exploitation avec ASLR activé, le chemin coreless étant considéré comme le meilleur PoC actuel :

• nginx_rifter.py : le point d'entrée propre et autonome pour l'évaluation et l'exploitation intégrée. Sa méthode d'exploitation par défaut est désormais la chaîne coreless /proc/<nginx-worker>/mem.
• nginx_rifter_core_v2_1.py : la version historique préservée de nginx_rifter.py, guidée par core. Elle est utile pour reproduire l'ancienne piste de recherche testée sur VM avec core de crash, mais elle n'est plus le PoC préféré.
• tools/proc_mem_coreless_exploit.py : l'ancien harnais de recherche coreless autonome. Sa logique a été fusionnée dans nginx_rifter.py ; l'outil reste disponible pour rejouer des expériences brutes.

La topologie cible est volontairement sur le même port :

• route vulnérable : /api/...
• route PHP de lecture de fichier locale : /lfi.php?file=...
• route d'indice phpinfo : /phpinfo.php
• connexion victime HTTP/2 : même écouteur et même worker nginx
• vérification de la preuve : fichier marqueur relu via le point de terminaison LFI PHP

Le chemin proc-mem coreless actuel effectue les étapes de haut niveau suivantes :

1. Utilise le LFI PHP pour lire l'identité PHP, les fichiers pid de nginx, les /proc/<pid>/maps du worker nginx et le fichier libc mappé.
2. Analyse la libc cible via LFI pour calculer l'adresse absolue de system() pour ce worker.
3. Envoie le trafic normal de spray/sondage NGINX Rift tout en maintenant l'état du worker vivant.
4. Lit les plages mappées depuis /proc/<worker>/mem via la primitive de lecture de fichier.
5. Analyse la mémoire vive à la recherche de structures de faux-cleanup marquées par nonce et de candidats de pools de cleanup.
6. Utilise des candidats finaux bornés dérivés de la mémoire vive du worker, et non des offsets de laboratoire codés en dur ou des cores de crash lisibles.
7. Vérifie l'exécution de commandes en lisant la sortie du marqueur via la primitive de lecture de fichier.

Le chemin historique guidé par core effectue une dérivation d'adresse de base similaire, puis fait intentionnellement planter un worker, lit le fichier core généré via LFI et fouille ce core pour y trouver les emplacements de faux-cleanup sprayés. C'était un pont de recherche utile, mais il dépend de la politique de core dump et des permissions du système de fichiers, qui sont moins courantes dans les déploiements par défaut.

Ce n'est pas la même chose que la démo Docker déterministe d'origine. Le chemin VM x86_64 laisse l'ASLR Linux normal activé et recalcule les adresses spécifiques au processus à chaque exécution. Le chemin coreless Docker laisse également l'ASLR activé et supprime l'exigence inhabituelle de core lisible, mais il dépend du comportement des permissions procfs qui doit être vérifié pour la classe de cible.

Portée et mises en garde

Ce fork est un laboratoire de recherche contrôlé. Les chaînes avec ASLR activé reposent sur des conditions fortes qui ne sont pas des hypothèses de production universelles :

• PHP doit exposer une primitive utile de lecture de fichier locale.
• Pour le chemin coreless proc-mem par défaut, PHP doit pouvoir lire les /proc/<pid>/maps du worker nginx avec le même UID, la libc mappée et /proc/<pid>/mem à de grands offsets mappés.
• Pour le chemin historique guidé par core, PHP doit pouvoir lire les /proc/<pid>/maps du worker nginx avec le même UID, la libc mappée et le core du worker généré.
• HTTP/2 est activé sur le même écouteur nginx pour fournir la cible de cleanup du pool de connexions utilisée par la chaîne finale.

phpinfo() et /proc/<pid>/maps suffisent pour retrouver les adresses de base PIE/libc, mais ne suffisent pas à eux seuls pour retrouver l'objet/fenêtre tas exact nécessaire à cette exploitation. L'ancienne chaîne utilisait un core de crash lisible pour cette divulgation finale. La chaîne par défaut actuelle utilise /proc/<worker>/mem à la place, ce qui est plus proche d'une conséquence réelle de lecture arbitraire de fichier dans les déploiements avec même UID, car cela expose la mémoire vive du worker sans modifier la politique de core dump.

Limites importantes restantes :

• /proc/<pid>/mem est protégé par ptrace. Cela a fonctionné dans le lab Docker et lors d'un contrôle avec même UID contre le modèle d'image officiel nginx:stable, mais les processus d'application avec un UID différent devraient échouer sous les protections procfs par défaut.
• La primitive de lecture de fichier doit prendre en charge de grands offsets ou une API d'intervalle équivalente.
• Un nouveau test sur une véritable VM Ubuntu pour le chemin proc-mem est toujours en attente.
• Aucune fuite mémoire directe dans les réponses nginx sans LFI n'a été trouvée. Les sondes de réflexion passive, de redirection/en-tête/corps, un balayage initial de sur-lecture via proxy différé et une revue de code assistée par SSRF n'ont produit aucune divulgation pertinente pour l'ASLR.

Outillage actuel

Le point d'entrée propre actuel est nginx_rifter.py, un outil orienté évaluation d'abord, conçu pour se rapprocher de la manière dont un testeur autorisé évaluerait un déploiement nginx vulnérable connu avec une primitive de lecture de fichier locale accessible par HTTP.

Par rapport au lanceur de démo initial, nginx_rifter.py améliore le flux de travail de plusieurs manières :

• L'évaluation est le comportement par défaut. Il n'exécute pas l'exploit qui fait planter le service sauf si --exploit est explicitement fourni.
• La cible est fournie sous la forme HOST:PORT, et la primitive de lecture de fichier est modulaire via --file-read-template.
• Il profile la primitive LFI avant de s'y fier, notamment les lectures texte, les lectures binaires, les lectures par plage, /proc/self/status, /proc/self/maps et l'accessibilité procfs des workers avec le même UID.
• Il découvre les maps des workers nginx, la libc, system(), les build IDs, les empreintes binaires, les détails du système d'exploitation et les paramètres proc-mem/core via la primitive distante.
• Il tente de découvrir la configuration nginx à partir de la ligne de commande du processus maître et des chemins de configuration courants, puis signale les candidats de routes vulnérables rewrite + set.
• Il affiche une matrice de viabilité de la chaîne d'exploitation afin que les prérequis manquants soient visibles avant toute tentative d'exploitation.
• Le mode exploitation est explicite et intégré dans nginx_rifter.py ; la méthode par défaut est coreless proc-mem.

Le nginx_rifter.py actuel est autonome. Il n'importe plus et n'appelle plus les versions précédentes du PoC de démo ni tools/proc_mem_coreless_exploit.py pour l'évaluation ou l'exploitation.

L'ancienne implémentation de nginx_rifter.py guidée par core est préservée sous le nom nginx_rifter_core_v2_1.py.

Le nouveau artifacts/nginx_rifter_v3_coreless_exploit_20260519.gif montre le chemin d'exploitation coreless fusionné du v3 nginx_rifter.py. demo4.gif montre le flux d'évaluation et d'exploitation explicite de l'ancien outillage tout-en-un guidé par core. L'ancien nginx-aslr-demo.gif reste la démo d'exploitation d'origine avec ASLR activé.

Utilisation

Testé sur Ubuntu 24.04.3 LTS.

Reproduction Docker d'origine avec ASLR désactivé :

1. ./setup.sh — construit le conteneur.
2. docker compose -f env/docker-compose.yml up — démarre le serveur NGINX vulnérable.
3. python3 poc.py --shell — ouvre un shell.

Pour le flux de reproduction Docker local, voir LAB.md.

Chaîne historique guidée par core sur VM avec ASLR activé :

Outil v3 orienté évaluation d'abord :

nginx_rifter.py est le point d'entrée actuel orienté monde réel pour l'évaluation et le PoC intégré. Son mode par défaut n'exécute pas le chemin d'exploitation qui fait planter le service. Il profile la primitive de lecture de fichier HTTP, vérifie les lectures par plage et binaires, identifie l'OS/nginx/libc, découvre les workers nginx et les maps pertinentes pour l'ASLR, teste la lisibilité de /proc/<worker>/mem avec le même UID, tente de récupérer les chemins de configuration nginx via les lectures pid/cmdline/config, signale les candidats de routes vulnérables rewrite + set et affiche une matrice de viabilité pour la chaîne coreless actuelle.

Le nginx_rifter.py actuel est autonome. Il n'importe plus et n'appelle plus les versions précédentes du PoC de démo ni le harnais de recherche proc-mem autonome pour l'évaluation ou l'exploitation.

Pour une forme LFI/téléchargement personnalisée :

L'exécution de l'exploit est explicite :

La méthode d'exploitation par défaut est coreless proc-mem. Les options suivantes sont déjà sélectionnées par défaut car elles étaient les plus fiables pour la preuve coreless Docker :

Le mode historique avec core lisible est toujours disponible pour comparaison, mais le script versionné est plus clair pour reproduire cet ancien chemin :

Démo terminal historique adaptée à l'enregistrement :

demo_ctf_exploit_v1_9.py est l'ancien exécutable orienté opérateur pour le chemin de laboratoire guidé par core. Le point d'entrée PoC actuellement préféré est nginx_rifter.py.

La primitive de lecture de fichier par défaut est la route PHP de ce fork :

Pour une application CTF vulnérable connue différente ou une plateforme de test, le vecteur de lecture de fichier est modulaire :

Le modèle prend en charge {host}, {port}, {path_url}, {offset}, {length} et {range_query}. Le profil générique ignore les assertions de configuration nginx spécifiques au laboratoire de ce fork, mais l'exploit par défaut nécessite toujours les mêmes capacités sous-jacentes : maps /proc lisibles du worker nginx, libc lisible et /proc/<worker>/mem lisible. phpinfo() est facultatif ; utilisez --phpinfo-path '' pour le désactiver.

Avertissement sur le réalisme : la classe de bugs LFI/lecture de fichier et le modèle de déploiement nginx/PHP-FPM sur le même hôte sont réalistes. La chaîne proc-mem est plus réaliste que l'ancienne chaîne crash-core car elle ne nécessite ni d'activer ni de lire les core dumps des workers. Elle ne constitue toujours pas une hypothèse universelle de production : la disposition des processus avec le même UID, la politique procfs/Yama, les paramètres d'espace de noms du conteneur et la qualité de la primitive de lecture de fichier déterminent si /proc/<worker>/mem est accessible.

Sondes de recherche sans LFI :

Ce sont des sondes de recherche négatives, pas des points d'entrée d'exploitation. Elles exercent des sinks de réflexion passive et une forme initiale de sur-lecture à réponse différée, sans utiliser LFI, phpinfo, procfs, cores, accès au débogueur ni bases ASLR dynamiques codées en dur.

Des notes de laboratoire supplémentaires et des journaux d'exécution se trouvent dans docs/, notamment :

• docs/CTF_PLAN.md
• docs/CTF_FINDINGS.md
• docs/CTF_TESTS.md
• docs/CTF_EXPERIMENT_LOG.md
• docs/DEMO_POC_IMPROVEMENTS.md
• docs/KNOWN_LAYOUT_PATTERNS.md
• docs/VAGRANT_ESXI.md
• docs/CORELESS_ASLR_PLAN.md
• docs/CORELESS_ASLR_FINDINGS.md
• docs/NON_LFI_ASLR_BYPASS_LOG.md
• docs/DEMO_RECORDING_WORKFLOW.md