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

# Nginx

<details>

<summary><strong>Leer AWS-hacking van nul tot held met</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Ander maniere om HackTricks te ondersteun:

* As jy jou **maatskappy in HackTricks wil adverteer** of **HackTricks in PDF wil aflaai**, kyk na die [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Kry die [**amptelike PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Ontdek [**The PEASS Family**](https://opensea.io/collection/the-peass-family), ons versameling eksklusiewe [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Deel jou hacking-truuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-repos.

</details>

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

**Onmiddellik beskikbare opset vir kwesbaarheidsassessering en penetrasietoetsing**. Voer 'n volledige pentest uit van enige plek met 20+ gereedskap en funksies wat strek van rekognisering tot verslagdoening. Ons vervang nie pentesters nie - ons ontwikkel aangepaste gereedskap, opsporings- en uitbuitingsmodules om hulle 'n bietjie tyd te gee om dieper te graaf, skulpe te kraak en pret te hê.

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

## Ontbrekende hooflokasie <a href="#missing-root-location" id="missing-root-location"></a>

## **Essensiële beginsels van die konfigurasie van die Nginx-hoofgids**

Wanneer die Nginx-bediener gekonfigureer word, speel die **root-aanwysing** 'n kritieke rol deur die basisgids te definieer waarvandaan lêers bedien word. Oorweeg die volgende voorbeeld:
```bash
server {
root /etc/nginx;

location /hello.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:8080/;
}
}
```
In hierdie konfigurasie word `/etc/nginx` as die hoofgids aangewys. Hierdie opset maak toegang tot lêers binne die gespesifiseerde hoofgids moontlik, soos `/hello.txt`. Dit is egter belangrik om op te let dat slegs 'n spesifieke ligging (`/hello.txt`) gedefinieer is. Daar is geen konfigurasie vir die hoofligging (`location / {...}`) nie. Hierdie weglatings beteken dat die hoofopdrag globaal van toepassing is, wat beteken dat versoek na die hoofpad `/` toegang tot lêers onder `/etc/nginx` kan verkry.

'n Kritieke veiligheidsoorweging ontstaan as gevolg van hierdie konfigurasie. 'n Eenvoudige `GET` versoek, soos `GET /nginx.conf`, kan sensitiewe inligting blootstel deur die Nginx konfigurasie-lêer wat by `/etc/nginx/nginx.conf` geleë is, te bedien. Deur die hoofgids na 'n minder sensitiewe gids, soos `/etc`, te stel, kan hierdie risiko verminder word, maar dit kan steeds onbedoelde toegang tot ander kritieke lêers moontlik maak, insluitend ander konfigurasie-lêers, toegangsjoernale en selfs versleutelde geloofsbriewe wat gebruik word vir HTTP basiese outentifikasie.

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

In die konfigurasie lêers van Nginx is 'n noukeurige ondersoek van die "ligging" opdragte nodig. 'n Kwesbaarheid wat bekend staan as Plaaslike Lêer Insluiting (LFI) kan onbedoeld deur 'n konfigurasie soos die volgende ingevoer word:
```
location /imgs {
alias /path/images/;
}
```
Hierdie konfigurasie is vatbaar vir LFI-aanvalle as gevolg van die bedieners wat versoek soos `/imgs../flag.txt` interpreteer as 'n poging om lêers buite die bedoelde gids te benader, wat effektief oplos na `/path/images/../flag.txt`. Hierdie fout stel aanvallers in staat om lêers van die bediener se lêersisteem te herwin wat nie toeganklik behoort te wees via die web nie.

Om hierdie kwesbaarheid te verminder, moet die konfigurasie aangepas word na:
```
location /imgs/ {
alias /path/images/;
}
```
Meer inligting: [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 toetse:
```
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
```
## Onveilige padbeperking <a href="#onveilige-variabele-gebruik" id="onveilige-variabele-gebruik"></a>

Kyk na die volgende bladsy om te leer hoe om riglyne soos die volgende te omseil:
```plaintext
location = /admin {
deny all;
}

location = /admin/ {
deny all;
}
```
## Onveilige gebruik van veranderlikes <a href="#onveilige-gebruik-van-veranderlikes" id="onveilige-gebruik-van-veranderlikes"></a>

'n Kwesbaarheid in die Nginx-konfigurasie word gedemonstreer deur die volgende voorbeeld:
```
location / {
return 302 https://example.com$uri;
}
```
Die karakters \r (Carriage Return) en \n (Line Feed) dui nuwe lyn karakters aan in HTTP-versoeke, en hul URL-gekodeerde vorms word voorgestel as `%0d%0a`. Deur hierdie karakters in 'n versoek in te sluit (bv. `http://localhost/%0d%0aDetectify:%20clrf`) na 'n verkeerd gekonfigureerde bediener, sal die bediener 'n nuwe kop met die naam `Detectify` uitreik. Dit gebeur omdat die $uri-veranderlike die URL-gekodeerde nuwe lyn karakters ontkodeer, wat lei tot 'n onverwagte kop in die respons:
```
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
```
Leer meer oor die risiko's van CRLF-injeksie en responsplitsing by [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/).

### Enige veranderlike

Daar is ontdek dat **gebruikersverskafte data** as 'n **Nginx-veranderlike** behandel kan word onder sekere omstandighede. Die oorsaak van hierdie gedrag bly ietwat raaiselagtig, maar dit is nie selde of maklik om te verifieer nie. Hierdie anomalie is uitgelig in 'n veiligheidsverslag op HackerOne, wat hier besigtig kan word [hier](https://hackerone.com/reports/370094). Verdere ondersoek na die foutboodskap het gelei tot die identifikasie van sy voorkoms binne die [SSI-filtermodule van Nginx se kodebasis](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), wat Server Side Includes (SSI) as die hoofoor-saak aanwys.

Om hierdie verkeerde konfigurasie op te spoor, kan die volgende opdrag uitgevoer word, wat die instelling van 'n verwysingskop behels om vir veranderlike druk te toets:
```bash
$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’
```
Skanderings vir hierdie verkeerde konfigurasie oor stelsels het verskeie gevalle aan die lig gebring waar Nginx-veranderlikes deur 'n gebruiker gedruk kon word. Nietemin, 'n afname in die aantal kwesbare gevalle dui daarop dat pogings om hierdie probleem reg te stel, enigsins suksesvol was.

## Lewerings van onbewerkte agterste antwoorde

Nginx bied 'n funksie deur middel van `proxy_pass` wat die onderskepping van foute en HTTP-koppele wat deur die agterste vervaardig word, moontlik maak, met die doel om interne foutboodskappe en koppele te verberg. Dit word bereik deur Nginx aangepaste foutbladsye as antwoord op agterste foute te bedien. Tog ontstaan uitdagings wanneer Nginx 'n ongeldige HTTP-versoek teëkom. So 'n versoek word soos ontvang na die agterste deurgestuur, en die agterste se onbewerkte antwoord word dan direk na die kliënt gestuur sonder Nginx se tussenkoms.

Oorweeg 'n voorbeeldscenario met 'n uWSGI-toepassing:
```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!"]
```
Om dit te bestuur, word spesifieke riglyne in die Nginx-konfigurasie gebruik:
```
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)**: Hierdie riglyn stel Nginx in staat om 'n aangepaste reaksie te dien vir agterkant reaksies met 'n statuskode groter as 300. Dit verseker dat, vir ons voorbeeld uWSGI-toepassing, 'n `500 Fout` reaksie onderskep en hanteer word deur Nginx.
- **[proxy_hide_header](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_hide_header)**: Soos die naam aandui, verberg hierdie riglyn gespesifiseerde HTTP-koppe van die kliënt, wat privaatheid en veiligheid verbeter.

Wanneer 'n geldige `GET` versoek gemaak word, verwerk Nginx dit normaalweg en gee 'n standaard fout reaksie sonder om enige geheime koppe te onthul. 'n Ongeldige HTTP versoek omseil egter hierdie meganisme, wat lei tot die blootstelling van rou agterkant reaksies, insluitend geheime koppe en foutboodskappe.


## merge\_slashes gestel op off

Standaard is Nginx se **`merge_slashes` riglyn** gestel op **`on`**, wat meervoudige vorentoe slasies in 'n URL saamdruk tot 'n enkele slasie. Hierdie funksie, terwyl dit URL-verwerking stroomlyn, kan onbedoeld kwesbaarhede in toepassings agter Nginx verberg, veral dié wat vatbaar is vir plaaslike lêer insluiting (LFI) aanvalle. Sekuriteitsexperts **Danny Robinson en Rotem Bar** het die potensiële risiko's wat verband hou met hierdie verstekgedrag beklemtoon, veral wanneer Nginx as 'n omgekeerde proksi optree.

Om sulke risiko's te verminder, word dit aanbeveel om die `merge_slashes` riglyn af te skakel vir toepassings wat vatbaar is vir hierdie kwesbaarhede. Dit verseker dat Nginx versoek na die toepassing stuur sonder om die URL-struktuur te verander, en dus nie enige onderliggende veiligheidsprobleme verberg nie.

Vir meer inligting, kyk na [Danny Robinson en Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d).

### **Verstekwaarde in Map Riglyn**

In die **Nginx-konfigurasie** speel die `map` riglyn dikwels 'n rol in **toestemmingsbeheer**. 'n Algemene fout is om nie 'n **verstek** waarde te spesifiseer nie, wat kan lei tot ongemagtigde toegang. Byvoorbeeld:
```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";
}
}
```
Sonder 'n `default`, kan 'n **booswillige gebruiker** sekuriteit omseil deur toegang te verkry tot 'n **ongedefinieerde URI** binne `/map-poc`. [Die Nginx-handleiding](https://nginx.org/en/docs/http/ngx_http_map_module.html) beveel aan dat 'n **verstekwaarde** ingestel word om sulke probleme te voorkom.

### **DNS Spoofing Kwesbaarheid**

DNS-spoofing teen Nginx is moontlik onder sekere omstandighede. As 'n aanvaller die **DNS-bediener** wat deur Nginx gebruik word, ken en sy DNS-navrae kan onderskep, kan hulle DNS-rekords vervals. Hierdie metode is egter ondoeltreffend as Nginx gekonfigureer is om **localhost (127.0.0.1)** vir DNS-oplossing te gebruik. Nginx maak dit moontlik om 'n DNS-bediener as volg te spesifiseer:
```yaml
resolver 8.8.8.8;
```
### **`proxy_pass` en `internal` Direktiewe**

Die **`proxy_pass`**-direktief word gebruik om versoek na ander bedieners te stuur, intern of ekstern. Die **`internal`**-direktief verseker dat sekere areas slegs binne Nginx toeganklik is. Alhoewel hierdie direktiewe nie opsigself kwesbaarhede is nie, vereis hul konfigurasie noukeurige ondersoek om sekuriteitsfoute te voorkom.

## proxy\_set\_header Upgrade & Connection

As die nginx-bediner gekonfigureer is om die Upgrade- en Connection-koptekens oor te dra, kan 'n [**h2c Smuggling-aanval**](../../pentesting-web/h2c-smuggling.md) uitgevoer word om toegang tot beskermde/intern eindpunte te verkry.

{% hint style="danger" %}
Hierdie kwesbaarheid sal 'n aanvaller in staat stel om 'n **direkte verbinding met die `proxy_pass`-eindpunt** (`http://backend:9999` in hierdie geval) te vestig waarvan die inhoud nie deur nginx nagegaan sal word nie.
{% endhint %}

Voorbeeld van 'n kwesbare konfigurasie om `/flag` te steel van [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" %}
Let wel dat selfs as die `proxy_pass` na 'n spesifieke **pad** verwys, soos `http://backend:9999/socket.io`, die verbinding met `http://backend:9999` tot stand gebring sal word, sodat jy **enige ander pad binne daardie interne eindpunt kan kontak. Dit maak dus nie saak of 'n pad gespesifiseer word in die URL van proxy\_pass nie.**
{% endhint %}

## Probeer dit self

Detectify het 'n GitHub-opberging geskep waar jy Docker kan gebruik om jou eie kwesbare Nginx-toetsbediener op te stel met sommige van die verkeerde konfigurasies wat in hierdie artikel bespreek word, en probeer om hulle self te vind!

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

## Statische analisehulpmiddels

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

Gixy is 'n hulpmiddel om Nginx-konfigurasie te analiseer. Die hoofdoel van Gixy is om sekuriteitsverkeerde konfigurasie te voorkom en foutopsporing te outomatiseer.

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

Nginxpwner is 'n eenvoudige hulpmiddel om na algemene Nginx-verkeerde konfigurasies en kwesbaarhede te soek.

## Verwysings

* [**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 (2).png" alt=""><figcaption></figcaption></figure>

**Onmiddellik beskikbare opset vir kwesbaarheidsbeoordeling en penetrasietoetsing**. Voer 'n volledige pentest uit van enige plek met 20+ hulpmiddels & funksies wat vanaf rekognisering tot verslagdoening strek. Ons vervang nie pentesters nie - ons ontwikkel aangepaste hulpmiddels, opsporings- en uitbuitingsmodules om hulle 'n bietjie tyd te gee om dieper te graaf, skulpe te laat spat en pret te hê.

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

<details>

<summary><strong>Leer AWS-hacking van nul tot held met</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Ander maniere om HackTricks te ondersteun:

* As jy wil sien dat jou **maatskappy geadverteer word in HackTricks** of **HackTricks aflaai in PDF-formaat**, kyk na die [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Kry die [**amptelike PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Ontdek [**The PEASS Family**](https://opensea.io/collection/the-peass-family), ons versameling eksklusiewe [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Deel jou haktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-opberge.

</details>