Greek - Ht
HackTricks Training Twitter Linkedin Sponsor

Nginx

Μάθετε το χάκινγκ στο AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι υποστήριξης του HackTricks:

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

Λείπει η ρίζα τοποθεσίας

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

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

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

Αυτή η διαμόρφωση είναι ευάλωτη σε επιθέσεις LFI λόγω του διακομιστή που ερμηνεύει αιτήσεις όπως /imgs../flag.txt ως προσπάθεια πρόσβασης σε αρχεία έξω από τον προορισμένο κατάλογο, αναπτύσσοντας αποτελεσματικά σε /path/images/../flag.txt. Αυτή η αδυναμία επιτρέπει σε επιτιθέμενους να ανακτήσουν αρχεία από το σύστημα αρχείων του διακομιστή που δεν πρέπει να είναι προσβάσιμα μέσω του 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;
}

Χρήση μη ασφαλών μεταβλητών / Διαχωρισμός Αιτήσεων HTTP

Οι ευάλωτες μεταβλητές $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 (Επιστροφή Καρέτου) και \n (Αλλαγή Γραμμής) σημαίνουν νέους χαρακτήρες σε αιτήσεις HTTP, και οι κωδικοποιημένες μορφές τους στο URL αναπαρίστανται ως %0d%0a. Η συμπερίληψη αυτών των χαρακτήρων σε μια αίτηση (π.χ., http://localhost/%0d%0aDetectify:%20clrf) προς έναν λανθασμένα ρυθμισμένο διακομιστή οδηγεί στον διακομιστή να εκδίδει ένα νέο κεφαλίδα με το όνομα Detectify. Αυτό συμβαίνει επειδή η μεταβλητή $uri αποκωδικοποιεί τους κωδικοποιημένους με νέα γραμμή χαρακτήρες URL, οδηγώντας σε ένα απροσδόκητο κεφαλίδα στην απάντηση:

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 και της διαίρεσης απόκρισης στο https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

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

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

  • https://example.com/%20H - 400 Κακό Αίτημα

Αν είναι ευάλωτο, το πρώτο θα επιστραφεί ως "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 Κακό Αίτημα

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

  • Σημειώστε πώς $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 header) για να δοκιμάσετε την εκτύπωση μεταβλητών:

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

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

Διάβασμα απάντησης backend χωρίς μετατροπή

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

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

Η ρύθμιση merge_slashes σε off

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

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

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

Κακόβουλες Κεφαλίδες Απάντησης

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

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

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

  • 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 / και μια απάντηση από τον διακομιστή ιστού με X-Accel-Redirect: .env θα κάνει το nginx να στείλει το περιεχόμενο του /.env (Διέλευση Διαδρομής).

Προεπιλεγμένη Τιμή στην Οδηγία Map

Στη διαμόρφωση του 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

Η παραπλάνηση DNS εναντίον του Nginx είναι εφικτή υπό συγκεκριμένες συνθήκες. Αν ένας επιτιθέμενος γνωρίζει τον DNS server που χρησιμοποιείται από το Nginx και μπορεί να παρεμβάλει τις DNS ερωτήσεις του, μπορεί να παραπλανήσει τις εγγραφές DNS. Αυτή η μέθοδος, ωστόσο, δεν είναι αποτελεσματική εάν το 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 έχει ρυθμιστεί να περνά τα headers 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.

Αναφορές

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

Μάθετε το χάκινγκ στο AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι υποστήριξης του HackTricks:

PreviousMoodleNextPHP Tricks

Last updated