nginx-rift-private-lab

Laboratorio privato Nginx Rift ASLR, catena di exploit e registrazioni demo

Vuoi trovare problemi come questo nel tuo codice? Prova lo stesso sistema su https://depthfirst.com/open-defense.

Il Bug (TL;DR)

Il motore di script di NGINX utilizza un processo a due passaggi: prima calcola la dimensione del buffer necessaria, poi copia i dati. Il flag is_args viene impostato sul motore principale quando una sostituzione di rewrite contiene ?, ma il passaggio di calcolo della lunghezza viene eseguito su un sotto-motore appena azzerato. Quindi:

• Passaggio della lunghezza vede is_args = 0 → restituisce la lunghezza grezza della cattura.
• Passaggio della copia vede is_args = 1 → chiama ngx_escape_uri con NGX_ESCAPE_ARGS, espandendo ogni byte escapabile a 3 byte.

La copia sovrascrive il buffer heap sottodimensionato con dati URI controllati dall'attaccante. Lo sfruttamento utilizza il feng shui dell'heap tra richieste per corrompere il puntatore cleanup di un ngx_pool_t adiacente (spruzzato tramite corpi POST, poiché i byte URI non possono contenere byte nulli), reindirizzandolo a un falso ngx_pool_cleanup_s che invoca system() alla distruzione del pool.

Leggi di più su questo bug nel nostro articolo tecnico.

Versioni Affette e Corrette

Avviso completo del fornitore: https://my.f5.com/manage/s/article/K000160932

Fork di Ricerca Privato: Catena di Lab Remota con ASLR Abilitato

Questo fork mantiene intatto il PoC di divulgazione originale, ma aggiunge un secondo percorso di ricerca focalizzato su una domanda più realistica:

Il bug può essere sfruttato contro una vera VM Linux x86_64 con ASLR abilitato, senza fare affidamento su offset Docker/lab hardcoded?

La risposta in questo fork di ricerca è sì, con importanti vincoli. Le catene funzionanti non disabilitano ASLR e non utilizzano gli indirizzi heap/libc hardcoded originali. Invece, derivano lo stato in esecuzione attraverso primitive accessibili via HTTP sulla stessa porta, quindi selezionano il target heap finale dai dati di divulgazione ottenuti da remoto.

Ci sono ora due percorsi di exploit con ASLR abilitato, con il percorso coreless trattato come il PoC corrente migliore:

• nginx_rifter.py: il punto di ingresso pulito, autonomo, integrato per valutazione ed exploit. Il suo metodo di exploit predefinito è ora la catena coreless /proc/<nginx-worker>/mem.
• nginx_rifter_core_v2_1.py: la versione legacy preservata di nginx_rifter.py guidata dal core. È utile per riprodurre il vecchio percorso di ricerca VM testato con crash-core, ma non è più il PoC preferito.
• tools/proc_mem_coreless_exploit.py: il precedente harness di ricerca coreless autonomo. La sua logica è stata integrata in nginx_rifter.py; lo strumento rimane per la riproduzione di esperimenti grezzi.

La topologia target è intenzionalmente sulla stessa porta:

• route vulnerabile: /api/...
• route PHP di lettura file locale: /lfi.php?file=...
• route hint phpinfo: /phpinfo.php
• connessione vittima HTTP/2: stesso listener nginx e stesso worker
• verifica della prova: lettura del marcatore di file tramite l'endpoint LFI PHP

L'attuale percorso coreless proc-mem esegue i seguenti passaggi ad alto livello:

1. Utilizza LFI PHP per leggere l'identità PHP, i file pid di nginx, le mappe /proc/<pid>/maps del worker nginx e il file libc mappato.
2. Analizza il libc target tramite LFI per calcolare l'indirizzo assoluto di system() per quel worker.
3. Invia il normale traffico di spray/probe di NGINX Rift mantenendo vivo lo stato del worker.
4. Legge gli intervalli mappati da /proc/<worker>/mem attraverso la primitiva di lettura file.
5. Scansiona la memoria live per strutture fake-cleanup marcate con nonce e candidati cleanup-pool.
6. Utilizza candidati finali limitati derivati dalla memoria live del worker, non offset di laboratorio hardcoded o core dump leggibili.
7. Verifica l'esecuzione del comando leggendo l'output del marcatore attraverso la primitiva di lettura file.

