# Nginx {% hint style="success" %} Leer & oefen AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Leer & oefen GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Ondersteun HackTricks * Kyk na die [**subskripsieplanne**](https://github.com/sponsors/carlospolop)! * **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐩 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}
**Kry 'n hacker se perspektief op jou webtoepassings, netwerk, en wolk** **Vind en rapporteer kritieke, exploiteerbare kwesbaarhede met werklike besigheidsimpak.** Gebruik ons 20+ pasgemaakte gereedskap om die aanvaloppervlak te karteer, vind sekuriteitskwessies wat jou toelaat om bevoegdhede te verhoog, en gebruik geoutomatiseerde eksploit om noodsaaklike bewyse te versamel, wat jou harde werk in oortuigende verslae omskep. {% embed url="https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=spons" %} ## Ontbrekende wortel ligging Wanneer jy die Nginx-bediener konfigureer, speel die **wortelrigting** 'n kritieke rol deur die basisgids te definieer waaruit lĂȘers bedien word. Oorweeg die voorbeeld hieronder: ```bash server { root /etc/nginx; location /hello.txt { try_files $uri $uri/ =404; proxy_pass http://127.0.0.1:8080/; } } ``` In hierdie konfigurasie is `/etc/nginx` as die wortelgids aangewys. Hierdie opstelling laat toegang tot lĂȘers binne die gespesifiseerde wortelgids toe, soos `/hello.txt`. Dit is egter belangrik om te noem dat slegs 'n spesifieke ligging (`/hello.txt`) gedefinieer is. Daar is geen konfigurasie vir die wortel ligging nie (`location / {...}`). Hierdie omissie beteken dat die wortelriglyn globaal van toepassing is, wat versoeke na die wortelpad `/` toelaat om lĂȘers onder `/etc/nginx` te benader. 'n Kritieke sekuriteitsoorweging ontstaan uit hierdie konfigurasie. 'n Eenvoudige `GET` versoek, soos `GET /nginx.conf`, kan sensitiewe inligting blootstel deur die Nginx konfigurasielĂȘer wat geleĂ« is by `/etc/nginx/nginx.conf` te bedien. Om die wortel na 'n minder sensitiewe gids, soos `/etc`, in te stel, kan hierdie risiko verminder, maar dit mag steeds onbedoelde toegang tot ander kritieke lĂȘers, insluitend ander konfigurasielĂȘers, toeganglogs en selfs versleutelde akrediteerings wat vir HTTP basiese outentisering gebruik word, toelaat. ## Alias LFI Misconfiguration In die konfigurasielĂȘers van Nginx is 'n noukeurige inspeksie van die "location" riglyne nodig. 'n Kwetsbaarheid bekend as Local File Inclusion (LFI) kan per ongeluk ingevoer word deur 'n konfigurasie wat soos die volgende lyk: ``` location /imgs { alias /path/images/; } ``` Hierdie konfigurasie is geneig tot LFI-aanvalle weens die bediener wat versoeke 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 laat aanvallers toe om lĂȘers van die bediener se lĂȘerstelsel te verkry wat nie via die web toeganklik behoort te wees 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 Kyk na die volgende bladsy om te leer hoe om riglyne soos te omseil: ```plaintext location = /admin { deny all; } location = /admin/ { deny all; } ``` {% content-ref url="../../pentesting-web/proxy-waf-protections-bypass.md" %} [proxy-waf-protections-bypass.md](../../pentesting-web/proxy-waf-protections-bypass.md) {% endcontent-ref %} ## Onveilige gebruik van veranderlikes / HTTP Versoek Splitsing {% hint style="danger" %} Kwetsbare veranderlikes `$uri` en `$document_uri` en dit kan reggestel word deur dit te vervang met `$request_uri`. 'n Regex kan ook kwesbaar wees soos: `location ~ /docs/([^/])? { 
 $1 
 }` - Kwetsbaar `location ~ /docs/([^/\s])? { 
 $1 
 }` - Nie kwesbaar nie (kontroleer spaties) `location ~ /docs/(.*)? { 
 $1 
 }` - Nie kwesbaar nie {% endhint %} 'n Kwetsbaarheid in Nginx-konfigurasie word gedemonstreer deur die voorbeeld hieronder: ``` location / { return 302 https://example.com$uri; } ``` Die karakters \r (Carriage Return) en \n (Line Feed) dui nuwe lyn karakters in HTTP versoeke aan, en hul URL-gecodeerde vorms word voorgestel as `%0d%0a`. Om hierdie karakters in 'n versoek in te sluit (bv. `http://localhost/%0d%0aDetectify:%20clrf`) na 'n verkeerd geconfigureerde bediener lei tot die bediener wat 'n nuwe kop genaamd `Detectify` uitreik. Dit gebeur omdat die $uri veranderlike die URL-gecodeerde nuwe lyn karakters decodeer, wat lei tot 'n onverwagte kop in die antwoord: ``` 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-inspuiting en antwoordsplitsing 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/). Ook hierdie tegniek is [**verduidelik in hierdie praatjie**](https://www.youtube.com/watch?v=gWQyWdZbdoY\&list=PL0xCSYnG\_iTtJe2V6PQqamBF73n7-f1Nr\&index=77) met 'n paar kwesbare voorbeelde en opsporingsmeganismes. Byvoorbeeld, om hierdie miskonfigurasie vanuit 'n swartdoos perspektief op te spoor, kan jy hierdie versoeke gebruik: * `https://example.com/%20X` - Enige HTTP-kode * `https://example.com/%20H` - 400 Bad Request As kwesbaar, sal die eerste terugkeer as "X" is enige HTTP-metode en die tweede sal 'n fout teruggee aangesien H nie 'n geldige metode is nie. So die bediener sal iets soos ontvang: `GET / H HTTP/1.1` en dit sal die fout aktiveer. Nog 'n opsporingsvoorbeeld kan wees: * `http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x` - Enige HTTP-kode * `http://company.tld/%20HTTP/1.1%0D%0AHost:%20x` - 400 Bad Request Sommige gevonde kwesbare konfigurasies wat in daardie praatjie aangebied is, was: * Let op hoe **`$uri`** as is in die finale URL gestel is. ``` location ^~ /lite/api/ { proxy_pass http://lite-backend$uri$is_args$args; } ``` * Let op hoe weer **`$uri`** in die URL is (denke keer binne 'n parameter) ``` location ~ ^/dna/payment { rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break; proxy_pass http://$back; ``` * Nou in AWS S3 ``` location /s3/ { proxy_pass https://company-bucket.s3.amazonaws.com$uri; } ``` ### Enige veranderlike Daar is ontdek dat **gebruikersgeleverde data** onder sekere omstandighede as 'n **Nginx veranderlike** behandel kan word. Die oorsaak van hierdie gedrag bly ietwat ontwykend, maar dit is nie ongewoon of eenvoudig om te verifieer nie. Hierdie anomalie is in 'n sekuriteitsverslag op HackerOne beklemtoon, wat [hier](https://hackerone.com/reports/370094) beskou kan word. 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 oorsaak identifiseer. Om **hierdie miskonfigurasie te ontdek**, kan die volgende opdrag uitgevoer word, wat behels om 'n referer-kop te stel om vir veranderlike druk te toets: ```bash $ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’ ``` Scans vir hierdie miskonfigurasie oor stelsels het verskeie gevalle onthul waar Nginx veranderlikes deur 'n gebruiker gedruk kon word. 'n Afname in die aantal kwesbare gevalle dui egter daarop dat pogings om hierdie probleem reg te stel, tot 'n mate suksesvol was. ## Rau backend respons lees Nginx bied 'n funksie deur middel van `proxy_pass` wat die onderskepping van foute en HTTP-koppe wat deur die backend geproduseer word, moontlik maak, met die doel om interne foutboodskappe en koppe te verberg. Dit word bereik deurdat Nginx pasgemaakte foutbladsye dien in reaksie op backend-foute. Uitdagings ontstaan egter wanneer Nginx 'n ongeldige HTTP-versoek teĂ«kom. So 'n versoek word na die backend gestuur soos ontvang, en die backend se rau respons word dan direk aan die kliĂ«nt gestuur sonder Nginx se tussenkoms. Overweeg 'n voorbeeldscenario wat 'n uWSGI-toepassing betrek: ```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 pasgemaakte antwoord te bedien vir agtergrond antwoorde met 'n statuskode groter as 300. Dit verseker dat, vir ons voorbeeld uWSGI-toepassing, 'n `500 Error` antwoord 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-koptekste van die kliĂ«nt, wat privaatheid en sekuriteit verbeter. Wanneer 'n geldige `GET` versoek gemaak word, verwerk Nginx dit normaalweg, en keer 'n standaard foutantwoord terug sonder om enige geheime koptekste te onthul. 'n Ongeldige HTTP-versoek omseil egter hierdie meganisme, wat lei tot die blootstelling van rou agtergrond antwoorde, insluitend geheime koptekste en foutboodskappe. ## merge\_slashes op af Standaard is Nginx se **`merge_slashes` riglyn** op **`aan`** gestel, wat verskeie vorentoe-skuinslyne in 'n URL in 'n enkele skuinslyn saampers. Hierdie kenmerk, terwyl dit URL-verwerking stroomlyn, kan onbedoeld kwesbaarhede in toepassings agter Nginx verberg, veral diĂ© wat geneig is tot plaaslike lĂȘerinvoeging (LFI) aanvalle. Sekuriteitskenners **Danny Robinson en Rotem Bar** het die potensiĂ«le risiko's wat met hierdie standaardgedrag geassosieer word, beklemtoon, veral wanneer Nginx as 'n omgekeerde proxy 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 versoeke aan die toepassing deurgee sonder om die URL-struktuur te verander, en dus nie enige onderliggende sekuriteitskwessies te 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). ### **Maclicious Response Headers** Soos getoon in [**hierdie skrywe**](https://mizu.re/post/cors-playground), is daar sekere koptekste wat, indien teenwoordig in die antwoord van die webbediener, die gedrag van die Nginx-proxy sal verander. Jy kan hulle [**in die dokumentasie**](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/) nagaan: * `X-Accel-Redirect`: Dui aan Nginx om 'n versoek intern na 'n gespesifiseerde ligging te herlei. * `X-Accel-Buffering`: Beheer of Nginx die antwoord moet buffere of nie. * `X-Accel-Charset`: Stel die karakterstel vir die antwoord in wanneer X-Accel-Redirect gebruik word. * `X-Accel-Expires`: Stel die vervaldatum vir die antwoord in wanneer X-Accel-Redirect gebruik word. * `X-Accel-Limit-Rate`: Beperk die oordragtempo vir antwoorde wanneer X-Accel-Redirect gebruik word. Byvoorbeeld, die koptekst **`X-Accel-Redirect`** sal 'n interne **herleiding** in die nginx veroorsaak. Dus, om 'n nginx-konfigurasie te hĂȘ met iets soos **`root /`** en 'n antwoord van die webbediener met **`X-Accel-Redirect: .env`** sal maak dat nginx die inhoud van **`/.env`** stuur (Path Traversal). ### **Standaardwaarde in Map Riglyn** In die **Nginx-konfigurasie** speel die `map` riglyn dikwels 'n rol in **autoriseringbeheer**. 'n Algemene fout is om nie 'n **standaard** waarde te spesifiseer nie, wat kan lei tot ongeoorloofde 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"; } } ``` Without a `default`, a **malicious user** kan sekuriteit omseil deur toegang te verkry tot 'n **onbeskryfde URI** binne `/map-poc`. [Die Nginx-handleiding](https://nginx.org/en/docs/http/ngx\_http\_map\_module.html) adviseer om 'n **standaardwaarde** in te stel om sulke probleme te vermy. ### **DNS Spoofing Kwesbaarheid** DNS spoofing teen Nginx is haalbaar onder sekere omstandighede. As 'n aanvaller die **DNS-server** wat deur Nginx gebruik word, ken en sy DNS-vrae kan onderskep, kan hulle DNS-rekords spoof. Hierdie metode is egter ondoeltreffend as Nginx geconfigureer is om **localhost (127.0.0.1)** vir DNS-resolusie te gebruik. Nginx laat toe om 'n DNS-server soos volg te spesifiseer: ```yaml resolver 8.8.8.8; ``` ### **`proxy_pass` en `internal` Direktiewe** Die **`proxy_pass`** direktief word gebruik om versoeke na ander bedieners te herlei, hetsy intern of ekstern. Die **`internal`** direktief verseker dat sekere plekke slegs binne Nginx toeganklik is. Alhoewel hierdie direktiewe nie kwesbaarhede op hul eie is nie, vereis hul konfigurasie sorgvuldige ondersoek om sekuriteitsfoute te voorkom. ## proxy\_set\_header Upgrade & Connection As die nginx bediener geconfigureer is om die Upgrade en Connection headers oor te dra, kan 'n [**h2c Smuggling aanval**](../../pentesting-web/h2c-smuggling.md) uitgevoer word om toegang te verkry tot beskermde/intern eindpunte. {% hint style="danger" %} Hierdie kwesbaarheid sou 'n aanvaller in staat stel om **'n direkte verbinding met die `proxy_pass` eindpunt te vestig** (`http://backend:9999` in hierdie geval) waarvan die inhoud nie deur nginx gaan nagegaan word nie. {% endhint %} Voorbeeld van 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 daarop dat selfs al was die `proxy_pass` op 'n spesifieke **pad** soos `http://backend:9999/socket.io` gewys, die verbinding sal gevestig word met `http://backend:9999` sodat jy **enige ander pad binne daardie interne eindpunt kan kontak. Dit maak nie saak of 'n pad in die URL van proxy\_pass gespesifiseer is nie.** {% endhint %} ## Probeer dit self Detectify het 'n GitHub-repo geskep waar jy Docker kan gebruik om jou eie kwesbare Nginx-toetsbediener op te stel met 'n paar van die miskonfigurasies wat in hierdie artikel bespreek is en probeer om dit self te vind! [https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx) ## Statiese ontleder gereedskap ### [GIXY](https://github.com/yandex/gixy) Gixy is 'n hulpmiddel om Nginx-konfigurasie te analiseer. Die hoofdoel van Gixy is om sekuriteitsmisconfigurasie te voorkom en foutdetectie te outomatiseer. ### [Nginxpwner](https://github.com/stark0de/nginxpwner) Nginxpwner is 'n eenvoudige hulpmiddel om te soek na algemene Nginx-miskonfigurasies en kwesbaarhede. ## 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)
**Kry 'n hacker se perspektief op jou webtoepassings, netwerk, en wolk** **Vind en rapporteer kritieke, exploiteerbare kwesbaarhede met werklike besigheidsimpak.** Gebruik ons 20+ pasgemaakte gereedskap om die aanvaloppervlak te karteer, sekuriteitskwessies te vind wat jou toelaat om voorregte te verhoog, en gebruik outomatiese eksploit om noodsaaklike bewyse te versamel, wat jou harde werk in oortuigende verslae omskep. {% embed url="https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=spons" %} {% hint style="success" %} Leer & oefen AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Leer & oefen GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Ondersteun HackTricks * Kyk na die [**subskripsieplanne**](https://github.com/sponsors/carlospolop)! * **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐩 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}