# Nginx
Impara l'hacking AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)! Altri modi per supportare HackTricks: * Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)! * Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com) * Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family) * **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
**Configurazione istantanea disponibile per valutazione delle vulnerabilità e test di penetrazione**. Esegui un pentest completo da qualsiasi luogo con oltre 20 strumenti e funzionalità che vanno dalla ricognizione alla segnalazione. Non sostituiamo i pentester - sviluppiamo strumenti personalizzati, moduli di rilevamento ed exploit per dare loro più tempo per approfondire, aprire shell e divertirsi. {% embed url="https://pentest-tools.com/" %} ## Missing root location ## **Essenziali per la configurazione della directory radice di Nginx** Quando si configura il server Nginx, la **direttiva root** svolge un ruolo critico definendo la directory di base da cui vengono serviti i file. Considera l'esempio seguente: ```bash server { root /etc/nginx; location /hello.txt { try_files $uri $uri/ =404; proxy_pass http://127.0.0.1:8080/; } } ``` In questa configurazione, `/etc/nginx` è designato come directory principale. Questo setup permette l'accesso ai file all'interno della directory principale specificata, come `/hello.txt`. Tuttavia, è fondamentale notare che è definita solo una specifica posizione (`/hello.txt`). Non c'è una configurazione per la posizione principale (`location / {...}`). Questa omissione significa che la direttiva principale si applica globalmente, consentendo alle richieste del percorso principale `/` di accedere ai file sotto `/etc/nginx`. Da questa configurazione sorge una considerazione critica per la sicurezza. 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 directory principale su una directory meno sensibile, come `/etc`, potrebbe mitigare questo rischio, ma potrebbe comunque consentire l'accesso non intenzionale ad altri file critici, inclusi altri file di configurazione, registri di accesso e persino credenziali crittografate utilizzate per l'autenticazione di base HTTP. ## Configurazione Errata di Alias LFI Nei file di configurazione di Nginx, è necessaria un'ispezione attenta delle direttive "location". Una vulnerabilità nota come Inclusione Locale di File (LFI) può essere introdotta involontariamente attraverso una configurazione che assomiglia a quanto segue: ``` location /imgs { alias /path/images/; } ``` Questo tipo di configurazione è vulnerabile agli attacchi LFI poiché il server interpreta le richieste come `/imgs../flag.txt` come un tentativo di accedere a file al di fuori della directory prevista, risolvendo effettivamente in `/percorso/immagini/../flag.txt`. Questa falla 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 in: ``` location /imgs/ { alias /path/images/; } ``` Ulteriori informazioni: [https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/](https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/) Test di Acunetix: ``` alias../ => HTTP status code 403 alias.../ => HTTP status code 404 alias../../ => HTTP status code 403 alias../../../../../../../../../../../ => HTTP status code 400 alias../ => HTTP status code 403 ``` ## Restrizione del percorso non sicura Controlla la seguente pagina per imparare come aggirare direttive come: ```plaintext location = /admin { deny all; } location = /admin/ { deny all; } ``` ## Uso non sicuro delle variabili / Divisione della richiesta HTTP {% hint style="danger" %} Le variabili vulnerabili `$uri` e `$document_uri` possono essere risolte sostituendole con `$request_uri`. Anche una regex può essere vulnerabile come: `location ~ /docs/([^/])? { … $1 … }` - Vulnerabile `location ~ /docs/([^/\s])? { … $1 … }` - Non vulnerabile (controlla gli spazi) `location ~ /docs/(.*)? { … $1 … }` - Non vulnerabile {% endhint %} Una vulnerabilità nella configurazione di Nginx è dimostrata dall'esempio seguente: ``` location / { return 302 https://example.com$uri; } ``` I caratteri \r (Carriage Return) e \n (Line Feed) indicano i caratteri di nuova riga nelle richieste HTTP, e le loro forme URL-encoded sono rappresentate come `%0d%0a`. Includere questi caratteri in una richiesta (ad esempio, `http://localhost/%0d%0aDetectify:%20clrf`) a un server configurato in modo errato porta il server a emettere un nuovo header chiamato `Detectify`. Questo avviene perché la variabile $uri decodifica i caratteri di nuova riga URL-encoded, portando a un header inaspettato nella risposta: ``` HTTP/1.1 302 Moved Temporarily Server: nginx/1.19.3 Content-Type: text/html Content-Length: 145 Connection: keep-alive Location: https://example.com/ Detectify: clrf ``` Scopri di più sui rischi dell'iniezione di CRLF e della divisione delle risposte a [https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/](https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/). Questa tecnica è anche **spiegata in questa presentazione** con alcuni esempi vulnerabili e meccanismi di rilevamento. Ad esempio, per rilevare questa errata configurazione da una prospettiva blackbox, potresti utilizzare queste richieste: - `https://example.com/%20X` - Qualsiasi codice HTTP - `https://example.com/%20H` - 400 Bad Request Se vulnerabile, il primo restituirà "X" poiché è un metodo HTTP qualsiasi e il secondo restituirà un errore poiché H non è un metodo valido. Quindi il server riceverà qualcosa del genere: `GET / H HTTP/1.1` e questo attiverà l'errore. Altri esempi di rilevamento sarebbero: - `http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x` - Qualsiasi codice HTTP - `http://company.tld/%20HTTP/1.1%0D%0AHost:%20x` - 400 Bad Request Alcune configurazioni vulnerabili trovate presentate in quella presentazione erano: - Nota come **`$uri`** sia impostato così com'è nell'URL finale ``` location ^~ /lite/api/ { proxy_pass http://lite-backend$uri$is_args$args; } ``` * Notare come di nuovo **`$uri`** sia presente nell'URL (questa volta all'interno di un parametro) ``` location ~ ^/dna/payment { rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break; proxy_pass http://$back; ``` * Ora in AWS S3 ``` location /s3/ { proxy_pass https://company-bucket.s3.amazonaws.com$uri; } ``` ### Qualsiasi variabile È stato scoperto che i **dati forniti dall'utente** potrebbero essere trattati come una **variabile Nginx** in determinate circostanze. La causa di questo comportamento rimane in parte sfuggente, tuttavia non è rara né semplice da verificare. Questa anomalia è stata evidenziata in un rapporto di sicurezza su HackerOne, che può essere visualizzato [qui](https://hackerone.com/reports/370094). Ulteriori indagini sul messaggio di errore hanno portato all'identificazione della sua presenza all'interno del [modulo filtro SSI del codice di Nginx](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), individuando gli Include lato server (SSI) come causa principale. Per **rilevare questa errata configurazione**, può essere eseguito il seguente comando, che implica impostare un'intestazione referer per testare la stampa della variabile: ```bash $ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’ ``` Scansioni per questa errata configurazione su vari sistemi hanno rivelato molteplici istanze in cui le variabili di Nginx potevano essere stampate da un utente. Tuttavia, una diminuzione del numero di istanze vulnerabili suggerisce che gli sforzi per correggere questo problema siano stati in qualche modo efficaci. ## Lettura grezza della risposta del backend Nginx offre una funzionalità tramite `proxy_pass` che consente l'intercettazione degli errori e degli header HTTP prodotti dal backend, mirando a nascondere messaggi di errore e header interni. Ciò viene realizzato da Nginx servendo pagine di errore personalizzate in risposta agli errori del backend. Tuttavia, si presentano sfide quando Nginx si trova di fronte a una richiesta HTTP non valida. Una tale richiesta viene inoltrata al backend così come ricevuta, e la risposta grezza del backend viene quindi inviata direttamente al client senza l'intervento di Nginx. Considera uno scenario di esempio che coinvolge un'applicazione uWSGI: ```python def application(environ, start_response): start_response('500 Error', [('Content-Type', 'text/html'), ('Secret-Header', 'secret-info')]) return [b"Secret info, should not be visible!"] ``` Per gestire ciò, vengono utilizzate direttive specifiche nella configurazione di Nginx: ``` http { error_page 500 /html/error.html; proxy_intercept_errors on; proxy_hide_header Secret-Header; } ``` * [**proxy\_intercept\_errors**](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_intercept\_errors): Questa direttiva abilita Nginx a servire una risposta personalizzata per le risposte del backend con un codice di stato maggiore di 300. Assicura che, per il nostro esempio di applicazione uWSGI, una risposta `Errore 500` venga intercettata e gestita da Nginx. * [**proxy\_hide\_header**](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#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 eventuali header segreti. Tuttavia, una richiesta HTTP non valida aggira questo meccanismo, portando all'esposizione delle risposte del backend in formato grezzo, inclusi gli header segreti e i messaggi di errore. ## merge\_slashes impostato su off Per impostazione predefinita, la direttiva **`merge_slashes` di Nginx** è impostata su **`on`**, che comprime più barre oblique in un URL in una singola barra obliqua. Questa funzionalità, pur semplificando l'elaborazione degli URL, può involontariamente 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 agisce come reverse-proxy. Per mitigare tali rischi, si consiglia di **disattivare la direttiva `merge_slashes`** per le applicazioni suscettibili a queste vulnerabilità. Ciò garantisce che Nginx inoltri le richieste all'applicazione senza modificare la struttura dell'URL, non mascherando eventuali problemi di sicurezza sottostanti. Per ulteriori informazioni consulta [Danny Robinson e Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d). ### **Valore predefinito nella direttiva Map** Nella **configurazione di Nginx**, la direttiva `map` spesso svolge un ruolo nel **controllo dell'autorizzazione**. Un errore comune è non specificare un **valore predefinito**, il che potrebbe portare a un accesso non autorizzato. Ad esempio: ```yaml http { map $uri $mappocallow { /map-poc/private 0; /map-poc/secret 0; /map-poc/public 1; } } ``` ```yaml server { location /map-poc { if ($mappocallow = 0) {return 403;} return 200 "Hello. It is private area: $mappocallow"; } } ``` 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](https://nginx.org/en/docs/http/ngx\_http\_map\_module.html) consiglia di impostare un **valore predefinito** per evitare tali problemi. ### **Vulnerabilità di Spoofing DNS** 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. Tuttavia, questo metodo è inefficace se Nginx è configurato per utilizzare **localhost (127.0.0.1)** per la risoluzione DNS. Nginx consente di specificare un server DNS nel seguente modo: ```yaml resolver 8.8.8.8; ``` ### **Direttive `proxy_pass` e `internal`** La direttiva **`proxy_pass`** è utilizzata per reindirizzare le richieste verso altri server, internamente o esternamente. La direttiva **`internal`** garantisce che determinate posizioni siano accessibili solo all'interno di Nginx. Anche se queste direttive non costituiscono vulnerabilità di per sé, la loro configurazione richiede un esame attento per evitare falle di sicurezza. ## proxy\_set\_header Upgrade & Connection Se il server nginx è configurato per passare gli header Upgrade e Connection, potrebbe essere eseguito un [**attacco di Smuggling h2c**](../../pentesting-web/h2c-smuggling.md) per accedere a endpoint protetti/interni. {% hint style="danger" %} 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. {% endhint %} Esempio di configurazione vulnerabile per rubare `/flag` da [qui](https://bishopfox.com/blog/h2c-smuggling-request): ``` server { listen 443 ssl; server_name localhost; ssl_certificate /usr/local/nginx/conf/cert.pem; ssl_certificate_key /usr/local/nginx/conf/privkey.pem; location / { proxy_pass http://backend:9999; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; } location /flag { deny all; } ``` {% hint style="warning" %} Si noti che anche se `proxy_pass` puntava a un **percorso** specifico come `http://backend:9999/socket.io` la connessione verrà stabilita con `http://backend:9999` quindi è possibile **contattare qualsiasi altro percorso all'interno di quel punto finale interno. Quindi non importa se viene specificato un percorso nell'URL di proxy\_pass.** {% endhint %} ## Provalo tu stesso Detectify ha creato un repository su GitHub dove puoi utilizzare Docker per configurare il tuo server di test Nginx vulnerabile con alcune delle misconfigurazioni discusse in questo articolo e provare a trovarle da solo! [https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx) ## Strumenti di Analisi Statica ### [GIXY](https://github.com/yandex/gixy) Gixy è uno strumento per analizzare la configurazione di Nginx. L'obiettivo principale di Gixy è prevenire le misconfigurazioni di sicurezza e automatizzare la rilevazione delle falle. ### [Nginxpwner](https://github.com/stark0de/nginxpwner) Nginxpwner è uno strumento semplice per cercare comuni misconfigurazioni e vulnerabilità di Nginx. ## Riferimenti * [**https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/**](https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/) * [**http://blog.zorinaq.com/nginx-resolver-vulns/**](http://blog.zorinaq.com/nginx-resolver-vulns/) * [**https://github.com/yandex/gixy/issues/115**](https://github.com/yandex/gixy/issues/115)
**Configurazione immediatamente disponibile per valutazione delle vulnerabilità e test di penetrazione**. Esegui un pentest completo da qualsiasi luogo con oltre 20 strumenti e funzionalità che vanno dalla ricognizione alla segnalazione. Non sostituiamo i pentester - sviluppiamo strumenti personalizzati, moduli di rilevamento ed exploit per dar loro più tempo per approfondire, aprire shell e divertirsi. {% embed url="https://pentest-tools.com/" %}
Impara l'hacking su AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)! Altri modi per supportare HackTricks: * Se desideri vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)! * Ottieni il [**merchandising ufficiale PEASS & HackTricks**](https://peass.creator-spring.com) * Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di esclusive [**NFT**](https://opensea.io/collection/the-peass-family) * **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Condividi i tuoi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.