Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-19 09:34:03 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/pentesting-web/nginx.md
Translator workflow 6af5d4e1a0 Translated to German
2024-02-10 15:36:32 +00:00

17 KiB
Raw Blame History

Nginx

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

Andere Möglichkeiten, HackTricks zu unterstützen:

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:

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/

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

{% content-ref url="../../pentesting-web/proxy-waf-protections-bypass.md" %} 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/.

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 eingesehen werden kann. Eine weitere Untersuchung der Fehlermeldung führte zur Identifizierung ihres Auftretens im SSI-Filtermodul des Nginx-Codebases, 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:

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

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

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:

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

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

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

Statische Analysetools

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

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

Referenzen

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: