German - Ht
HackTricks Training Twitter Linkedin Sponsor

Nginx

Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Sofort verfügbare Einrichtung für Schwachstellenbewertung & Penetrationstests. Führen Sie einen vollständigen Pentest von überall aus mit 20+ Tools & Funktionen durch, die von der Aufklärung bis zum Bericht reichen. Wir ersetzen keine Pentester - wir entwickeln benutzerdefinierte Tools, Erkennungs- & Exploit-Module, um ihnen etwas Zeit zurückzugeben, um tiefer zu graben, Shells zu öffnen und Spaß zu haben.

Fehlender Root-Standort

Bei der Konfiguration des Nginx-Servers spielt die root-Direktive eine entscheidende Rolle, indem sie das Basisverzeichnis definiert, aus dem Dateien bereitgestellt werden. Betrachten Sie das folgende Beispiel:

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. Dieses Setup 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 / {...}). Dieses Weglassen bedeutet, dass die Stammrichtlinie global gilt und Anfragen an den Stamm-Pfad / ermöglicht, auf Dateien unter /etc/nginx zuzugreifen.

Aus dieser Konfiguration ergibt sich eine kritische Sicherheitsüberlegung. Eine einfache GET-Anfrage, wie z.B. 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 z.B. /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üsselte Anmeldeinformationen, die für die HTTP-Basisauthentifizierung verwendet werden.

Alias LFI Fehlkonfiguration

In den Konfigurationsdateien von Nginx ist eine genaue Prüfung der "location"-Direktiven erforderlich. Eine Sicherheitslücke namens Local File Inclusion (LFI) kann unbeabsichtigt durch eine Konfiguration eingeführt werden, die der folgenden ähnelt:

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 aufgelöst wird. Diese Schwachstelle ermöglicht es Angreifern, Dateien aus dem Dateisystem des Servers abzurufen, auf die über das Web nicht zugegriffen werden sollte.

Um diese Schwachstelle zu mildern, sollte die Konfiguration angepasst werden:

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

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

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Unsicherer Variablengebrauch / HTTP-Anforderungsaufteilung

Verwundbare Variablen $uri und $document_uri und dies kann durch Ersetzen durch $request_uri behoben werden.

Ein Regex kann auch verwundbar sein wie:

location ~ /docs/([^/])? { … $1 … } - Verwundbar

location ~ /docs/([^/\s])? { … $1 … } - Nicht verwundbar (Überprüfung von Leerzeichen)

location ~ /docs/(.*)? { … $1 … } - Nicht verwundbar

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) bedeuten neue Zeichen in HTTP-Anfragen, und ihre URL-codierten Formen werden als %0d%0a dargestellt. Wenn Sie diese Zeichen in einer Anfrage (z. B. http://localhost/%0d%0aDetectify:%20clrf) an einen falsch konfigurierten Server einschließen, führt dies dazu, dass der Server einen neuen Header mit dem Namen Detectify ausgibt. Dies geschieht, weil die $uri-Variable die URL-codierten Zeilenumbruchszeichen 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-Injektion 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 das erste als "X" zurückgegeben, da X eine beliebige HTTP-Methode ist, und das 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.

Weitere Beispiele zur Erkennung wären:

  • 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 so gesetzt ist wie im endgültigen URL.

location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}

  • Beachten Sie erneut, wie $uri in der URL (dieses Mal innerhalb eines Parameters) enthalten ist

location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
proxy_pass http://$back;

  • Jetzt in AWS S3

location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}

Jede Variable

Es wurde festgestellt, dass vom Benutzer bereitgestellte Daten unter bestimmten Umständen als Nginx-Variable behandelt werden könnten. Die Ursache dieses Verhaltens bleibt etwas rätselhaft, ist jedoch weder selten noch einfach zu überprüfen. Diese Anomalie wurde in einem Sicherheitsbericht auf HackerOne hervorgehoben, der hier eingesehen werden kann. Eine weitere Untersuchung der Fehlermeldung führte zur Identifizierung ihres Auftretens innerhalb des SSI-Filtermoduls des Nginx-Quellcodes, wobei Server-seitige Includes (SSI) als Wurzelursache identifiziert wurden.

Um diese Fehlkonfiguration zu erkennen, kann der folgende Befehl ausgeführt werden, der das Setzen eines Referrer-Headers beinhaltet, um das Drucken von Variablen zu testen:

$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’

Scans für diese Fehlkonfigurationen auf verschiedenen Systemen haben mehrere Fälle aufgedeckt, in denen Nginx-Variablen von einem Benutzer ausgegeben werden könnten. Allerdings deutet eine Abnahme der anfälligen Fälle darauf hin, dass Bemühungen zur Behebung dieses Problems teilweise erfolgreich waren.

Lesen der Rohantwort des Back-Ends

Nginx bietet eine Funktion über proxy_pass, die es ermöglicht, Fehler und HTTP-Header, die vom Back-End erzeugt werden, abzufangen, um interne Fehlermeldungen und Header zu verbergen. Dies wird erreicht, indem Nginx benutzerdefinierte Fehlerseiten als Antwort auf Backend-Fehler bereitstellt. Herausforderungen entstehen jedoch, wenn Nginx eine ungültige HTTP-Anfrage erhält. Eine solche Anfrage wird wie empfangen an das Back-End weitergeleitet, und die Rohantwort des Back-Ends wird dann direkt an den Client gesendet, ohne das Eingreifen von Nginx.

