# Nginx
Lernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)! Andere Möglichkeiten, HackTricks zu unterstützen: * Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)! * Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com) * Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family) * **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.** * **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) **GitHub-Repositories** senden.
**Sofort verfügbare Einrichtung für Schwachstellenbewertung und Penetrationstests**. Führen Sie einen vollständigen Pentest von überall aus mit 20+ Tools und Funktionen durch, die von der Aufklärung bis zum Bericht reichen. Wir ersetzen keine Pentester - wir entwickeln benutzerdefinierte Tools, Erkennungs- und Exploit-Module, um ihnen etwas Zeit zu geben, um tiefer zu graben, Shells zu öffnen und Spaß zu haben. {% embed url="https://pentest-tools.com/" %} ## Fehlender Root-Standort ## **Grundlagen der Konfiguration des Nginx-Stammverzeichnisses** Bei der Konfiguration des Nginx-Servers spielt die **root-Direktive** eine entscheidende Rolle, indem sie das Basisverzeichnis definiert, von dem aus Dateien bereitgestellt werden. Betrachten Sie das folgende Beispiel: ```bash server { root /etc/nginx; location /hello.txt { try_files $uri $uri/ =404; proxy_pass http://127.0.0.1:8080/; } } ``` In dieser Konfiguration wird `/etc/nginx` als Stammverzeichnis festgelegt. Diese Einrichtung ermöglicht den Zugriff auf Dateien innerhalb des angegebenen Stammverzeichnisses, wie z.B. `/hello.txt`. Es ist jedoch wichtig zu beachten, dass nur ein bestimmter Ort (`/hello.txt`) definiert ist. Es gibt keine Konfiguration für den Stammort (`location / {...}`). Durch dieses Weglassen gilt die Stamm-Anweisung global, sodass Anfragen an den Stamm-Pfad `/` auf Dateien unter `/etc/nginx` zugreifen können. Aus dieser Konfiguration ergibt sich eine kritische Sicherheitsüberlegung. Eine einfache `GET`-Anfrage wie `GET /nginx.conf` könnte sensible Informationen preisgeben, indem die Nginx-Konfigurationsdatei unter `/etc/nginx/nginx.conf` bereitgestellt wird. Das Festlegen des Stammverzeichnisses auf ein weniger sensibles Verzeichnis wie `/etc` könnte dieses Risiko mindern, könnte jedoch immer noch unbeabsichtigten Zugriff auf andere wichtige Dateien ermöglichen, einschließlich anderer Konfigurationsdateien, Zugriffsprotokolle und sogar verschlüsselter Anmeldeinformationen, die für die HTTP-Basisauthentifizierung verwendet werden. ## Alias LFI Fehlkonfiguration In den Konfigurationsdateien von Nginx ist eine genaue Überprüfung der "location"-Anweisungen erforderlich. Durch eine Konfiguration, die der folgenden ähnelt, kann unabsichtlich eine Sicherheitslücke namens Local File Inclusion (LFI) eingeführt werden: ``` location /imgs { alias /path/images/; } ``` Diese Konfiguration ist anfällig für LFI-Angriffe, da der Server Anfragen wie `/imgs../flag.txt` als Versuch interpretiert, auf Dateien außerhalb des beabsichtigten Verzeichnisses zuzugreifen, was effektiv zu `/path/images/../flag.txt` führt. Diese Schwachstelle ermöglicht es Angreifern, Dateien aus dem Dateisystem des Servers abzurufen, die über das Web nicht zugänglich sein sollten. Um diese Sicherheitslücke zu beheben, sollte die Konfiguration angepasst werden: ``` location /imgs/ { alias /path/images/; } ``` Weitere Informationen: [https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/](https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/) Accunetix-Tests: ``` 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 ``` ## Unsichere Pfadbeschränkung Überprüfen Sie die folgende Seite, um zu erfahren, wie Sie Direktiven wie umgehen können: ```plaintext location = /admin { deny all; } location = /admin/ { deny all; } ``` {% content-ref url="../../pentesting-web/proxy-waf-protections-bypass.md" %} [proxy-waf-protections-bypass.md](../../pentesting-web/proxy-waf-protections-bypass.md) {% endcontent-ref %} ## Unsicherer Variablengebrauch Eine Schwachstelle in der Nginx-Konfiguration wird am folgenden Beispiel demonstriert: ``` location / { return 302 https://example.com$uri; } ``` Die Zeichen \r (Wagenrücklauf) und \n (Zeilenumbruch) stehen für Zeilenumbruchzeichen in HTTP-Anfragen, und ihre URL-codierten Formen werden als `%0d%0a` dargestellt. Wenn diese Zeichen in einer Anfrage enthalten sind (z. B. `http://localhost/%0d%0aDetectify:%20clrf`) an einen fehlerhaft konfigurierten Server, führt dies dazu, dass der Server einen neuen Header mit dem Namen `Detectify` ausgibt. Dies geschieht, weil die Variable $uri die URL-codierten Zeilenumbruchzeichen decodiert, was zu einem unerwarteten Header in der Antwort führt: ``` 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 ``` Erfahren Sie mehr über die Risiken von CRLF-Injection und Response-Splitting unter [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/). ### Jede Variable Es wurde festgestellt, dass **benutzerdefinierte Daten** unter bestimmten Umständen als **Nginx-Variable** behandelt werden können. Die Ursache für dieses Verhalten bleibt etwas rätselhaft, 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. Eine weitere Untersuchung der Fehlermeldung führte zur Identifizierung ihres Auftretens im [SSI-Filtermodul 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 eigentliche Ursache identifiziert wurden. Um diese Fehlkonfiguration zu **erkennen**, kann der folgende Befehl ausgeführt werden, der das Setzen eines Referer-Headers beinhaltet, um die Ausgabe der Variablen zu testen: ```bash $ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’ ``` Scans für diese Konfigurationsfehler auf verschiedenen Systemen haben mehrere Fälle aufgedeckt, in denen Nginx-Variablen von einem Benutzer angezeigt werden konnten. Allerdings deutet eine Abnahme der anfälligen Fälle darauf hin, dass die Bemühungen zur Behebung dieses Problems teilweise erfolgreich waren. ## Lesen der Rohantwort des Backends 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 ergeben sich jedoch, wenn Nginx eine ungültige HTTP-Anfrage erhält. Eine solche Anfrage wird unverändert an das Backend weitergeleitet und die Rohantwort des Backends wird direkt an den Client gesendet, ohne dass Nginx eingreift. Betrachten wir ein Beispiel-Szenario mit einer uWSGI-Anwendung: ```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!"] ``` Um dies zu verwalten, werden spezifische Anweisungen in der Nginx-Konfiguration verwendet: ``` 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)**: Diese Anweisung ermöglicht es Nginx, eine benutzerdefinierte Antwort für Backend-Antworten mit einem Statuscode größer als 300 zu senden. Dadurch wird sichergestellt, dass bei unserer Beispiel-uWSGI-Anwendung eine `500 Error`-Antwort von Nginx abgefangen und behandelt 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 Anweisung bestimmte HTTP-Header vor dem Client und erhöht so die Privatsphäre und Sicherheit. Wenn eine gültige `GET`-Anfrage gestellt wird, verarbeitet Nginx sie normal und gibt eine Standardfehlerantwort zurück, ohne geheime Header preiszugeben. Eine ungültige HTTP-Anfrage umgeht jedoch diesen Mechanismus und führt zur Offenlegung von Rohdaten der Backend-Antworten, einschließlich geheimer Header und Fehlermeldungen. ## merge\_slashes auf off gesetzt Standardmäßig ist die **`merge_slashes`-Anweisung** von Nginx auf **`on`** gesetzt, was mehrere Schrägstriche in einer URL zu einem einzigen Schrägstrich komprimiert. Diese Funktion kann jedoch versehentlich Schwachstellen in Anwendungen hinter Nginx verbergen, insbesondere solche, die anfällig für Local File Inclusion (LFI)-Angriffe sind. Die Sicherheitsexperten **Danny Robinson und Rotem Bar** haben auf die potenziellen Risiken dieses Standardverhaltens hingewiesen, insbesondere wenn Nginx als Reverse-Proxy fungiert. Um solche Risiken zu minimieren, wird empfohlen, die **`merge_slashes`-Anweisung für anfällige Anwendungen auszuschalten**. Dadurch wird sichergestellt, dass Nginx Anfragen an die Anwendung weiterleitet, ohne die URL-Struktur zu verändern und somit keine zugrunde liegenden Sicherheitsprobleme zu verbergen. Weitere Informationen finden Sie unter [Danny Robinson und Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d). ### **Standardwert in der Map-Anweisung** In der **Nginx-Konfiguration** spielt die `map`-Anweisung oft eine Rolle bei der **Autorisierungssteuerung**. Ein häufiger Fehler besteht darin, keinen **Standardwert** anzugeben, was zu unberechtigtem Zugriff führen kann. Zum Beispiel: ```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"; } } ``` Ohne `default` kann ein **bösartiger Benutzer** die Sicherheit umgehen, indem er auf eine **undefinierte URI** innerhalb von `/map-poc` zugreift. [Das Nginx-Handbuch](https://nginx.org/en/docs/http/ngx_http_map_module.html) empfiehlt, einen **Standardwert** festzulegen, um solche Probleme zu vermeiden. ### **DNS-Spoofing-Schwachstelle** DNS-Spoofing gegen Nginx ist unter bestimmten Bedingungen möglich. Wenn ein Angreifer den von Nginx verwendeten **DNS-Server** kennt und seine DNS-Anfragen abfangen kann, kann er DNS-Einträge fälschen. Diese Methode ist jedoch unwirksam, wenn Nginx so konfiguriert ist, dass es zur DNS-Auflösung **localhost (127.0.0.1)** verwendet. Nginx ermöglicht die Angabe eines DNS-Servers wie folgt: ```yaml resolver 8.8.8.8; ``` ### **`proxy_pass` und `internal` Direktiven** Die **`proxy_pass`**-Direktive wird verwendet, um Anfragen an andere Server umzuleiten, entweder intern oder extern. Die **`internal`**-Direktive stellt sicher, dass bestimmte Standorte nur innerhalb von Nginx erreichbar sind. Obwohl diese Direktiven an sich keine Sicherheitslücken darstellen, erfordert ihre Konfiguration eine sorgfältige Prüfung, um Sicherheitslücken zu vermeiden. ## proxy\_set\_header Upgrade & Connection Wenn der Nginx-Server so konfiguriert ist, dass die Upgrade- und Connection-Header weitergeleitet werden, kann ein [**h2c-Smuggling-Angriff**](../../pentesting-web/h2c-smuggling.md) durchgeführt werden, um auf geschützte/interne Endpunkte zuzugreifen. {% hint style="danger" %} Diese Sicherheitslücke würde einem Angreifer ermöglichen, eine direkte Verbindung mit dem `proxy_pass`-Endpunkt (`http://backend:9999` in diesem Fall) herzustellen, dessen Inhalt nicht von Nginx überprüft wird. {% endhint %} Beispiel für eine verwundbare Konfiguration zum Stehlen von `/flag` von [hier](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" %} Beachten Sie, dass selbst wenn `proxy_pass` auf einen bestimmten **Pfad** wie `http://backend:9999/socket.io` zeigt, die Verbindung mit `http://backend:9999` hergestellt wird. Sie können also **jeden anderen Pfad innerhalb dieses internen Endpunkts kontaktieren. Es spielt also keine Rolle, ob ein Pfad in der URL von proxy\_pass angegeben ist.** {% endhint %} ## Probieren Sie es selbst aus Detectify hat ein GitHub-Repository erstellt, in dem Sie Docker verwenden können, um Ihren eigenen verwundbaren Nginx-Testserver mit einigen der in diesem Artikel behandelten Fehlkonfigurationen einzurichten und selbst nach ihnen zu suchen! [https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx) ## Statische Analysetools ### [GIXY](https://github.com/yandex/gixy) Gixy ist ein Tool zur Analyse der Nginx-Konfiguration. Das Hauptziel von Gixy ist es, Sicherheitsfehler zu verhindern und die automatische Erkennung von Schwachstellen zu ermöglichen. ### [Nginxpwner](https://github.com/stark0de/nginxpwner) Nginxpwner ist ein einfaches Tool, um nach gängigen Nginx-Fehlkonfigurationen und Schwachstellen zu suchen. ## Referenzen * [**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)
**Sofort einsatzbereite Einrichtung für Schwachstellenbewertung und Penetrationstests**. Führen Sie einen vollständigen Penetrationstest von überall aus mit über 20 Tools und Funktionen durch, die von der Aufklärung bis zum Bericht reichen. Wir ersetzen keine Penetrationstester - wir entwickeln benutzerdefinierte Tools, Erkennungs- und Exploit-Module, um ihnen etwas Zeit zu geben, um tiefer zu graben, Shells zu öffnen und Spaß zu haben. {% embed url="https://pentest-tools.com/" %}
Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)! Andere Möglichkeiten, HackTricks zu unterstützen: * Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)! * Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com) * Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family) * **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.** * **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories senden.