diff --git a/src/images/nginx_try_files.png b/src/images/nginx_try_files.png new file mode 100644 index 000000000..0c14e95c9 Binary files /dev/null and b/src/images/nginx_try_files.png differ diff --git a/src/network-services-pentesting/pentesting-web/nginx.md b/src/network-services-pentesting/pentesting-web/nginx.md index 1b18c81fb..6fb614a5c 100644 --- a/src/network-services-pentesting/pentesting-web/nginx.md +++ b/src/network-services-pentesting/pentesting-web/nginx.md @@ -5,7 +5,7 @@ ## Fehlender Root-Standort -Bei der Konfiguration des Nginx-Servers spielt die **root-Direktive** eine entscheidende Rolle, da sie das Basisverzeichnis definiert, aus dem Dateien bereitgestellt werden. Betrachten Sie das folgende Beispiel: +Bei der Konfiguration des Nginx-Servers spielt die **Root-Direktive** eine entscheidende Rolle, da sie das Basisverzeichnis definiert, aus dem Dateien bereitgestellt werden. Betrachten Sie das folgende Beispiel: ```bash server { root /etc/nginx; @@ -16,13 +16,13 @@ proxy_pass http://127.0.0.1:8080/; } } ``` -In dieser Konfiguration ist `/etc/nginx` als das Wurzelverzeichnis festgelegt. Dieses Setup ermöglicht den Zugriff auf Dateien im angegebenen Wurzelverzeichnis, wie z.B. `/hello.txt`. Es ist jedoch wichtig zu beachten, dass nur ein spezifischer Ort (`/hello.txt`) definiert ist. Es gibt keine Konfiguration für den Wurzelort (`location / {...}`). Diese Auslassung bedeutet, dass die Wurzelanweisung global gilt, was es Anfragen an den Wurzelpfad `/` ermöglicht, auf Dateien unter `/etc/nginx` zuzugreifen. +In dieser Konfiguration ist `/etc/nginx` als das Wurzelverzeichnis festgelegt. Dieses Setup ermöglicht den Zugriff auf Dateien im angegebenen Wurzelverzeichnis, wie z.B. `/hello.txt`. Es ist jedoch wichtig zu beachten, dass nur ein spezifischer Ort (`/hello.txt`) definiert ist. Es gibt keine Konfiguration für den Wurzelort (`location / {...}`). Diese Auslassung bedeutet, dass die Root-Direktive global gilt, was es Anfragen an den Wurzelpfad `/` ermöglicht, auf Dateien unter `/etc/nginx` zuzugreifen. -Eine kritische Sicherheitsüberlegung ergibt sich aus dieser Konfiguration. Eine einfache `GET`-Anfrage, wie `GET /nginx.conf`, könnte sensible Informationen offenlegen, indem die Nginx-Konfigurationsdatei unter `/etc/nginx/nginx.conf` bereitgestellt wird. Das Setzen des Wurzels auf ein weniger sensibles Verzeichnis, wie `/etc`, könnte dieses Risiko mindern, dennoch könnte es weiterhin unbeabsichtigten Zugriff auf andere kritische Dateien, einschließlich anderer Konfigurationsdateien, Zugriffsprotokolle und sogar verschlüsselter Anmeldeinformationen für die HTTP-Basisauthentifizierung, ermöglichen. +Eine kritische Sicherheitsüberlegung ergibt sich aus dieser Konfiguration. Eine einfache `GET`-Anfrage, wie `GET /nginx.conf`, könnte sensible Informationen offenlegen, indem die Nginx-Konfigurationsdatei unter `/etc/nginx/nginx.conf` bereitgestellt wird. Das Setzen des Roots auf ein weniger sensibles Verzeichnis, wie `/etc`, könnte dieses Risiko mindern, dennoch könnte es weiterhin unbeabsichtigten Zugriff auf andere kritische Dateien, einschließlich anderer Konfigurationsdateien, Zugriffsprotokolle und sogar verschlüsselter Anmeldeinformationen für die HTTP-Basisauthentifizierung, ermöglichen. ## Alias LFI Fehlkonfiguration -In den Konfigurationsdateien von Nginx ist eine genaue Überprüfung der "location"-Anweisungen erforderlich. Eine Schwachstelle, die als Local File Inclusion (LFI) bekannt ist, kann unbeabsichtigt durch eine Konfiguration eingeführt werden, die der folgenden ähnelt: +In den Konfigurationsdateien von Nginx ist eine genaue Überprüfung der "location"-Direktiven erforderlich. Eine Schwachstelle, die als Local File Inclusion (LFI) bekannt ist, kann unbeabsichtigt durch eine Konfiguration eingeführt werden, die der folgenden ähnelt: ``` location /imgs { alias /path/images/; @@ -48,7 +48,7 @@ alias../ => HTTP status code 403 ``` ## Unsichere Pfadbeschränkung -Überprüfen Sie die folgende Seite, um zu erfahren, wie man Direktiven wie umgeht: +Überprüfen Sie die folgende Seite, um zu erfahren, wie man Direktiven wie: umgeht: ```plaintext location = /admin { deny all; @@ -81,7 +81,7 @@ location / { return 302 https://example.com$uri; } ``` -Die Zeichen \r (Carriage Return) und \n (Line Feed) kennzeichnen Zeilenumbrüche in HTTP-Anfragen, und ihre URL-kodierten Formen werden als `%0d%0a` dargestellt. Das Einfügen dieser Zeichen in eine Anfrage (z. B. `http://localhost/%0d%0aDetectify:%20clrf`) an einen falsch konfigurierten Server führt dazu, dass der Server einen neuen Header mit dem Namen `Detectify` ausgibt. Dies geschieht, weil die $uri-Variable die URL-kodierten Zeilenumbrüche dekodiert, was zu einem unerwarteten Header in der Antwort führt: +Die Zeichen \r (Carriage Return) und \n (Line Feed) signalisieren Zeilenumbruchzeichen in HTTP-Anfragen, und ihre URL-kodierten Formen werden als `%0d%0a` dargestellt. Das Einfügen dieser Zeichen in eine Anfrage (z. B. `http://localhost/%0d%0aDetectify:%20clrf`) an einen falsch konfigurierten Server führt dazu, dass der Server einen neuen Header mit dem Namen `Detectify` ausgibt. Dies geschieht, weil die $uri-Variable die URL-kodierten Zeilenumbruchzeichen dekodiert, was zu einem unerwarteten Header in der Antwort führt: ``` HTTP/1.1 302 Moved Temporarily Server: nginx/1.19.3 @@ -98,7 +98,7 @@ Diese Technik wird auch [**in diesem Vortrag erklärt**](https://www.youtube.com - `https://example.com/%20X` - Jeder HTTP-Code - `https://example.com/%20H` - 400 Bad Request -Wenn anfällig, wird die erste Anfrage zurückgegeben, da "X" jede HTTP-Methode ist, und die zweite wird einen Fehler zurückgeben, da H keine gültige Methode ist. Der Server erhält also etwas wie: `GET / H HTTP/1.1` und dies wird den Fehler auslösen. +Wenn anfällig, wird die erste Anfrage zurückgeben, da "X" jede HTTP-Methode ist, und die zweite wird einen Fehler zurückgeben, da H keine gültige Methode ist. Der Server erhält also etwas wie: `GET / H HTTP/1.1` und dies wird den Fehler auslösen. Ein weiteres Erkennungsbeispiel wäre: @@ -113,7 +113,7 @@ location ^~ /lite/api/ { proxy_pass http://lite-backend$uri$is_args$args; } ``` -- Beachte, wie erneut **`$uri`** in der URL ist (diesmal innerhalb eines Parameters) +- Beachte, dass erneut **`$uri`** in der URL ist (diesmal innerhalb eines Parameters) ``` location ~ ^/dna/payment { rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break; @@ -129,15 +129,65 @@ proxy_pass https://company-bucket.s3.amazonaws.com$uri; Es wurde festgestellt, dass **benutzereingereichte Daten** unter bestimmten Umständen als **Nginx-Variable** behandelt werden könnten. Die Ursache dieses Verhaltens bleibt etwas unklar, ist jedoch weder selten noch einfach zu überprüfen. Diese Anomalie wurde in einem Sicherheitsbericht auf HackerOne hervorgehoben, der [hier](https://hackerone.com/reports/370094) eingesehen werden kann. Weitere Untersuchungen der Fehlermeldung führten zur Identifizierung ihres Auftretens innerhalb des [SSI-Filtermoduls des Nginx-Codebases](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), wobei Server Side Includes (SSI) als Hauptursache festgestellt wurden. -Um diese **Fehlkonfiguration zu erkennen**, kann der folgende Befehl ausgeführt werden, der das Setzen eines Referer-Headers beinhaltet, um das Drucken von Variablen zu testen: +Um diese Fehlkonfiguration zu **erkennen**, kann der folgende Befehl ausgeführt werden, der das Setzen eines Referer-Headers beinhaltet, um das Drucken von Variablen zu testen: ```bash $ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’ ``` -Scans für diese Fehlkonfiguration über Systeme hinweg haben mehrere Fälle ergeben, in denen Nginx-Variablen von einem Benutzer ausgegeben werden konnten. Ein Rückgang der Anzahl der verwundbaren Instanzen deutet jedoch darauf hin, dass die Bemühungen, dieses Problem zu beheben, einigermaßen erfolgreich waren. +Scans for this misconfiguration across systems revealed multiple instances where Nginx variables could be printed by a user. However, a decrease in the number of vulnerable instances suggests that efforts to patch this issue have been somewhat successful. + +### Verwendung von try_files mit $URI$ARGS-Variablen + +Following Nginx misconfiguration can lead to an LFI vulnerability: +``` +location / { +try_files $uri$args $uri$args/ /index.html; +} +``` +In unserer Konfiguration haben wir die Direktive `try_files`, die verwendet wird, um die Existenz von Dateien in der angegebenen Reihenfolge zu überprüfen. Nginx wird die erste Datei bereitstellen, die es findet. Die grundlegende Syntax der Direktive `try_files` ist wie folgt: +``` +try_files file1 file2 ... fileN fallback; +``` +Nginx wird die Existenz jeder Datei in der angegebenen Reihenfolge überprüfen. Wenn eine Datei existiert, wird sie sofort bereitgestellt. Wenn keine der angegebenen Dateien existiert, wird die Anfrage an die Fallback-Option weitergeleitet, die eine andere URI oder eine spezifische Fehlerseite sein kann. + +Wenn jedoch die Variablen `$uri$args` in dieser Direktive verwendet werden, wird Nginx versuchen, eine Datei zu finden, die mit der Anfrage-URI kombiniert mit allen Abfragezeichenfolgenargumenten übereinstimmt. Daher können wir diese Konfiguration ausnutzen: +``` +http { +server { +root /var/www/html/public; + +location / { +try_files $uri$args $uri$args/ /index.html; +} +} +} +``` +Mit folgendem Payload: +``` +GET /?../../../../../../../../etc/passwd HTTP/1.1 +Host: example.com +``` +Mit unserem Payload werden wir das Wurzelverzeichnis (definiert in der Nginx-Konfiguration) verlassen und die Datei `/etc/passwd` laden. In den Debug-Protokollen können wir beobachten, wie Nginx die Dateien versucht: +``` +...SNIP... + +2025/07/11 15:49:16 [debug] 79694#79694: *4 trying to use file: "/../../../../../../../../etc/passwd" "/var/www/html/public/../../../../../../../../etc/passwd" +2025/07/11 15:49:16 [debug] 79694#79694: *4 try file uri: "/../../../../../../../../etc/passwd" + +...SNIP... + +2025/07/11 15:49:16 [debug] 79694#79694: *4 http filename: "/var/www/html/public/../../../../../../../../etc/passwd" + +...SNIP... + +2025/07/11 15:49:16 [debug] 79694#79694: *4 HTTP/1.1 200 OK + +``` +PoC gegen Nginx unter Verwendung der oben genannten Konfiguration: +![Beispiel burp-Anfrage](../../images/nginx_try_files.png) ## Rohes Backend-Antwortlesen -Nginx bietet eine Funktion über `proxy_pass`, die die Abfangung von Fehlern und HTTP-Headern ermöglicht, die vom Backend erzeugt werden, mit dem Ziel, interne Fehlermeldungen und Header zu verbergen. Dies wird erreicht, indem Nginx benutzerdefinierte Fehlerseiten als Antwort auf Backend-Fehler bereitstellt. Herausforderungen treten jedoch auf, wenn Nginx eine ungültige HTTP-Anfrage erhält. Eine solche Anfrage wird unverändert an das Backend weitergeleitet, und die rohe Antwort des Backends wird dann direkt an den Client gesendet, ohne dass Nginx eingreift. +Nginx bietet eine Funktion über `proxy_pass`, die es ermöglicht, Fehler und HTTP-Header, die vom Backend erzeugt werden, abzufangen, um interne Fehlermeldungen und Header zu verbergen. Dies wird erreicht, indem Nginx benutzerdefinierte Fehlerseiten als Antwort auf Backend-Fehler bereitstellt. Herausforderungen treten jedoch auf, wenn Nginx eine ungültige HTTP-Anfrage erhält. Eine solche Anfrage wird unverändert an das Backend weitergeleitet, und die rohe Antwort des Backends wird dann direkt an den Client gesendet, ohne dass Nginx eingreift. Betrachten Sie ein Beispiel-Szenario mit einer uWSGI-Anwendung: ```python @@ -153,14 +203,14 @@ 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): Diese Direktive ermöglicht es Nginx, eine benutzerdefinierte Antwort für Backend-Antworten mit einem Statuscode größer als 300 bereitzustellen. Sie stellt sicher, dass für unsere Beispiel-uWSGI-Anwendung eine `500 Error`-Antwort von Nginx abgefangen und verarbeitet wird. +- [**proxy_intercept_errors**](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_intercept_errors): Diese Direktive ermöglicht es Nginx, eine benutzerdefinierte Antwort für Backend-Antworten mit einem Statuscode größer als 300 bereitzustellen. Sie stellt sicher, dass in unserem Beispiel der uWSGI-Anwendung eine `500 Error`-Antwort abgefangen und von Nginx verarbeitet wird. - [**proxy_hide_header**](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_hide_header): Wie der Name schon sagt, verbirgt diese Direktive bestimmte HTTP-Header vor dem Client und verbessert so die Privatsphäre und Sicherheit. -Wenn eine gültige `GET`-Anfrage gestellt wird, verarbeitet Nginx sie normalerweise und gibt eine standardmäßige Fehlermeldung zurück, ohne geheime Header offenzulegen. Eine ungültige HTTP-Anfrage umgeht jedoch diesen Mechanismus, was zur Offenlegung von rohen Backend-Antworten, einschließlich geheimer Header und Fehlermeldungen, führt. +Wenn eine gültige `GET`-Anfrage gestellt wird, verarbeitet Nginx sie normalerweise und gibt eine standardmäßige Fehlerantwort zurück, ohne geheime Header offenzulegen. Eine ungültige HTTP-Anfrage umgeht jedoch diesen Mechanismus, was zur Offenlegung roher Backend-Antworten, einschließlich geheimer Header und Fehlermeldungen, führt. ## merge_slashes auf aus gesetzt -Standardmäßig ist die **`merge_slashes`-Direktive** von Nginx auf **`on`** gesetzt, was mehrere aufeinanderfolgende Schrägstriche in einer URL zu einem einzigen Schrägstrich komprimiert. Diese Funktion, die die Verarbeitung von URLs vereinfacht, kann unbeabsichtigt Schwachstellen in Anwendungen hinter Nginx verbergen, insbesondere solche, die anfällig für lokale Datei-Inklusionsangriffe (LFI) sind. Sicherheitsexperten **Danny Robinson und Rotem Bar** haben die potenziellen Risiken hervorgehoben, die mit diesem Standardverhalten verbunden sind, insbesondere wenn Nginx als Reverse-Proxy fungiert. +Standardmäßig ist die **`merge_slashes`-Direktive** von Nginx auf **`on`** gesetzt, was mehrere aufeinanderfolgende Schrägstriche in einer URL zu einem einzelnen Schrägstrich komprimiert. Diese Funktion, die die Verarbeitung von URLs optimiert, kann unbeabsichtigt Schwachstellen in Anwendungen hinter Nginx verbergen, insbesondere solche, die anfällig für lokale Datei-Inklusionsangriffe (LFI) sind. Sicherheitsexperten **Danny Robinson und Rotem Bar** haben die potenziellen Risiken hervorgehoben, die mit diesem Standardverhalten verbunden sind, insbesondere wenn Nginx als Reverse-Proxy fungiert. Um solche Risiken zu mindern, wird empfohlen, die **`merge_slashes`-Direktive auszuschalten** für Anwendungen, die anfällig für diese Schwachstellen sind. Dies stellt sicher, dass Nginx Anfragen an die Anwendung weiterleitet, ohne die URL-Struktur zu ändern, und somit keine zugrunde liegenden Sicherheitsprobleme maskiert. @@ -170,13 +220,13 @@ Für weitere Informationen siehe [Danny Robinson und Rotem Bar](https://medium.c Wie in [**diesem Bericht**](https://mizu.re/post/cors-playground) gezeigt, gibt es bestimmte Header, die, wenn sie in der Antwort des Webservers vorhanden sind, das Verhalten des Nginx-Proxys ändern. Sie können sie [**in den Dokumenten**](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/) überprüfen: -- `X-Accel-Redirect`: Weist Nginx an, eine Anfrage intern an einen bestimmten Ort umzuleiten. +- `X-Accel-Redirect`: Weist Nginx an, eine Anfrage intern an einen bestimmten Ort weiterzuleiten. - `X-Accel-Buffering`: Steuert, ob Nginx die Antwort puffern soll oder nicht. - `X-Accel-Charset`: Legt den Zeichensatz für die Antwort fest, wenn X-Accel-Redirect verwendet wird. - `X-Accel-Expires`: Legt die Ablaufzeit für die Antwort fest, wenn X-Accel-Redirect verwendet wird. - `X-Accel-Limit-Rate`: Begrenzung der Übertragungsrate für Antworten, wenn X-Accel-Redirect verwendet wird. -Zum Beispiel wird der Header **`X-Accel-Redirect`** eine interne **Umleitung** in Nginx verursachen. Wenn also eine Nginx-Konfiguration mit etwas wie **`root /`** und einer Antwort vom Webserver mit **`X-Accel-Redirect: .env`** vorhanden ist, wird Nginx den Inhalt von **`/.env`** senden (Path Traversal). +Zum Beispiel wird der Header **`X-Accel-Redirect`** eine interne **Umleitung** in Nginx verursachen. Wenn also eine Nginx-Konfiguration mit etwas wie **`root /`** und eine Antwort vom Webserver mit **`X-Accel-Redirect: .env`** vorhanden ist, wird Nginx den Inhalt von **`/.env`** senden (Path Traversal). ### **Standardwert in der Map-Direktive** @@ -209,7 +259,7 @@ resolver 8.8.8.8; ``` ### **`proxy_pass` und `internal` Direktiven** -Die **`proxy_pass`** Direktive wird verwendet, um Anfragen an andere Server weiterzuleiten, entweder intern oder extern. Die **`internal`** Direktive stellt sicher, dass bestimmte Standorte nur innerhalb von Nginx zugänglich sind. Während diese Direktiven für sich genommen keine Schwachstellen darstellen, erfordert ihre Konfiguration eine sorgfältige Prüfung, um Sicherheitslücken zu vermeiden. +Die **`proxy_pass`** Direktive wird verwendet, um Anfragen an andere Server weiterzuleiten, entweder intern oder extern. Die **`internal`** Direktive stellt sicher, dass bestimmte Standorte nur innerhalb von Nginx zugänglich sind. Obwohl diese Direktiven an sich keine Schwachstellen sind, erfordert ihre Konfiguration eine sorgfältige Prüfung, um Sicherheitslücken zu vermeiden. ## proxy_set_header Upgrade & Connection @@ -243,7 +293,7 @@ deny all; ## Probieren Sie es selbst aus -Detectify hat ein GitHub-Repository erstellt, in dem Sie Docker verwenden können, um Ihren eigenen anfälligen Nginx-Testserver mit einigen der in diesem Artikel besprochenen Fehlkonfigurationen einzurichten und diese selbst zu finden! +Detectify hat ein GitHub-Repository erstellt, in dem Sie Docker verwenden können, um Ihren eigenen anfälligen Nginx-Testserver mit einigen der in diesem Artikel besprochenen Fehlkonfigurationen einzurichten und selbst nach ihnen zu suchen! [https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx)