Nginx
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ottieni la prospettiva di un hacker sulle tue app web, rete e cloud
Trova e segnala vulnerabilità critiche e sfruttabili con un reale impatto sul business. Usa i nostri oltre 20 strumenti personalizzati per mappare la superficie di attacco, trovare problemi di sicurezza che ti permettano di elevare i privilegi e utilizzare exploit automatizzati per raccogliere prove essenziali, trasformando il tuo duro lavoro in report persuasivi.
Quando si configura il server Nginx, la direttiva root gioca un ruolo critico definendo la directory di base da cui vengono serviti i file. Considera l'esempio qui sotto:
In questa configurazione, /etc/nginx è designato come la directory radice. Questa impostazione consente l'accesso ai file all'interno della directory radice specificata, come /hello.txt. Tuttavia, è fondamentale notare che è definita solo una posizione specifica (/hello.txt). Non c'è configurazione per la posizione radice (location / {...}). Questa omissione significa che la direttiva root si applica globalmente, consentendo le richieste al percorso radice / di accedere ai file sotto /etc/nginx.
Una considerazione critica per la sicurezza deriva da questa configurazione. Una semplice richiesta GET, come GET /nginx.conf, potrebbe esporre informazioni sensibili servendo il file di configurazione di Nginx situato in /etc/nginx/nginx.conf. Impostare la root su una directory meno sensibile, come /etc, potrebbe mitigare questo rischio, ma potrebbe comunque consentire accessi non intenzionali ad altri file critici, inclusi altri file di configurazione, log di accesso e persino credenziali crittografate utilizzate per l'autenticazione di base HTTP.
Nei file di configurazione di Nginx, è necessaria un'attenta ispezione per le direttive "location". Una vulnerabilità nota come Local File Inclusion (LFI) può essere introdotta involontariamente attraverso una configurazione che somiglia alla seguente:
Questa configurazione è soggetta ad attacchi LFI a causa del server che interpreta richieste come /imgs../flag.txt come un tentativo di accedere a file al di fuori della directory prevista, risolvendo effettivamente a /path/images/../flag.txt. Questo difetto consente agli attaccanti di recuperare file dal filesystem del server che non dovrebbero essere accessibili tramite il web.
Per mitigare questa vulnerabilità, la configurazione dovrebbe essere regolata per:
Maggiore info: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/
Test di Accunetix:
Controlla la seguente pagina per imparare come bypassare direttive come:
Variabili vulnerabili $uri e $document_uri e questo può essere risolto sostituendole con $request_uri.
Una regex può anche essere vulnerabile come:
location ~ /docs/([^/])? { … $1 … } - Vulnerabile
location ~ /docs/([^/\s])? { … $1 … } - Non vulnerabile (controllo degli spazi)
location ~ /docs/(.*)? { … $1 … } - Non vulnerabile
Una vulnerabilità nella configurazione di Nginx è dimostrata dall'esempio seguente:
I caratteri \r (Carriage Return) e \n (Line Feed) significano caratteri di nuova linea nelle richieste HTTP, e le loro forme codificate in URL sono rappresentate come %0d%0a. Includere questi caratteri in una richiesta (ad esempio, http://localhost/%0d%0aDetectify:%20clrf) a un server mal configurato porta il server a emettere un nuovo header chiamato Detectify. Questo accade perché la variabile $uri decodifica i caratteri di nuova linea codificati in URL, portando a un header imprevisto nella risposta:
Learn more about the risks of CRLF injection and response splitting at https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.
Also this technique is explained in this talk with some vulnerable examples and dectection mechanisms. For example, In order to detect this misconfiguration from a blackbox perspective you could these requests:
https://example.com/%20X - Qualsiasi codice HTTP
https://example.com/%20H - 400 Bad Request
If vulnerable, the first will return as "X" is any HTTP method and the second will return an error as H is not a valid method. So the server will receive something like: GET / H HTTP/1.1 and this will trigger the error.
Another detection examples would be:
http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Qualsiasi codice HTTP
http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Bad Request
Some found vulnerable configurations presented in that talk were:
Note how $uri is set as is in the final URL
Nota come di nuovo $uri è nell'URL (questa volta all'interno di un parametro)
Ora in AWS S3
È stato scoperto che i dati forniti dall'utente potrebbero essere trattati come una variabile Nginx in determinate circostanze. La causa di questo comportamento rimane piuttosto elusiva, eppure non è né rara né semplice da verificare. Questa anomalia è stata evidenziata in un rapporto di sicurezza su HackerOne, che può essere visualizzato qui. Ulteriori indagini sul messaggio di errore hanno portato all'identificazione della sua occorrenza all'interno del modulo di filtro SSI del codice di Nginx, individuando gli Server Side Includes (SSI) come causa principale.
Per rilevare questa misconfigurazione, è possibile eseguire il seguente comando, che prevede l'impostazione di un'intestazione referer per testare la stampa delle variabili:
Scans per questa misconfigurazione su sistemi hanno rivelato più istanze in cui le variabili Nginx potevano essere stampate da un utente. Tuttavia, una diminuzione del numero di istanze vulnerabili suggerisce che gli sforzi per correggere questo problema sono stati in qualche modo efficaci.
Nginx offre una funzionalità tramite proxy_pass che consente l'intercettazione di errori e intestazioni HTTP prodotte dal backend, con l'obiettivo di nascondere messaggi di errore e intestazioni interni. Questo viene realizzato da Nginx servendo pagine di errore personalizzate in risposta agli errori del backend. Tuttavia, sorgono sfide quando Nginx incontra una richiesta HTTP non valida. Tale richiesta viene inoltrata al backend così com'è, e la risposta grezza del backend viene quindi inviata direttamente al client senza l'intervento di Nginx.
Considera uno scenario esemplificativo che coinvolge un'applicazione uWSGI:
Per gestire questo, vengono utilizzate direttive specifiche nella configurazione di Nginx:
proxy_intercept_errors: Questa direttiva consente a Nginx di servire una risposta personalizzata per le risposte del backend con un codice di stato superiore a 300. Garantisce che, per il nostro esempio di applicazione uWSGI, una risposta 500 Error venga intercettata e gestita da Nginx.
proxy_hide_header: Come suggerisce il nome, questa direttiva nasconde gli header HTTP specificati dal client, migliorando la privacy e la sicurezza.
Quando viene effettuata una richiesta GET valida, Nginx la elabora normalmente, restituendo una risposta di errore standard senza rivelare alcun header segreto. Tuttavia, una richiesta HTTP non valida bypassa questo meccanismo, risultando nell'esposizione delle risposte raw del backend, inclusi header segreti e messaggi di errore.
Per impostazione predefinita, la direttiva merge_slashes di Nginx è impostata su on, che comprime più barre oblique in un URL in una singola barra. Questa funzionalità, pur semplificando l'elaborazione degli URL, può inavvertitamente nascondere vulnerabilità nelle applicazioni dietro Nginx, in particolare quelle soggette ad attacchi di inclusione di file locali (LFI). Gli esperti di sicurezza Danny Robinson e Rotem Bar hanno evidenziato i potenziali rischi associati a questo comportamento predefinito, specialmente quando Nginx funge da reverse-proxy.
Per mitigare tali rischi, si raccomanda di disattivare la direttiva merge_slashes per le applicazioni suscettibili a queste vulnerabilità. Questo garantisce che Nginx inoltri le richieste all'applicazione senza alterare la struttura dell'URL, evitando così di mascherare eventuali problemi di sicurezza sottostanti.
Per ulteriori informazioni, controlla Danny Robinson e Rotem Bar.
Come mostrato in questo writeup, ci sono alcune intestazioni che, se presenti nella risposta del server web, cambieranno il comportamento del proxy Nginx. Puoi controllarle nei documenti:
X-Accel-Redirect: Indica a Nginx di reindirizzare internamente una richiesta a una posizione specificata.
X-Accel-Buffering: Controlla se Nginx deve bufferizzare la risposta o meno.
X-Accel-Charset: Imposta il set di caratteri per la risposta quando si utilizza X-Accel-Redirect.
X-Accel-Expires: Imposta il tempo di scadenza per la risposta quando si utilizza X-Accel-Redirect.
X-Accel-Limit-Rate: Limita il tasso di trasferimento per le risposte quando si utilizza X-Accel-Redirect.
Ad esempio, l'intestazione X-Accel-Redirect causerà un reindirizzamento interno in nginx. Quindi avere una configurazione nginx con qualcosa come root / e una risposta dal server web con X-Accel-Redirect: .env farà sì che nginx invii il contenuto di /.env (Path Traversal).
Nella configurazione di Nginx, la direttiva map gioca spesso un ruolo nel controllo dell'autorizzazione. Un errore comune è non specificare un valore predefinito, il che potrebbe portare a accessi non autorizzati. Ad esempio:
Senza un default, un utente malintenzionato può eludere la sicurezza accedendo a un URI non definito all'interno di /map-poc. Il manuale di Nginx consiglia di impostare un valore predefinito per evitare tali problemi.
Lo spoofing DNS contro Nginx è fattibile in determinate condizioni. Se un attaccante conosce il server DNS utilizzato da Nginx e può intercettare le sue query DNS, può falsificare i record DNS. Questo metodo, tuttavia, è inefficace se Nginx è configurato per utilizzare localhost (127.0.0.1) per la risoluzione DNS. Nginx consente di specificare un server DNS come segue:
proxy_pass e Direttive internalLa direttiva proxy_pass è utilizzata per reindirizzare le richieste ad altri server, sia internamente che esternamente. La direttiva internal garantisce che determinate posizioni siano accessibili solo all'interno di Nginx. Anche se queste direttive non sono vulnerabilità di per sé, la loro configurazione richiede un'attenta esaminazione per prevenire lacune di sicurezza.
Se il server nginx è configurato per passare le intestazioni Upgrade e Connection, un attacco h2c Smuggling potrebbe essere eseguito per accedere a endpoint protetti/interni.
Questa vulnerabilità consentirebbe a un attaccante di stabilire una connessione diretta con l'endpoint proxy_pass (http://backend:9999 in questo caso) il cui contenuto non verrà controllato da nginx.
Esempio di configurazione vulnerabile per rubare /flag da qui:
Nota che anche se il proxy_pass puntava a un percorso specifico come http://backend:9999/socket.io, la connessione sarà stabilita con http://backend:9999, quindi puoi contattare qualsiasi altro percorso all'interno di quel punto finale interno. Quindi non importa se un percorso è specificato nell'URL di proxy_pass.
Detectify ha creato un repository GitHub dove puoi utilizzare Docker per impostare il tuo server di test Nginx vulnerabile con alcune delle configurazioni errate discusse in questo articolo e provare a trovarle tu stesso!
https://github.com/detectify/vulnerable-nginx
Gixy è uno strumento per analizzare la configurazione di Nginx. L'obiettivo principale di Gixy è prevenire la misconfigurazione della sicurezza e automatizzare il rilevamento dei difetti.
Nginxpwner è uno strumento semplice per cercare comuni misconfigurazioni e vulnerabilità di Nginx.
Ottieni la prospettiva di un hacker sulle tue app web, rete e cloud
Trova e segnala vulnerabilità critiche ed esploitabili con un reale impatto commerciale. Usa i nostri oltre 20 strumenti personalizzati per mappare la superficie di attacco, trovare problemi di sicurezza che ti consentono di elevare i privilegi e utilizzare exploit automatizzati per raccogliere prove essenziali, trasformando il tuo duro lavoro in report persuasivi.
Impara e pratica l'Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica l'Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
