hacktricks/network-services-pentesting/pentesting-web/nginx.md

# Nginx

<details>

<summary><strong>Lernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Andere Möglichkeiten, HackTricks zu unterstützen:

* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen 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-Merch**](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 einreichen.

</details>

<figure><img src="../../.gitbook/assets/image (14) (1).png" alt=""><figcaption></figcaption></figure>

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

{% embed url="https://pentest-tools.com/" %}

## Fehlender Root-Standort <a href="#missing-root-location" id="missing-root-location"></a>

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:
```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. 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 <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>

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/](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 <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>

Ü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;
}
```
## Unsicherer Variablengebrauch / HTTP-Anforderungsaufteilung <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>

{% hint style="danger" %}
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
{% endhint %}

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/](https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/).

Diese Technik wird auch in diesem Vortrag [**erklärt**](https://www.youtube.com/watch?v=gWQyWdZbdoY\&list=PL0xCSYnG\_iTtJe2V6PQqamBF73n7-f1Nr\&index=77) 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](https://hackerone.com/reports/370094) eingesehen werden kann. Eine weitere Untersuchung der Fehlermeldung führte zur Identifizierung ihres Auftretens innerhalb des [SSI-Filtermoduls des Nginx-Quellcodes](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx\_http\_ssi\_filter\_module.c#L365), 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:
```bash
$ 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:
```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 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**](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 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**](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, 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](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d).

### **Bösartige Antwortheader**

Wie in [**diesem Bericht**](https://mizu.re/post/cors-playground) 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**](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/) ü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:
```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 ein `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 **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:
```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 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**](../../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 einer anfälligen 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 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.**
{% endhint %}

## 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](https://github.com/detectify/vulnerable-nginx)

## Tools für statische Analyse

### [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 Fehlererkennung zu automatisieren.

### [Nginxpwner](https://github.com/stark0de/nginxpwner)

Nginxpwner ist ein einfaches Tool, um nach gängigen Nginx-Fehlkonfigurationen und Sicherheitslücken 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)

<figure><img src="../../.gitbook/assets/image (14) (1).png" alt=""><figcaption></figcaption></figure>

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

{% embed url="https://pentest-tools.com/" %}

<details>

<summary><strong>Erfahren Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Andere Möglichkeiten, HackTricks zu unterstützen:

* Wenn Sie Ihr **Unternehmen in HackTricks bewerben** 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-Merch**](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 einreichen.

</details>