Nginx
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Άμεσα διαθέσιμη ρύθμιση για αξιολόγηση ευπαθειών & διείσδυση. Εκτελέστε μια πλήρη pentest από οπουδήποτε με 20+ εργαλεία & δυνατότητες που κυμαίνονται από αναγνώριση έως αναφορά. Δεν αντικαθιστούμε τους pentesters - αναπτύσσουμε προσαρμοσμένα εργαλεία, μονάδες ανίχνευσης & εκμετάλλευσης για να τους δώσουμε πίσω λίγο χρόνο για να εμβαθύνουν, να ανοίξουν κέλυφος και να διασκεδάσουν.
Όταν ρυθμίζετε τον διακομιστή Nginx, η κατεύθυνση root παίζει κρίσιμο ρόλο καθορίζοντας τον βασικό κατάλογο από τον οποίο εξυπηρετούνται τα αρχεία. Σκεφτείτε το παρακάτω παράδειγμα:
Σε αυτή τη διαμόρφωση, το /etc/nginx έχει οριστεί ως ο ριζικός κατάλογος. Αυτή η ρύθμιση επιτρέπει την πρόσβαση σε αρχεία εντός του καθορισμένου ριζικού καταλόγου, όπως το /hello.txt. Ωστόσο, είναι κρίσιμο να σημειωθεί ότι μόνο μια συγκεκριμένη τοποθεσία (/hello.txt) έχει οριστεί. Δεν υπάρχει διαμόρφωση για τη ριζική τοποθεσία (location / {...}). Αυτή η παράλειψη σημαίνει ότι η οδηγία ριζικού ισχύει παγκοσμίως, επιτρέποντας τα αιτήματα για τη ριζική διαδρομή / να έχουν πρόσβαση σε αρχεία κάτω από το /etc/nginx.
Μια κρίσιμη σκέψη ασφαλείας προκύπτει από αυτή τη διαμόρφωση. Ένα απλό αίτημα GET, όπως το GET /nginx.conf, θα μπορούσε να εκθέσει ευαίσθητες πληροφορίες παρέχοντας το αρχείο διαμόρφωσης Nginx που βρίσκεται στο /etc/nginx/nginx.conf. Η ρύθμιση της ρίζας σε έναν λιγότερο ευαίσθητο κατάλογο, όπως το /etc, θα μπορούσε να μετριάσει αυτόν τον κίνδυνο, ωστόσο μπορεί να επιτρέπει ακόμα μη προγραμματισμένη πρόσβαση σε άλλα κρίσιμα αρχεία, συμπεριλαμβανομένων άλλων αρχείων διαμόρφωσης, αρχείων καταγραφής πρόσβασης και ακόμη και κωδικών πρόσβασης που χρησιμοποιούνται για την HTTP basic authentication.
Στα αρχεία διαμόρφωσης του Nginx, απαιτείται προσεκτική επιθεώρηση για τις οδηγίες "location". Μια ευπάθεια γνωστή ως Local File Inclusion (LFI) μπορεί να εισαχθεί ακούσια μέσω μιας διαμόρφωσης που μοιάζει με την εξής:
Αυτή η διαμόρφωση είναι επιρρεπής σε επιθέσεις LFI λόγω της ερμηνείας των αιτημάτων από τον διακομιστή όπως το /imgs../flag.txt ως μια προσπάθεια πρόσβασης σε αρχεία εκτός του προοριζόμενου καταλόγου, επιλύοντας αποτελεσματικά σε /path/images/../flag.txt. Αυτή η αδυναμία επιτρέπει στους επιτιθέμενους να ανακτούν αρχεία από το σύστημα αρχείων του διακομιστή που δεν θα έπρεπε να είναι προσβάσιμα μέσω του ιστού.
Για να μετριαστεί αυτή η ευπάθεια, η διαμόρφωση θα πρέπει να προσαρμοστεί σε:
Περισσότερες πληροφορίες: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/
Δοκιμές Accunetix:
Ελέγξτε την παρακάτω σελίδα για να μάθετε πώς να παρακάμψετε οδηγίες όπως:
Ευάλωτες μεταβλητές $uri και $document_uri και αυτό μπορεί να διορθωθεί αντικαθιστώντας τις με $request_uri.
Μια regex μπορεί επίσης να είναι ευάλωτη όπως:
location ~ /docs/([^/])? { … $1 … } - Ευάλωτη
location ~ /docs/([^/\s])? { … $1 … } - Όχι ευάλωτη (έλεγχος κενών)
location ~ /docs/(.*)? { … $1 … } - Όχι ευάλωτη
Μια ευπάθεια στη διαμόρφωση του Nginx αποδεικνύεται από το παρακάτω παράδειγμα:
Οι χαρακτήρες \r (Carriage Return) και \n (Line Feed) σηματοδοτούν χαρακτήρες νέας γραμμής σε αιτήματα HTTP, και οι URL-encoded μορφές τους αναπαρίστανται ως %0d%0a. Η συμπερίληψη αυτών των χαρακτήρων σε ένα αίτημα (π.χ., http://localhost/%0d%0aDetectify:%20clrf) σε έναν κακώς ρυθμισμένο διακομιστή έχει ως αποτέλεσμα τον διακομιστή να εκδίδει μια νέα κεφαλίδα με το όνομα Detectify. Αυτό συμβαίνει επειδή η μεταβλητή $uri αποκωδικοποιεί τους URL-encoded χαρακτήρες νέας γραμμής, οδηγώντας σε μια απροσδόκητη κεφαλίδα στην απόκριση:
Μάθετε περισσότερα για τους κινδύνους της 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
Σημειώστε πώς ξανά $uri είναι στο URL (αυτή τη φορά μέσα σε μια παράμετρο)
Τώρα στο AWS S3
Ανακαλύφθηκε ότι τα δεδομένα που παρέχονται από τον χρήστη μπορεί να αντιμετωπίζονται ως μεταβλητή Nginx υπό ορισμένες συνθήκες. Η αιτία αυτής της συμπεριφοράς παραμένει κάπως ασαφής, ωστόσο δεν είναι σπάνια ούτε απλή η επαλήθευσή της. Αυτή η ανωμαλία επισημάνθηκε σε μια αναφορά ασφαλείας στο HackerOne, η οποία μπορεί να προβληθεί εδώ. Περεταίρω έρευνα στο μήνυμα σφάλματος οδήγησε στην αναγνώριση της εμφάνισής του εντός του SSI filter module του κώδικα Nginx, προσδιορίζοντας τις Server Side Includes (SSI) ως την κύρια αιτία.
Για να ανιχνευθεί αυτή η κακή ρύθμιση, μπορεί να εκτελεστεί η παρακάτω εντολή, η οποία περιλαμβάνει την ρύθμιση ενός referer header για τη δοκιμή εκτύπωσης μεταβλητών:
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.
Nginx προσφέρει μια δυνατότητα μέσω του proxy_pass που επιτρέπει την παρεμβολή σφαλμάτων και HTTP headers που παράγονται από το backend, με στόχο να κρύψει τα εσωτερικά μηνύματα σφάλματος και headers. Αυτό επιτυγχάνεται με το να σερβίρει η Nginx προσαρμοσμένες σελίδες σφάλματος σε απάντηση σε σφάλματα του backend. Ωστόσο, προκύπτουν προκλήσεις όταν η Nginx συναντά μια μη έγκυρη HTTP αίτηση. Μια τέτοια αίτηση προωθείται στο backend όπως έχει ληφθεί, και η ακατέργαστη απάντηση του backend αποστέλλεται απευθείας στον πελάτη χωρίς την παρέμβαση της Nginx.
Consider an example scenario involving a uWSGI application:
Για να διαχειριστείτε αυτό, χρησιμοποιούνται συγκεκριμένες οδηγίες στη διαμόρφωση του Nginx:
proxy_intercept_errors: Αυτή η οδηγία επιτρέπει στο Nginx να εξυπηρετεί μια προσαρμοσμένη απάντηση για τις απαντήσεις του backend με κωδικό κατάστασης μεγαλύτερο από 300. Διασφαλίζει ότι, για την εφαρμογή uWSGI που χρησιμοποιούμε ως παράδειγμα, μια απάντηση 500 Error παγιδεύεται και διαχειρίζεται από το Nginx.
proxy_hide_header: Όπως υποδηλώνει το όνομα, αυτή η οδηγία κρύβει καθορισμένα HTTP headers από τον πελάτη, ενισχύοντας την ιδιωτικότητα και την ασφάλεια.
Όταν γίνεται μια έγκυρη αίτηση GET, το Nginx την επεξεργάζεται κανονικά, επιστρέφοντας μια τυπική απάντηση σφάλματος χωρίς να αποκαλύπτει κανένα μυστικό header. Ωστόσο, μια μη έγκυρη HTTP αίτηση παρακάμπτει αυτόν τον μηχανισμό, με αποτέλεσμα την έκθεση των ακατέργαστων απαντήσεων του backend, συμπεριλαμβανομένων των μυστικών headers και των μηνυμάτων σφάλματος.
Από προεπιλογή, η merge_slashes οδηγία του Nginx είναι ρυθμισμένη σε on, η οποία συμπιέζει πολλαπλούς προοδευτικούς χαρακτήρες σε μια μόνο κάθετο. Αυτή η δυνατότητα, ενώ απλοποιεί την επεξεργασία URL, μπορεί ακούσια να αποκρύψει ευπάθειες σε εφαρμογές πίσω από το Nginx, ιδιαίτερα αυτές που είναι επιρρεπείς σε επιθέσεις τοπικής συμπερίληψης αρχείων (LFI). Οι ειδικοί ασφαλείας Danny Robinson και Rotem Bar έχουν επισημάνει τους πιθανούς κινδύνους που σχετίζονται με αυτή τη συμπεριφορά προεπιλογής, ειδικά όταν το Nginx λειτουργεί ως αντίστροφος διακομιστής.
Για να μετριαστούν αυτοί οι κίνδυνοι, συνιστάται να απενεργοποιήσετε την οδηγία merge_slashes για εφαρμογές που είναι ευάλωτες σε αυτές τις ευπάθειες. Αυτό διασφαλίζει ότι το Nginx προωθεί τις αιτήσεις στην εφαρμογή χωρίς να αλλάζει τη δομή του URL, αποφεύγοντας έτσι την απόκρυψη οποιωνδήποτε υποκείμενων ζητημάτων ασφαλείας.
Για περισσότερες πληροφορίες, ελέγξτε Danny Robinson και Rotem Bar.
Όπως φαίνεται σε αυτή την ανάλυση, υπάρχουν ορισμένα 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).
Στη ρύθμιση Nginx, η οδηγία map συχνά παίζει ρόλο στον έλεγχο εξουσιοδότησης. Ένα κοινό λάθος είναι να μην καθορίζεται μια προεπιλεγμένη τιμή, κάτι που θα μπορούσε να οδηγήσει σε μη εξουσιοδοτημένη πρόσβαση. Για παράδειγμα:
Χωρίς ένα default, ένας κακόβουλος χρήστης μπορεί να παρακάμψει την ασφάλεια αποκτώντας πρόσβαση σε μια μη καθορισμένη URI εντός του /map-poc. Το εγχειρίδιο του Nginx προτείνει την ρύθμιση μιας προκαθορισμένης τιμής για να αποφευχθούν τέτοια ζητήματα.
Η DNS spoofing κατά του Nginx είναι εφικτή υπό ορισμένες συνθήκες. Εάν ένας επιτιθέμενος γνωρίζει τον DNS server που χρησιμοποιεί ο Nginx και μπορεί να παρεμποδίσει τα DNS queries του, μπορεί να παραποιήσει τα DNS records. Αυτή η μέθοδος, ωστόσο, είναι αναποτελεσματική εάν ο Nginx είναι ρυθμισμένος να χρησιμοποιεί localhost (127.0.0.1) για την επίλυση DNS. Ο Nginx επιτρέπει την καθορισμένη ρύθμιση ενός DNS server ως εξής:
proxy_pass και internal ΔηλώσειςΗ proxy_pass δήλωση χρησιμοποιείται για την ανακατεύθυνση αιτημάτων σε άλλους διακομιστές, είτε εσωτερικά είτε εξωτερικά. Η internal δήλωση διασφαλίζει ότι ορισμένες τοποθεσίες είναι προσβάσιμες μόνο εντός του Nginx. Ενώ αυτές οι δηλώσεις δεν είναι ευπάθειες από μόνες τους, η διαμόρφωσή τους απαιτεί προσεκτική εξέταση για την αποφυγή κενών ασφαλείας.
Εάν ο διακομιστής nginx είναι διαμορφωμένος να περνά τις κεφαλίδες Upgrade και Connection, μπορεί να εκτελεστεί μια επίθεση h2c Smuggling για την πρόσβαση σε προστατευμένα/εσωτερικά σημεία.
Αυτή η ευπάθεια θα επέτρεπε σε έναν επιτιθέμενο να δημιουργήσει άμεση σύνδεση με το proxy_pass σημείο (http://backend:9999 σε αυτή την περίπτωση) του οποίου το περιεχόμενο δεν θα ελεγχθεί από το nginx.
Παράδειγμα ευάλωτης διαμόρφωσης για την κλοπή του /flag από εδώ:
Σημειώστε ότι ακόμη και αν το proxy_pass δείχνει σε μια συγκεκριμένη διαδρομή όπως http://backend:9999/socket.io, η σύνδεση θα γίνει με το http://backend:9999, οπότε μπορείτε να επικοινωνήσετε με οποιαδήποτε άλλη διαδρομή μέσα σε αυτό το εσωτερικό σημείο. Έτσι, δεν έχει σημασία αν μια διαδρομή καθορίζεται στη διεύθυνση URL του proxy_pass.
Η Detectify έχει δημιουργήσει ένα αποθετήριο GitHub όπου μπορείτε να χρησιμοποιήσετε το Docker για να ρυθμίσετε τον δικό σας ευάλωτο διακομιστή δοκιμών Nginx με μερικές από τις κακές ρυθμίσεις που συζητούνται σε αυτό το άρθρο και να προσπαθήσετε να τις βρείτε μόνοι σας!
https://github.com/detectify/vulnerable-nginx
Το Gixy είναι ένα εργαλείο για την ανάλυση της ρύθμισης Nginx. Ο κύριος στόχος του Gixy είναι να αποτρέψει τις κακές ρυθμίσεις ασφαλείας και να αυτοματοποιήσει την ανίχνευση σφαλμάτων.
Το Nginxpwner είναι ένα απλό εργαλείο για την αναζήτηση κοινών κακών ρυθμίσεων και ευπαθειών του Nginx.
Άμεση διαθέσιμη ρύθμιση για αξιολόγηση ευπαθειών & pentesting. Εκτελέστε μια πλήρη δοκιμή από οπουδήποτε με 20+ εργαλεία & δυνατότητες που κυμαίνονται από αναγνώριση έως αναφορά. Δεν αντικαθιστούμε τους pentesters - αναπτύσσουμε προσαρμοσμένα εργαλεία, μονάδες ανίχνευσης & εκμετάλλευσης για να τους δώσουμε πίσω λίγο χρόνο για να εμβαθύνουν, να ανοίξουν κέλυφος και να διασκεδάσουν.
Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