Betrachten Sie ein Beispiel-Szenario, das eine uWSGI-Anwendung betrifft:

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 Direktiven in der Nginx-Konfiguration verwendet:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}

  • proxy_intercept_errors: Diese Direktive ermöglicht es Nginx, eine benutzerdefinierte Antwort für Backend-Antworten mit einem Statuscode größer als 300 zu senden. Sie stellt sicher, dass für unsere Beispiel-uWSGI-Anwendung eine 500 Error-Antwort abgefangen und von Nginx behandelt wird.

  • proxy_hide_header: Wie der Name schon sagt, verbirgt diese Direktive bestimmte HTTP-Header vor dem Client, um die Privatsphäre und Sicherheit zu erhöhen.

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-Backend-Antworten, einschließlich geheimer Header und Fehlermeldungen.

merge_slashes auf aus

Standardmäßig ist die merge_slashes-Direktive von Nginx auf on gesetzt, was mehrere Schrägstriche in einer URL in einen einzelnen Schrägstrich komprimiert. Diese Funktion kann, obwohl sie die URL-Verarbeitung optimiert, versehentlich Schwachstellen in Anwendungen hinter Nginx verbergen, insbesondere solche, die anfällig für lokale Dateieinschluss (LFI)-Angriffe sind. Die Sicherheitsexperten Danny Robinson und Rotem Bar haben die potenziellen Risiken dieses Standardverhaltens hervorgehoben, insbesondere wenn Nginx als Reverse-Proxy fungiert.

Um solche Risiken zu minimieren, wird empfohlen, die merge_slashes-Direktive auszuschalten für Anwendungen, die anfällig für diese Schwachstellen sind. Dadurch wird sichergestellt, dass Nginx Anfragen an die Anwendung weiterleitet, ohne die URL-Struktur zu ändern und somit keine zugrunde liegenden Sicherheitsprobleme zu maskieren.

Für weitere Informationen siehe Danny Robinson und Rotem Bar.

Bösartige Antwortheader

Wie in diesem Bericht dargestellt, 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 der Dokumentation überprüfen:

  • X-Accel-Redirect: Gibt Nginx an, eine Anfrage intern an einen bestimmten Ort umzuleiten.

  • X-Accel-Buffering: Steuert, ob Nginx die Antwort zwischenspeichern 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: Begrenzt die Übertragungsrate für Antworten, wenn X-Accel-Redirect verwendet wird.

Zum Beispiel wird der Header X-Accel-Redirect eine interne Weiterleitung in Nginx verursachen. Wenn also eine Nginx-Konfiguration mit etwas wie root / und einer Antwort vom Webserver mit X-Accel-Redirect: .env vorliegt, sendet Nginx den Inhalt von /.env (Pfadtraversierung).

Standardwert in Map-Direktive

In der Nginx-Konfiguration spielt die map-Direktive oft eine Rolle bei der Autorisierungssteuerung. Ein häufiger Fehler besteht darin, keinen Standardwert anzugeben, was zu unbefugtem Zugriff führen könnte. Zum Beispiel:

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";
}
}

Ohne ein default kann ein bösartiger Benutzer die Sicherheit umgehen, indem er auf eine undefinierte URI innerhalb von /map-poc zugreift. Das Nginx-Handbuch 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 DNS-Server kennt, der von Nginx verwendet wird, 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 localhost (127.0.0.1) für die DNS-Auflösung verwendet. Nginx ermöglicht die Angabe eines DNS-Servers wie folgt:

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 verhindern.

proxy_set_header Upgrade & Connection

Wenn der Nginx-Server so konfiguriert ist, dass die Upgrade- und Connection-Header weitergeleitet werden, könnte ein h2c Smuggling-Angriff durchgeführt werden, um auf geschützte/interne Endpunkte zuzugreifen.

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.

Beispiel einer anfälligen Konfiguration zum Stehlen von /flag von hier:

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;
}

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.

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 diskutierten Fehlkonfigurationen einzurichten und selbst nach ihnen zu suchen!

https://github.com/detectify/vulnerable-nginx

Tools für statische Analyse

GIXY

Gixy ist ein Tool zur Analyse der Nginx-Konfiguration. Das Hauptziel von Gixy ist es, Sicherheitsfehler zu verhindern und die Fehlererkennung zu automatisieren.

Nginxpwner

Nginxpwner ist ein einfaches Tool, um nach gängigen Nginx-Fehlkonfigurationen und Sicherheitslücken zu suchen.

Referenzen

Sofort einsatzbereite Einrichtung für Schwachstellenbewertung & Penetrationstests. Führen Sie einen vollständigen Pentest von überall aus mit 20+ Tools & Funktionen durch, die von der Aufklärung bis zum Bericht reichen. Wir ersetzen keine Pentester - wir entwickeln benutzerdefinierte Tools, Erkennungs- & Exploit-Module, um ihnen etwas Zeit zu geben, tiefer zu graben, Shells zu öffnen und Spaß zu haben.

Erfahren Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

PreviousMoodleNextPHP Tricks

Last updated