Nginx
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Erhalte die Perspektive eines Hackers auf deine Webanwendungen, Netzwerke und Cloud
Finde und melde kritische, ausnutzbare Schwachstellen mit echtem Geschäftsauswirkungen. Nutze unsere 20+ benutzerdefinierten Tools, um die Angriffsfläche zu kartieren, Sicherheitsprobleme zu finden, die dir ermöglichen, Privilegien zu eskalieren, und automatisierte Exploits zu verwenden, um wesentliche Beweise zu sammeln, die deine harte Arbeit in überzeugende Berichte verwandeln.
Bei der Konfiguration des Nginx-Servers spielt die Root-Direktive eine entscheidende Rolle, indem sie das Basisverzeichnis definiert, aus dem Dateien bereitgestellt werden. Betrachte das folgende Beispiel:
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 Wurzelverzeichnisses 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.
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:
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 vorgesehenen Verzeichnisses zuzugreifen, was effektiv zu /path/images/../flag.txt aufgelöst wird. Dieser Fehler ermöglicht es Angreifern, Dateien aus dem Dateisystem des Servers abzurufen, die nicht über das Web zugänglich sein sollten.
Um diese Schwachstelle zu mindern, sollte die Konfiguration angepasst werden zu:
Mehr Informationen: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/
Accunetix-Tests:
Überprüfen Sie die folgende Seite, um zu erfahren, wie man Direktiven wie umgeht:
Anfällige Variablen $uri und $document_uri und dies kann behoben werden, indem sie durch $request_uri ersetzt werden.
Ein Regex kann ebenfalls anfällig sein, wie:
location ~ /docs/([^/])? { … $1 … } - Anfällig
location ~ /docs/([^/\s])? { … $1 … } - Nicht anfällig (überprüft Leerzeichen)
location ~ /docs/(.*)? { … $1 … } - Nicht anfällig
Eine Schwachstelle in der Nginx-Konfiguration wird durch das folgende Beispiel demonstriert:
Die Zeichen \r (Carriage Return) und \n (Line Feed) kennzeichnen 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:
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/.
Diese Technik wird auch in diesem Vortrag erklärt mit einigen anfälligen Beispielen und Erkennungsmechanismen. Zum Beispiel, um diese Fehlkonfiguration aus einer Blackbox-Perspektive zu erkennen, könnten Sie diese Anfragen verwenden:
https://example.com/%20X - Jeder HTTP-Code
https://example.com/%20H - 400 Bad Request
Wenn anfällig, wird die erste als "X" 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.
Ein weiteres Erkennungsbeispiel wäre:
http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Jeder HTTP-Code
http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Bad Request
Einige gefundene anfällige Konfigurationen, die in diesem Vortrag präsentiert wurden, waren:
Beachten Sie, wie $uri im endgültigen URL so gesetzt ist.
Beachten Sie, wie erneut $uri in der URL ist (diesmal innerhalb eines Parameters)
Jetzt in AWS S3
Es wurde entdeckt, 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 eingesehen werden kann. Weitere Untersuchungen der Fehlermeldung führten zur Identifizierung ihres Auftretens innerhalb des SSI-Filtermoduls des Nginx-Codebases, 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:
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.
Nginx bietet eine Funktion über proxy_pass, die die Abfangung von Fehlern und HTTP-Headern, die vom Backend erzeugt werden, ermöglicht, 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:
Um dies zu verwalten, werden spezifische Direktiven in der Nginx-Konfiguration verwendet:
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_hide_header: Wie der Name schon sagt, verbirgt diese Direktive bestimmte HTTP-Header vor dem Client, was die Privatsphäre und Sicherheit erhöht.
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 von rohen Backend-Antworten, einschließlich geheimer Header und Fehlermeldungen, führt.
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, wodurch keine zugrunde liegenden Sicherheitsprobleme maskiert werden.
Für weitere Informationen siehe Danny Robinson und Rotem Bar.
Wie in diesem Bericht 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 überprüfen:
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 eine Antwort vom Webserver mit X-Accel-Redirect: .env vorhanden ist, wird Nginx den Inhalt von /.env senden (Path Traversal).
In der Nginx-Konfiguration spielt die map-Direktive oft eine Rolle bei der Autorisierungskontrolle. Ein häufiger Fehler besteht darin, keinen Standard-Wert anzugeben, was zu unbefugtem Zugriff führen könnte. Zum Beispiel:
Ohne ein default kann ein böswilliger Benutzer die Sicherheit umgehen, indem er auf eine nicht definierte URI innerhalb von /map-poc zugreift. Das Nginx-Handbuch empfiehlt, einen Standardwert festzulegen, um solche Probleme zu vermeiden.
DNS-Spoofing gegen Nginx ist unter bestimmten Bedingungen möglich. Wenn ein Angreifer den DNS-Server kennt, der von Nginx verwendet wird, und seine DNS-Abfragen abfangen kann, kann er DNS-Einträge fälschen. Diese Methode ist jedoch ineffektiv, wenn Nginx so konfiguriert ist, dass es localhost (127.0.0.1) für die DNS-Auflösung verwendet. Nginx erlaubt die Angabe eines DNS-Servers wie folgt:
proxy_pass und internal DirektivenDie 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.
Wenn der Nginx-Server so konfiguriert ist, dass er die Upgrade- und Connection-Header weitergibt, könnte ein h2c Smuggling-Angriff durchgeführt werden, um auf geschützte/interne Endpunkte zuzugreifen.
Diese Schwachstelle würde es 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.
Beispiel für eine anfällige Konfiguration, um /flag von hier zu stehlen:
Beachten Sie, dass selbst wenn der proxy_pass auf einen bestimmten Pfad wie http://backend:9999/socket.io zeigt, die Verbindung mit http://backend:9999 hergestellt wird, sodass Sie jeden anderen Pfad innerhalb dieses internen Endpunkts kontaktieren können. Es spielt also keine Rolle, ob ein Pfad in der URL von proxy_pass angegeben ist.
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 sie selbst zu finden!
https://github.com/detectify/vulnerable-nginx
Gixy ist ein Tool zur Analyse von Nginx-Konfigurationen. Das Hauptziel von Gixy ist es, Sicherheitsfehlkonfigurationen zu verhindern und die Fehlererkennung zu automatisieren.
Nginxpwner ist ein einfaches Tool, um nach häufigen Nginx-Fehlkonfigurationen und -anfälligkeiten zu suchen.
Erhalten Sie die Perspektive eines Hackers auf Ihre Webanwendungen, Ihr Netzwerk und die Cloud
Finden und melden Sie kritische, ausnutzbare Sicherheitsanfälligkeiten mit echtem Geschäftsauswirkungen. Verwenden Sie unsere 20+ benutzerdefinierten Tools, um die Angriffsfläche zu kartieren, Sicherheitsprobleme zu finden, die Ihnen ermöglichen, Berechtigungen zu eskalieren, und automatisierte Exploits zu verwenden, um wesentliche Beweise zu sammeln, und Ihre harte Arbeit in überzeugende Berichte umzuwandeln.
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