Il percorso legacy core-guided esegue una derivazione simile degli indirizzi di base, poi causa intenzionalmente il crash di un worker, legge il file core generato tramite LFI e analizza quel core per individuare slot fake-cleanup spruzzati. Questo è stato un utile ponte di ricerca, ma dipende dalla politica di core-dump e dai permessi del filesystem che sono meno comuni nelle installazioni predefinite.

Questo non è lo stesso della demo Docker deterministica originale. Il percorso VM x86_64 lascia ASLR Linux normale abilitato e ricalcola gli indirizzi specifici del processo ad ogni esecuzione. Il percorso Docker coreless lascia anch'esso ASLR abilitato e rimuove il requisito insolito di un core leggibile, ma dipende dal comportamento dei permessi di procfs che deve essere verificato per la classe di target.

Ambito e Avvertenze

Questo fork è un laboratorio di ricerca controllato. Le catene con ASLR abilitato si basano su condizioni forti che non sono ipotesi di produzione universali:

• PHP deve esporre una primitiva utile di lettura file locale.
• Per il percorso predefinito coreless proc-mem, PHP deve essere in grado di leggere le mappe /proc/<pid>/maps del worker nginx con lo stesso UID, il libc mappato e /proc/<pid>/mem a grandi offset mappati.
• Per il percorso legacy core-guided, PHP deve essere in grado di leggere le mappe /proc/<pid>/maps del worker nginx con lo stesso UID, il libc mappato e il core del worker generato.
• HTTP/2 è abilitato sullo stesso listener nginx per fornire il target di pulizia del connection-pool utilizzato dalla catena finale.

phpinfo() e /proc/<pid>/maps sono sufficienti per recuperare gli indirizzi di base PIE/libc, ma non sono sufficienti da soli per recuperare l'esatto oggetto/finestra heap necessari per questo exploit. La vecchia catena utilizzava un core dump leggibile per quella divulgazione finale. L'attuale catena predefinita utilizza /proc/<worker>/mem invece, che è più vicino a una conseguenza reale di lettura arbitraria di file in distribuzioni con lo stesso UID perché espone la memoria live del worker senza modificare la politica di core-dump.

Limiti importanti rimanenti:

• /proc/<pid>/mem è protetto da ptrace. Ha funzionato nel laboratorio Docker e in un controllo con lo stesso UID contro il modello di immagine ufficiale nginx:stable, ma i processi applicativi con UID diverso dovrebbero fallire con le protezioni predefinite di procfs.
• La primitiva di lettura file deve supportare grandi offset o un'API di intervallo equivalente.
• Un nuovo test su VM Ubuntu reale per il percorso proc-mem è ancora in sospeso.
• Non è stata trovata una perdita di memoria diretta nella risposta nginx senza LFI. Sonde passive di riflessione, reindirizzamento/intestazione/corpo, una scansione iniziale di over-read con proxy ritardato e una revisione del codice assistita da SSRF non hanno prodotto divulgazioni rilevanti per ASLR.

Strumentazione Corrente

Il punto di ingresso pulito corrente è nginx_rifter.py, uno strumento orientato alla valutazione, progettato per essere più vicino a come un tester autorizzato valuterebbe una distribuzione nginx nota vulnerabile con una primitiva di lettura file locale accessibile via HTTP.

Rispetto all'esecutore demo iniziale, nginx_rifter.py migliora il flusso di lavoro in diversi modi:

• La valutazione è l'impostazione predefinita. Non esegue l'exploit che causa il crash se non viene esplicitamente fornito --exploit.
• Il target è fornito come HOST:PORT e la primitiva di lettura file è modulare tramite --file-read-template.
• Profila la primitiva LFI prima di utilizzarla, incluse letture di testo, letture binarie, letture con intervallo, /proc/self/status, /proc/self/maps e la raggiungibilità procfs del worker con lo stesso UID.
• Scopre le mappe del worker nginx, libc, system(), build ID, hash binari, dettagli del sistema operativo e impostazioni proc-mem/core attraverso la primitiva remota.
• Tenta la scoperta della configurazione nginx dalla riga di comando del master e da percorsi di configurazione comuni, quindi segnala i candidati route vulnerabili rewrite + set.
• Stampa una matrice di fattibilità della catena di exploit in modo che i prerequisiti mancanti siano visibili prima di qualsiasi tentativo di exploit.
• La modalità exploit è esplicita e integrata in nginx_rifter.py; il metodo predefinito è coreless proc-mem.

