Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 06:30:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/pentesting-web/nginx.md

20 KiB
Raw Blame History

Nginx

Impara l'hacking AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

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 restituire loro del tempo per approfondire, aprire shell e divertirsi.

{% embed url="https://pentest-tools.com/" %}

Missing root location

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:

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 ridurre questo rischio, ma potrebbe comunque consentire l'accesso non intenzionale ad altri file critici, inclusi altri file di configurazione, log 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 di File Locale (LFI) può essere introdotta involontariamente attraverso una configurazione che assomiglia alla seguente:

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 come segue:

location /imgs/ {
alias /path/images/;
}

Ulteriori informazioni: 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:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

{% content-ref url="../../pentesting-web/proxy-waf-protections-bypass.md" %} proxy-waf-protections-bypass.md {% endcontent-ref %}

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 nuovi caratteri di 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/.

Inoltre questa tecnica è spiegata in questa presentazione a https://www.youtube.com/watch?v=gWQyWdZbdoY&list=PL0xCSYnG_iTtJe2V6PQqamBF73n7-f1Nr&index=77 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, ma 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 presenza all'interno del modulo filtro SSI del codice di Nginx, 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:

$ 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 parte 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 i messaggi di errore interni e gli header. Ciò viene realizzato da Nginx servendo pagine di errore personalizzate in risposta agli errori del backend. Tuttavia, sorgono 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:

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: 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: 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. 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 alterare la struttura dell'URL, non mascherando eventuali problemi di sicurezza sottostanti.

Per ulteriori informazioni consulta Danny Robinson e Rotem Bar.

Intestazioni di Risposta Maliziose

Come mostrato in questo articolo, ci sono determinati header che, se presenti nella risposta dal server web, cambieranno il comportamento del proxy Nginx. Puoi controllarli nella documentazione:

  • 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'header 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 (Trasversamento di Percorso).

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:

http {
map $uri $mappocallow {
/map-poc/private 0;
/map-poc/secret 0;
/map-poc/public 1;
}
}

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 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:

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 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:

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" %} Nota 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 puoi contattare qualsiasi altro percorso all'interno di quel punto finale interno. Quindi non importa se un percorso è specificato nell'URL di proxy_pass. {% endhint %}

Provalo tu stesso

Detectify ha creato un repository 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

Strumenti di Analisi Statica

GIXY

Gixy è uno strumento per analizzare la configurazione di Nginx. L'obiettivo principale di Gixy è prevenire le misconfigurazioni di sicurezza e automatizzare il rilevamento delle vulnerabilità.

Nginxpwner

Nginxpwner è uno strumento semplice per cercare le comuni misconfigurazioni e vulnerabilità di Nginx.

Riferimenti

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 dare 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: