Nginx

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Άμεσα διαθέσιμη ρύθμιση για αξιολόγηση ευπαθειών & διείσδυση. Εκτελέστε μια πλήρη pentest από οπουδήποτε με 20+ εργαλεία & δυνατότητες που κυμαίνονται από αναγνώριση έως αναφορά. Δεν αντικαθιστούμε τους pentesters - αναπτύσσουμε προσαρμοσμένα εργαλεία, μονάδες ανίχνευσης & εκμετάλλευσης για να τους δώσουμε πίσω λίγο χρόνο για να εμβαθύνουν, να ανοίξουν κέλυφος και να διασκεδάσουν.

Penetration testing toolkit, ready to usePentest-Tools.com

Missing root location

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

server {
root /etc/nginx;

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

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

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

Alias LFI Misconfiguration

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

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

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

Για να μετριαστεί αυτή η ευπάθεια, η διαμόρφωση θα πρέπει να προσαρμοστεί σε:

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

Unsafe path restriction

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

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Proxy / WAF Protections Bypass

Unsafe variable use / HTTP Request Splitting

Ευάλωτες μεταβλητές $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) σε έναν κακώς ρυθμισμένο διακομιστή έχει ως αποτέλεσμα τον διακομιστή να εκδίδει μια νέα κεφαλίδα με το όνομα Detectify. Αυτό συμβαίνει επειδή η μεταβλητή $uri αποκωδικοποιεί τους URL-encoded χαρακτήρες νέας γραμμής, οδηγώντας σε μια απροσδόκητη κεφαλίδα στην απόκριση:

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 δεν είναι έγκυρη μέθοδος. Έτσι, ο διακομιστής θα λάβει κάτι σαν: 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;
}

Any variable

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

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

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

Scans for this misconfiguration across systems revealed multiple instances where Nginx variables could be printed by a user. However, a decrease in the number of vulnerable instances suggests that efforts to patch this issue have been somewhat successful.

Raw backend response reading

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

Consider an example scenario involving a 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!"]

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

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

merge_slashes set to off

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

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

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

Maclicious Response Headers

Όπως φαίνεται σε αυτή την ανάλυση, υπάρχουν ορισμένα headers που αν είναι παρόντα στην απάντηση από τον διακομιστή ιστού θα αλλάξουν τη συμπεριφορά του Nginx proxy. Μπορείτε να τα ελέγξετε στα έγγραφα:

• X-Accel-Redirect: Υποδεικνύει στο Nginx να ανακατευθύνει εσωτερικά μια αίτηση σε μια καθορισμένη τοποθεσία.

• X-Accel-Buffering: Ελέγχει αν το Nginx θα πρέπει να αποθηκεύει την απάντηση ή όχι.

• X-Accel-Charset: Ορίζει το σύνολο χαρακτήρων για την απάντηση όταν χρησιμοποιείται το X-Accel-Redirect.

• X-Accel-Expires: Ορίζει τον χρόνο λήξης για την απάντηση όταν χρησιμοποιείται το X-Accel-Redirect.

• X-Accel-Limit-Rate: Περιορίζει το ρυθμό μεταφοράς για τις απαντήσεις όταν χρησιμοποιείται το X-Accel-Redirect.

Για παράδειγμα, το header X-Accel-Redirect θα προκαλέσει μια εσωτερική ανακατεύθυνση στο nginx. Έτσι, έχοντας μια ρύθμιση nginx με κάτι όπως root / και μια απάντηση από τον διακομιστή ιστού με 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, ένας κακόβουλος χρήστης μπορεί να παρακάμψει την ασφάλεια αποκτώντας πρόσβαση σε μια μη καθορισμένη URI εντός του /map-poc. Το εγχειρίδιο του Nginx προτείνει την ρύθμιση μιας προκαθορισμένης τιμής για να αποφευχθούν τέτοια ζητήματα.

Ευπάθεια DNS Spoofing

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

resolver 8.8.8.8;

proxy_pass και internal Δηλώσεις

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

proxy_set_header Upgrade & Connection

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

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

Παράδειγμα ευάλωτης διαμόρφωσης για την κλοπή του /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;
}

Σημειώστε ότι ακόμη και αν το proxy_pass δείχνει σε μια συγκεκριμένη διαδρομή όπως http://backend:9999/socket.io, η σύνδεση θα γίνει με το http://backend:9999, οπότε μπορείτε να επικοινωνήσετε με οποιαδήποτε άλλη διαδρομή μέσα σε αυτό το εσωτερικό σημείο. Έτσι, δεν έχει σημασία αν μια διαδρομή καθορίζεται στη διεύθυνση URL του proxy_pass.

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

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

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

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

GIXY

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

Nginxpwner

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

Αναφορές

• https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/

• http://blog.zorinaq.com/nginx-resolver-vulns/

• https://github.com/yandex/gixy/issues/115

Άμεση διαθέσιμη ρύθμιση για αξιολόγηση ευπαθειών & pentesting. Εκτελέστε μια πλήρη δοκιμή από οπουδήποτε με 20+ εργαλεία & δυνατότητες που κυμαίνονται από αναγνώριση έως αναφορά. Δεν αντικαθιστούμε τους pentesters - αναπτύσσουμε προσαρμοσμένα εργαλεία, μονάδες ανίχνευσης & εκμετάλλευσης για να τους δώσουμε πίσω λίγο χρόνο για να εμβαθύνουν, να ανοίξουν κέλυφος και να διασκεδάσουν.

Penetration testing toolkit, ready to usePentest-Tools.com

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

Υποστήριξη HackTricks

• Ελέγξτε τα σχέδια συνδρομής!

• Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα telegram ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.

• Μοιραστείτε κόλπα hacking υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.