L'attuale nginx_rifter.py è autonomo. Non importa né richiama versioni precedenti del PoC demo o tools/proc_mem_coreless_exploit.py per valutazione o sfruttamento.

La vecchia implementazione di nginx_rifter.py guidata dal core è conservata come nginx_rifter_core_v2_1.py.

La più recente artifacts/nginx_rifter_v3_coreless_exploit_20260519.gif mostra il percorso di exploit coreless v3 integrato di nginx_rifter.py. demo4.gif mostra il flusso di valutazione ed exploit esplicito della precedente strumentazione integrata guidata dal core. La precedente nginx-aslr-demo.gif rimane come demo originale dell'exploit con ASLR abilitato.

Utilizzo

Testato su Ubuntu 24.04.3 LTS.

Riproduzione originale con ASLR disabilitato su Docker:

1. ./setup.sh — costruisci il contenitore.
2. docker compose -f env/docker-compose.yml up — avvia il server NGINX vulnerabile.
3. python3 poc.py --shell — ottieni una shell.

Per il flusso di riproduzione locale Docker, consulta LAB.md.

Catena legacy con ASLR abilitato su VM guidata dal core:

Strumento v3 assessment-first:

nginx_rifter.py è il valutatore orientato al mondo reale e il punto di ingresso integrato del PoC. La sua modalità predefinita non esegue il percorso di exploit che causa il crash. Profila la primitiva di lettura file HTTP, controlla letture con intervallo e binarie, identifica OS/nginx/libc, scopre i worker nginx e le mappe rilevanti per ASLR, testa la leggibilità di /proc/<worker>/mem con lo stesso UID, tenta di recuperare i percorsi di configurazione nginx tramite letture pid/cmdline/config, segnala i candidati route vulnerabili rewrite + set e stampa una matrice di fattibilità per la catena coreless corrente.

L'attuale nginx_rifter.py è autonomo. Non importa né richiama versioni precedenti del PoC demo o dell'harness di ricerca proc-mem autonomo per valutazione o sfruttamento.

Per una forma personalizzata di LFI/download:

L'esecuzione dell'exploit è esplicita:

Il metodo di exploit predefinito è coreless proc-mem. Le seguenti opzioni sono già selezionate per impostazione predefinita perché erano le più affidabili per la prova Docker coreless:

La modalità legacy con core leggibile è ancora disponibile per confronto, ma lo script versionato è più chiaro per riprodurre quel vecchio percorso:

Demo terminale legacy adatta per registrazione:

demo_ctf_exploit_v1_9.py è il vecchio esecutore orientato all'operatore per il percorso di laboratorio guidato dal core. Il punto di ingresso PoC preferito corrente è nginx_rifter.py.

La primitiva di lettura file predefinita è la route PHP di questo fork:

Per un'applicazione CTF vulnerabile diversa o una piattaforma di test, il vettore di lettura file è modulare:

Il modello supporta {host}, {port}, {path_url}, {offset}, {length} e {range_query}. Il profilo generico salta le asserzioni di configurazione nginx specifiche di questo fork, ma l'exploit predefinito ha ancora bisogno delle stesse capacità sottostanti: mappe /proc del worker nginx leggibili, libc leggibile e /proc/<worker>/mem leggibile. phpinfo() è opzionale; usa --phpinfo-path '' per disabilitarlo.

Avvertenza sul realismo: la classe di bug LFI/lettura file e il modello di distribuzione nginx/PHP-FPM sullo stesso host sono realistici. La catena proc-mem è più realistica della precedente catena crash-core perché non richiede l'abilitazione o la lettura dei core dump del worker. Non è ancora un'ipotesi universale di produzione predefinita: il layout del processo con lo stesso UID, la politica procfs/Yama, le impostazioni dei namespace del contenitore e la qualità della primitiva di lettura file decidono se /proc/<worker>/mem è raggiungibile.

Sonde di ricerca senza LFI:

Queste sono sonde di ricerca negative, non punti di ingresso per exploit. Esercitano sink passivi riflessi e una forma iniziale di over-read con risposta ritardata senza utilizzare LFI, phpinfo, procfs, core, accesso al debugger o basi ASLR live hardcoded.

Note aggiuntive di laboratorio e log di esecuzione sono in docs/, in particolare:

• 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