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

# Nginx

<details>

<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Inne sposoby wsparcia HackTricks:

* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* Kup [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>

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

**Natychmiastowa konfiguracja do oceny podatności i testów penetracyjnych**. Uruchom pełne testy penetracyjne z dowolnego miejsca za pomocą ponad 20 narzędzi i funkcji, które obejmują rozpoznanie, aż po raportowanie. Nie zastępujemy pentesterów - rozwijamy niestandardowe narzędzia, moduły wykrywania i eksploatacji, aby umożliwić im zagłębienie się głębiej, zdobycie powłok i dobrą zabawę.

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

## Brakujące miejsce root <a href="#missing-root-location" id="missing-root-location"></a>

Podczas konfigurowania serwera Nginx, dyrektywa **root** odgrywa kluczową rolę, definiując katalog podstawowy, z którego są serwowane pliki. Rozważ poniższy przykład:
```bash
server {
root /etc/nginx;

location /hello.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:8080/;
}
}
```
W tej konfiguracji `/etc/nginx` jest określony jako katalog główny. Ta konfiguracja umożliwia dostęp do plików w określonym katalogu głównym, takich jak `/hello.txt`. Jednakże ważne jest zauważenie, że zdefiniowana jest tylko określona lokalizacja (`/hello.txt`). Brak konfiguracji dla lokalizacji głównej (`location / {...}`). Ta omissja oznacza, że dyrektywa root jest stosowana globalnie, umożliwiając żądania do ścieżki głównej `/` w celu uzyskania dostępu do plików w `/etc/nginx`.

Z tej konfiguracji wynika istotne zagrożenie dla bezpieczeństwa. Proste żądanie `GET`, takie jak `GET /nginx.conf`, może ujawnić wrażliwe informacje poprzez udostępnienie pliku konfiguracyjnego Nginx znajdującego się w `/etc/nginx/nginx.conf`. Ustawienie roota na mniej wrażliwy katalog, np. `/etc`, może zmniejszyć to ryzyko, ale nadal może umożliwiać niezamierzony dostęp do innych istotnych plików, w tym innych plików konfiguracyjnych, logów dostępu, a nawet zaszyfrowanych poświadczeń używanych do autoryzacji podstawowej protokołu HTTP.

## Konfiguracja Alias LFI <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>

W plikach konfiguracyjnych Nginx konieczna jest dokładna inspekcja dyrektyw "location". Podatność znana jako Local File Inclusion (LFI) może zostać nieumyślnie wprowadzona poprzez konfigurację, która przypomina poniższe:
```
location /imgs {
alias /path/images/;
}
```
Ta konfiguracja jest podatna na ataki LFI ze względu na to, że serwer interpretuje żądania takie jak `/imgs../flag.txt` jako próbę dostępu do plików poza zamierzonym katalogiem, efektywnie rozwiązując się do `/path/images/../flag.txt`. Ta wada pozwala atakującym na pobieranie plików z systemu plików serwera, do których nie powinno być dostępu przez sieć.

Aby złagodzić tę podatność, konfiguracja powinna zostać dostosowana do:
```
location /imgs/ {
alias /path/images/;
}
```
Więcej informacji: [https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/](https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/)

Testy Accunetix:
```
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
```
## Niebezpieczne ograniczenie ścieżki <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>

Sprawdź następującą stronę, aby dowiedzieć się, jak ominąć dyrektywy takie jak:
```plaintext
location = /admin {
deny all;
}

location = /admin/ {
deny all;
}
```
## Niewłaściwe użycie zmiennej / Podział żądania HTTP <a href="#niewłaściwe-użycie-zmiennej" id="niewłaściwe-użycie-zmiennej"></a>

{% hint style="danger" %}
Narażone zmienne `$uri` i `$document_uri` mogą zostać naprawione poprzez ich zastąpienie przez `$request_uri`.

Regex może również być narażony, na przykład:

`location ~ /docs/([^/])? { … $1 … }` - Narażone&#x20;

`location ~ /docs/([^/\s])? { … $1 … }` - Nie narażone (sprawdzanie spacji)

`location ~ /docs/(.*)? { … $1 … }`  - Nie narażone
{% endhint %}

Przykładem podatności w konfiguracji Nginx jest:
```
location / {
return 302 https://example.com$uri;
}
```
Znaki \r (powrót karetki) i \n (nowa linia) oznaczają nowe znaki w żądaniach HTTP, a ich zapis w postaci URL-encoded to `%0d%0a`. Umieszczenie tych znaków w żądaniu (np. `http://localhost/%0d%0aDetectify:%20clrf`) do źle skonfigurowanego serwera skutkuje wydaniem przez serwer nowego nagłówka o nazwie `Detectify`. Dzieje się tak, ponieważ zmienna $uri dekoduje URL-encoded nowe znaki, co prowadzi do nieoczekiwanego nagłówka w odpowiedzi:
```
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
```
Dowiedz się więcej o ryzyku wstrzykiwania CRLF i podziału odpowiedzi na [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/).

Ta technika jest również [**wyjaśniona w tej prezentacji**](https://www.youtube.com/watch?v=gWQyWdZbdoY\&list=PL0xCSYnG\_iTtJe2V6PQqamBF73n7-f1Nr\&index=77) z przykładami podatności i mechanizmami wykrywania. Na przykład, aby wykryć tę błędną konfigurację z perspektywy blackbox, można użyć tych żądań:

* `https://example.com/%20X` - Dowolny kod HTTP
* `https://example.com/%20H` - 400 Bad Request

Jeśli jest podatny, pierwsze żądanie zwróci "X" jako dowolną metodę HTTP, a drugie spowoduje błąd, ponieważ H nie jest prawidłową metodą. Serwer otrzyma coś w rodzaju: `GET / H HTTP/1.1`, co spowoduje błąd.

Inne przykłady wykrywania to:

* `http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x` - Dowolny kod HTTP
* `http://company.tld/%20HTTP/1.1%0D%0AHost:%20x` - 400 Bad Request

Niektóre znalezione podatne konfiguracje przedstawione w tej prezentacji to:

* Zauważ, jak **`$uri`** jest ustawione tak, jak jest, w końcowym adresie URL.
```
location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
```
* Zauważ, jak ponownie **`$uri`** znajduje się w adresie URL (tym razem wewnątrz parametru)
```
location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
proxy_pass http://$back;
```
* Teraz w AWS S3
```
location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}
```
### Dowolna zmienna

Odkryto, że **dane dostarczone przez użytkownika** mogą być traktowane jako **zmienna Nginx** w określonych okolicznościach. Przyczyna tego zachowania pozostaje w pewnym sensie niejasna, ale nie jest to rzadkie ani proste do zweryfikowania. To nietypowe zjawisko zostało podkreślone w raporcie bezpieczeństwa na HackerOne, który można zobaczyć [tutaj](https://hackerone.com/reports/370094). Dalsze dochodzenie w sprawie komunikatu o błędzie doprowadziło do zidentyfikowania jego wystąpienia w [module filtru SSI kodu źródłowego Nginx-a](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), wskazując na Server Side Includes (SSI) jako główną przyczynę.

Aby **wykryć tę błędną konfigurację**, można wykonać poniższą komendę, która polega na ustawieniu nagłówka referer w celu przetestowania drukowania zmiennej:
```bash
$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’
```
Skanowania dla tej konfiguracji na różnych systemach ujawniły wiele przypadków, gdzie zmienne Nginx mogły być wydrukowane przez użytkownika. Jednakże spadek liczby podatnych przypadków sugeruje, że wysiłki mające na celu załatanie tego problemu były w pewnym stopniu skuteczne.

## Odczyt surowej odpowiedzi z backendu

Nginx oferuje funkcję poprzez `proxy_pass`, która pozwala na przechwytywanie błędów i nagłówków HTTP generowanych przez backend, mając na celu ukrycie wewnętrznych komunikatów o błędach i nagłówków. Jest to osiągane poprzez serwowanie Nginx stron błędów niestandardowych w odpowiedzi na błędy backendu. Jednakże pojawiają się wyzwania, gdy Nginx napotyka nieprawidłowe żądanie HTTP. Takie żądanie jest przekazywane do backendu w otrzymanej postaci, a surowa odpowiedź backendu jest następnie bezpośrednio wysyłana do klienta bez interwencji Nginx. 

Rozważmy przykładowy scenariusz dotyczący aplikacji uWSGI:
```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!"]
```
Aby zarządzać tym, używane są konkretne dyrektywy w konfiguracji Nginx:
```
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): Ta dyrektywa umożliwia Nginxowi obsługę niestandardowej odpowiedzi dla odpowiedzi z backendu z kodem stanu większym niż 300. Zapewnia, że dla naszej przykładowej aplikacji uWSGI odpowiedź `500 Error` jest przechwytywana i obsługiwana przez Nginx.
* [**proxy\_hide\_header**](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_hide\_header): Jak sugeruje nazwa, ta dyrektywa ukrywa określone nagłówki HTTP przed klientem, zwiększając prywatność i bezpieczeństwo.

Gdy zostanie wysłane poprawne żądanie `GET`, Nginx przetwarza je normalnie, zwracając standardową odpowiedź błędu, nie ujawniając żadnych tajnych nagłówków. Jednak nieprawidłowe żądanie HTTP omija ten mechanizm, co skutkuje ujawnieniem surowych odpowiedzi z backendu, w tym tajnych nagłówków i komunikatów błędów.

## merge\_slashes ustawione na off

Domyślnie dyrektywa **`merge_slashes` Nginxa** jest ustawiona na **`on`**, co spowoduje skompresowanie wielokrotnych ukośników w adresie URL do pojedynczego ukośnika. Ta funkcja, podczas upraszczania przetwarzania adresów URL, może niechcący ukrywać podatności w aplikacjach za Nginx, zwłaszcza tych podatnych na ataki lokalnego dołączania plików (LFI). Eksperci ds. bezpieczeństwa **Danny Robinson i Rotem Bar** zwrócili uwagę na potencjalne ryzyko związane z tym domyślnym zachowaniem, zwłaszcza gdy Nginx działa jako odwrotny proxy.

Aby zmniejszyć takie ryzyko, zaleca się **wyłączenie dyrektywy `merge_slashes`** dla aplikacji podatnych na te podatności. Zapewnia to, że Nginx przekazuje żądania do aplikacji bez zmiany struktury adresu URL, nie maskując żadnych istniejących problemów związanych z bezpieczeństwem.

Aby uzyskać więcej informacji, sprawdź [Danny Robinson i Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d).

### **Złośliwe nagłówki odpowiedzi**

Jak pokazano w [**tym opisie**](https://mizu.re/post/cors-playground), istnieją pewne nagłówki, które jeśli znajdują się w odpowiedzi z serwera WWW, zmienią zachowanie serwera proxy Nginx. Możesz sprawdzić je [**w dokumentacji**](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/):

* `X-Accel-Redirect`: Wskazuje Nginxowi wewnętrzne przekierowanie żądania do określonej lokalizacji.
* `X-Accel-Buffering`: Kontroluje, czy Nginx powinien buforować odpowiedź, czy nie.
* `X-Accel-Charset`: Ustawia zestaw znaków dla odpowiedzi przy użyciu X-Accel-Redirect.
* `X-Accel-Expires`: Ustawia czas wygaśnięcia odpowiedzi przy użyciu X-Accel-Redirect.
* `X-Accel-Limit-Rate`: Ogranicza szybkość transferu odpowiedzi przy użyciu X-Accel-Redirect.

Na przykład nagłówek **`X-Accel-Redirect`** spowoduje wewnętrzne **przekierowanie** w Nginx. Dlatego posiadanie konfiguracji Nginx z czymś takim jak **`root /`** i odpowiedź z serwera WWW z **`X-Accel-Redirect: .env`** spowoduje, że Nginx wyśle zawartość **`/.env`** (Przechodzenie ścieżką).

### **Wartość domyślna w dyrektywie Map**

W **konfiguracji Nginx**, dyrektywa `map` często odgrywa rolę w **kontroli autoryzacji**. Powszechnym błędem jest nieokreślenie **wartości domyślnej**, co może prowadzić do nieautoryzowanego dostępu. Na przykład:
```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";
}
}
```
Bez `default`, **złośliwy użytkownik** może ominąć zabezpieczenia, uzyskując dostęp do **niezdefiniowanego URI** wewnątrz `/map-poc`. [Podręcznik Nginx](https://nginx.org/en/docs/http/ngx\_http\_map\_module.html) zaleca ustawienie **wartości domyślnej**, aby uniknąć takich problemów.

### **Podatność na podszywanie DNS**

Podszywanie DNS wobec Nginx jest możliwe w określonych warunkach. Jeśli atakujący zna **serwer DNS** używany przez Nginx i może przechwycić jego zapytania DNS, może podszyć się pod rekordy DNS. Ta metoda jednak nie działa, jeśli Nginx jest skonfigurowany do korzystania z **localhost (127.0.0.1)** do rozwiązywania nazw DNS. Nginx pozwala określić serwer DNS w następujący sposób:
```yaml
resolver 8.8.8.8;
```
### **Dyrektywy `proxy_pass` i `internal`**

Dyrektywa **`proxy_pass`** jest wykorzystywana do przekierowywania żądań do innych serwerów, zarówno wewnętrznie, jak i zewnętrznie. Dyrektywa **`internal`** zapewnia, że określone lokalizacje są dostępne tylko w obrębie Nginx. Chociaż te dyrektywy same w sobie nie stanowią podatności, ich konfiguracja wymaga dokładnego zbadania, aby zapobiec lukom w zabezpieczeniach.

## proxy\_set\_header Upgrade & Connection

Jeśli serwer nginx jest skonfigurowany do przekazywania nagłówków Upgrade i Connection, atak [**h2c Smuggling**](../../pentesting-web/h2c-smuggling.md) może zostać przeprowadzony w celu uzyskania dostępu do chronionych/wewnętrznych punktów końcowych.

{% hint style="danger" %}
Ta podatność pozwoliłaby atakującemu **ustanowić bezpośrednie połączenie z punktem końcowym `proxy_pass`** (`http://backend:9999` w tym przypadku), którego zawartość nie będzie sprawdzana przez nginx.
{% endhint %}

Przykład podatnej konfiguracji do kradzieży `/flag` znajdziesz [tutaj](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" %}
Zauważ, że nawet jeśli `proxy_pass` wskazywał na określoną **ścieżkę**, taką jak `http://backend:9999/socket.io`, połączenie zostanie nawiązane z `http://backend:9999`, więc możesz **skontaktować się z dowolną inną ścieżką wewnątrz tego wewnętrznego punktu końcowego. Dlatego nie ma znaczenia, czy ścieżka jest określona w adresie URL proxy\_pass.**
{% endhint %}

## Wypróbuj to samodzielnie

Detectify utworzył repozytorium na GitHubie, gdzie możesz użyć Dockera do skonfigurowania własnego podatnego serwera testowego Nginx z niektórymi błędami konfiguracji omówionymi w tym artykule i spróbować je znaleźć samodzielnie!

[https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx)

## Narzędzia analizy statycznej

### [GIXY](https://github.com/yandex/gixy)

Gixy to narzędzie do analizy konfiguracji Nginx. Głównym celem Gixy jest zapobieganie błędom konfiguracji związanych z bezpieczeństwem i automatyzacja wykrywania wad.

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

Nginxpwner to proste narzędzie do wyszukiwania powszechnych błędów konfiguracyjnych i podatności Nginx.

## Odnośniki

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

**Natychmiastowa dostępność konfiguracji do oceny podatności i testów penetracyjnych**. Uruchom pełny test penetracyjny z dowolnego miejsca za pomocą ponad 20 narzędzi i funkcji, które obejmują rozpoznanie, raportowanie. Nie zastępujemy testerów penetracyjnych - rozwijamy niestandardowe narzędzia, moduły wykrywania i eksploatacji, aby umożliwić im zagłębienie się głębiej, zdobycie dostępu i dobrą zabawę.

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

<details>

<summary><strong>Zacznij od zera i zostań ekspertem AWS hackingu z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Inne sposoby wsparcia HackTricks:

* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>