diff --git a/src/images/nginx_try_files.png b/src/images/nginx_try_files.png new file mode 100644 index 000000000..0c14e95c9 Binary files /dev/null and b/src/images/nginx_try_files.png differ diff --git a/src/network-services-pentesting/pentesting-web/nginx.md b/src/network-services-pentesting/pentesting-web/nginx.md index 81e49f3d3..8213d18e7 100644 --- a/src/network-services-pentesting/pentesting-web/nginx.md +++ b/src/network-services-pentesting/pentesting-web/nginx.md @@ -5,7 +5,7 @@ ## Missing root location -Όταν ρυθμίζετε τον διακομιστή Nginx, η **κατεύθυνση root** παίζει κρίσιμο ρόλο καθορίζοντας τον βασικό κατάλογο από τον οποίο εξυπηρετούνται τα αρχεία. Σκεφτείτε το παρακάτω παράδειγμα: +Όταν ρυθμίζετε τον διακομιστή Nginx, η **εντολή root** παίζει κρίσιμο ρόλο καθορίζοντας τον βασικό κατάλογο από τον οποίο εξυπηρετούνται τα αρχεία. Σκεφτείτε το παρακάτω παράδειγμα: ```bash server { root /etc/nginx; @@ -16,7 +16,7 @@ proxy_pass http://127.0.0.1:8080/; } } ``` -Σε αυτή τη διαμόρφωση, το `/etc/nginx` έχει οριστεί ως ο ριζικός κατάλογος. Αυτή η ρύθμιση επιτρέπει την πρόσβαση σε αρχεία εντός του καθορισμένου ριζικού καταλόγου, όπως το `/hello.txt`. Ωστόσο, είναι κρίσιμο να σημειωθεί ότι έχει οριστεί μόνο μια συγκεκριμένη τοποθεσία (`/hello.txt`). Δεν υπάρχει διαμόρφωση για την ριζική τοποθεσία (`location / {...}`). Αυτή η παράλειψη σημαίνει ότι η ριζική οδηγία ισχύει παγκοσμίως, επιτρέποντας τα αιτήματα για τη ριζική διαδρομή `/` να έχουν πρόσβαση σε αρχεία κάτω από το `/etc/nginx`. +Σε αυτή τη διαμόρφωση, το `/etc/nginx` έχει οριστεί ως ο ριζικός κατάλογος. Αυτή η ρύθμιση επιτρέπει την πρόσβαση σε αρχεία εντός του καθορισμένου ριζικού καταλόγου, όπως το `/hello.txt`. Ωστόσο, είναι κρίσιμο να σημειωθεί ότι έχει οριστεί μόνο μια συγκεκριμένη τοποθεσία (`/hello.txt`). Δεν υπάρχει διαμόρφωση για τη ριζική τοποθεσία (`location / {...}`). Αυτή η παράλειψη σημαίνει ότι η οδηγία ρίζας ισχύει παγκοσμίως, επιτρέποντας τα αιτήματα για τη ριζική διαδρομή `/` να έχουν πρόσβαση σε αρχεία κάτω από το `/etc/nginx`. Μια κρίσιμη ανησυχία ασφαλείας προκύπτει από αυτή τη διαμόρφωση. Ένα απλό αίτημα `GET`, όπως το `GET /nginx.conf`, θα μπορούσε να εκθέσει ευαίσθητες πληροφορίες εξυπηρετώντας το αρχείο διαμόρφωσης Nginx που βρίσκεται στο `/etc/nginx/nginx.conf`. Η ρύθμιση της ρίζας σε έναν λιγότερο ευαίσθητο κατάλογο, όπως το `/etc`, θα μπορούσε να μετριάσει αυτόν τον κίνδυνο, ωστόσο μπορεί να επιτρέπει ακόμα μη προγραμματισμένη πρόσβαση σε άλλα κρίσιμα αρχεία, συμπεριλαμβανομένων άλλων αρχείων διαμόρφωσης, αρχείων καταγραφής πρόσβασης και ακόμη και κωδικών πρόσβασης που χρησιμοποιούνται για την HTTP βασική αυθεντικοποίηση. @@ -28,7 +28,7 @@ location /imgs { alias /path/images/; } ``` -Αυτή η ρύθμιση είναι επιρρεπής σε επιθέσεις LFI λόγω της ερμηνείας των αιτημάτων από τον διακομιστή όπως το `/imgs../flag.txt` ως μια προσπάθεια πρόσβασης σε αρχεία εκτός του προοριζόμενου καταλόγου, επιλύοντας αποτελεσματικά σε `/path/images/../flag.txt`. Αυτή η αδυναμία επιτρέπει στους επιτιθέμενους να ανακτούν αρχεία από το σύστημα αρχείων του διακομιστή που δεν θα έπρεπε να είναι προσβάσιμα μέσω του διαδικτύου. +Αυτή η ρύθμιση είναι επιρρεπής σε επιθέσεις LFI λόγω του ότι ο διακομιστής ερμηνεύει αιτήματα όπως το `/imgs../flag.txt` ως μια προσπάθεια πρόσβασης σε αρχεία εκτός του προοριζόμενου καταλόγου, επιλύοντας αποτελεσματικά σε `/path/images/../flag.txt`. Αυτή η αδυναμία επιτρέπει στους επιτιθέμενους να ανακτούν αρχεία από το σύστημα αρχείων του διακομιστή που δεν θα έπρεπε να είναι προσβάσιμα μέσω του διαδικτύου. Για να μετριαστεί αυτή η ευπάθεια, η ρύθμιση θα πρέπει να προσαρμοστεί σε: ``` @@ -62,7 +62,7 @@ deny all; ../../pentesting-web/proxy-waf-protections-bypass.md {{#endref}} -## Unsafe variable use / HTTP Request Splitting +## Χρήση μη ασφαλών μεταβλητών / Διαχωρισμός HTTP Request > [!CAUTION] > Ευάλωτες μεταβλητές `$uri` και `$document_uri` και αυτό μπορεί να διορθωθεί αντικαθιστώντας τις με `$request_uri`. @@ -98,7 +98,7 @@ Detectify: clrf - `https://example.com/%20X` - Οποιοσδήποτε κωδικός HTTP - `https://example.com/%20H` - 400 Bad Request -Αν είναι ευάλωτο, το πρώτο θα επιστρέψει καθώς το "X" είναι οποιαδήποτε μέθοδος HTTP και το δεύτερο θα επιστρέψει ένα σφάλμα καθώς το H δεν είναι έγκυρη μέθοδος. Έτσι, ο διακομιστής θα λάβει κάτι σαν: `GET / H HTTP/1.1` και αυτό θα προκαλέσει το σφάλμα. +Εάν είναι ευάλωτο, το πρώτο θα επιστρέψει καθώς το "X" είναι οποιαδήποτε μέθοδος HTTP και το δεύτερο θα επιστρέψει ένα σφάλμα καθώς το H δεν είναι έγκυρη μέθοδος. Έτσι, ο διακομιστής θα λάβει κάτι σαν: `GET / H HTTP/1.1` και αυτό θα προκαλέσει το σφάλμα. Άλλα παραδείγματα ανίχνευσης θα ήταν: @@ -107,7 +107,7 @@ Detectify: clrf Ορισμένες ευάλωτες ρυθμίσεις που βρέθηκαν σε αυτή την ομιλία ήταν: -- Σημειώστε πώς **`$uri`** έχει οριστεί όπως είναι στην τελική διεύθυνση URL. +- Σημειώστε πώς **`$uri`** είναι ρυθμισμένο όπως είναι στην τελική διεύθυνση URL. ``` location ^~ /lite/api/ { proxy_pass http://lite-backend$uri$is_args$args; @@ -125,19 +125,69 @@ location /s3/ { proxy_pass https://company-bucket.s3.amazonaws.com$uri; } ``` -### Οποιαδήποτε μεταβλητή +### Any variable -Ανακαλύφθηκε ότι τα **δεδομένα που παρέχονται από τον χρήστη** μπορεί να αντιμετωπίζονται ως **μεταβλητή Nginx** υπό ορισμένες συνθήκες. Η αιτία αυτής της συμπεριφοράς παραμένει κάπως ασαφής, ωστόσο δεν είναι σπάνια ούτε απλή η επαλήθευσή της. Αυτή η ανωμαλία επισημάνθηκε σε μια αναφορά ασφαλείας στο HackerOne, η οποία μπορεί να προβληθεί [εδώ](https://hackerone.com/reports/370094). Περαιτέρω έρευνα στο μήνυμα σφάλματος οδήγησε στην αναγνώριση της εμφάνισής του μέσα στον [μηχανισμό φίλτρου SSI του κώδικα Nginx](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), προσδιορίζοντας τις Server Side Includes (SSI) ως την κύρια αιτία. +Ανακαλύφθηκε ότι τα **δεδομένα που παρέχονται από τον χρήστη** μπορεί να αντιμετωπίζονται ως **μεταβλητή Nginx** υπό ορισμένες συνθήκες. Η αιτία αυτής της συμπεριφοράς παραμένει κάπως ασαφής, ωστόσο δεν είναι σπάνια ούτε απλή η επαλήθευσή της. Αυτή η ανωμαλία επισημάνθηκε σε μια αναφορά ασφαλείας στο HackerOne, η οποία μπορεί να προβληθεί [εδώ](https://hackerone.com/reports/370094). Περεταίρω έρευνα στο μήνυμα σφάλματος οδήγησε στην ταυτοποίηση της εμφάνισής του μέσα στον [SSI filter module του κώδικα Nginx](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), προσδιορίζοντας τις Server Side Includes (SSI) ως την κύρια αιτία. -Για να **ανιχνευθεί αυτή η κακή διαμόρφωση**, μπορεί να εκτελεστεί η ακόλουθη εντολή, η οποία περιλαμβάνει την ρύθμιση ενός referer header για τη δοκιμή εκτύπωσης μεταβλητών: +Για να **ανιχνευθεί αυτή η κακή ρύθμιση**, μπορεί να εκτελεστεί η ακόλουθη εντολή, η οποία περιλαμβάνει την ρύθμιση ενός referer header για να δοκιμαστεί η εκτύπωση μεταβλητών: ```bash $ 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 θα ελέγξει την ύπαρξη κάθε αρχείου με τη συγκεκριμένη σειρά. Αν ένα αρχείο υπάρχει, θα σερβιριστεί αμέσως. Αν κανένα από τα καθορισμένα αρχεία δεν υπάρχει, το αίτημα θα περάσει στην εναλλακτική επιλογή, η οποία μπορεί να είναι μια άλλη URI ή μια συγκεκριμένη σελίδα σφάλματος. + +Ωστόσο, όταν χρησιμοποιούνται οι μεταβλητές `$uri$args` σε αυτή τη δήλωση, το Nginx θα προσπαθήσει να βρει ένα αρχείο που να ταιριάζει με την URI του αιτήματος σε συνδυασμό με οποιαδήποτε επιχειρήματα συμβολοσειράς ερωτήματος. Επομένως, μπορούμε να εκμεταλλευτούμε αυτή τη ρύθμιση: +``` +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`. Στα αρχεία καταγραφής αποσφαλμάτωσης μπορούμε να παρατηρήσουμε πώς ο 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](../../images/nginx_try_files.png) + ## Ανάγνωση ωμής απάντησης backend -Το Nginx προσφέρει μια δυνατότητα μέσω του `proxy_pass` που επιτρέπει την παρεμβολή σφαλμάτων και HTTP headers που παράγονται από το backend, με στόχο την απόκρυψη εσωτερικών μηνυμάτων σφάλματος και headers. Αυτό επιτυγχάνεται με το να σερβίρει το Nginx προσαρμοσμένες σελίδες σφάλματος ως απάντηση σε σφάλματα του backend. Ωστόσο, προκύπτουν προκλήσεις όταν το Nginx συναντά μια μη έγκυρη HTTP αίτηση. Μια τέτοια αίτηση προωθείται στο backend όπως έχει ληφθεί, και η ωμή απάντηση του backend αποστέλλεται απευθείας στον πελάτη χωρίς την παρέμβαση του Nginx. +Ο Nginx προσφέρει μια δυνατότητα μέσω του `proxy_pass` που επιτρέπει την παρεμβολή σφαλμάτων και HTTP headers που παράγονται από το backend, με στόχο την απόκρυψη εσωτερικών μηνυμάτων σφάλματος και headers. Αυτό επιτυγχάνεται με τον Nginx να σερβίρει προσαρμοσμένες σελίδες σφαλμάτων ως απάντηση σε σφάλματα του backend. Ωστόσο, προκύπτουν προκλήσεις όταν ο Nginx συναντά μια μη έγκυρη HTTP αίτηση. Μια τέτοια αίτηση προωθείται στο backend όπως έχει ληφθεί, και η ωμή απάντηση του backend αποστέλλεται απευθείας στον πελάτη χωρίς την παρέμβαση του Nginx. Σκεφτείτε ένα παράδειγμα σεναρίου που περιλαμβάνει μια εφαρμογή uWSGI: ```python @@ -160,7 +210,7 @@ proxy_hide_header Secret-Header; ## merge_slashes set to off -Από προεπιλογή, η **`merge_slashes` οδηγία** του Nginx είναι ρυθμισμένη σε **`on`**, η οποία συμπιέζει πολλαπλούς προοδευτικούς χαρακτήρες σε μια URL σε έναν μόνο χαρακτήρα. Αυτή η δυνατότητα, ενώ απλοποιεί την επεξεργασία URL, μπορεί ακούσια να αποκρύψει ευπάθειες σε εφαρμογές πίσω από το Nginx, ιδιαίτερα αυτές που είναι επιρρεπείς σε επιθέσεις τοπικής συμπερίληψης αρχείων (LFI). Οι ειδικοί ασφαλείας **Danny Robinson και Rotem Bar** έχουν επισημάνει τους πιθανούς κινδύνους που σχετίζονται με αυτή τη συμπεριφορά προεπιλογής, ειδικά όταν το Nginx λειτουργεί ως αντίστροφος διακομιστής. +Από προεπιλογή, η **`merge_slashes` οδηγία** του Nginx είναι ρυθμισμένη σε **`on`**, η οποία συμπιέζει πολλαπλούς προοδευτικούς χαρακτήρες (slashes) σε μια URL σε έναν μόνο χαρακτήρα. Αυτή η δυνατότητα, ενώ απλοποιεί την επεξεργασία URL, μπορεί ακούσια να αποκρύψει ευπάθειες σε εφαρμογές πίσω από το Nginx, ιδιαίτερα αυτές που είναι επιρρεπείς σε επιθέσεις τοπικής συμπερίληψης αρχείων (LFI). Οι ειδικοί ασφαλείας **Danny Robinson και Rotem Bar** έχουν επισημάνει τους πιθανούς κινδύνους που σχετίζονται με αυτή τη συμπεριφορά προεπιλογής, ειδικά όταν το Nginx λειτουργεί ως αντίστροφος διακομιστής (reverse-proxy). Για να μετριαστούν αυτοί οι κίνδυνοι, συνιστάται να **απενεργοποιήσετε την οδηγία `merge_slashes`** για εφαρμογές που είναι ευάλωτες σε αυτές τις ευπάθειες. Αυτό διασφαλίζει ότι το Nginx προωθεί τις αιτήσεις στην εφαρμογή χωρίς να αλλάζει τη δομή της URL, αποφεύγοντας έτσι την απόκρυψη οποιωνδήποτε υποκείμενων ζητημάτων ασφαλείας. @@ -239,7 +289,7 @@ deny all; } ``` > [!WARNING] -> Σημειώστε ότι ακόμη και αν το `proxy_pass` δείχνει σε μια συγκεκριμένη **διαδρομή** όπως `http://backend:9999/socket.io`, η σύνδεση θα γίνει με το `http://backend:9999`, οπότε μπορείτε να **επικοινωνήσετε με οποιαδήποτε άλλη διαδρομή μέσα σε αυτό το εσωτερικό σημείο. Έτσι, δεν έχει σημασία αν μια διαδρομή έχει καθοριστεί στη διεύθυνση URL του proxy_pass.** +> Σημειώστε ότι ακόμη και αν το `proxy_pass` δείχνει σε μια συγκεκριμένη **διαδρομή** όπως `http://backend:9999/socket.io`, η σύνδεση θα γίνει με `http://backend:9999`, οπότε μπορείτε να **επικοινωνήσετε με οποιαδήποτε άλλη διαδρομή μέσα σε αυτό το εσωτερικό σημείο. Έτσι, δεν έχει σημασία αν μια διαδρομή έχει καθοριστεί στη διεύθυνση URL του proxy_pass.** ## Δοκιμάστε το μόνοι σας