Upgrade Header Smuggling
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)
H2C, ή http2 over cleartext, αποκλίνει από τον κανόνα των προσωρινών HTTP συνδέσεων αναβαθμίζοντας μια τυπική HTTP σύνδεση σε μόνιμη. Αυτή η αναβαθμισμένη σύνδεση χρησιμοποιεί το πρωτόκολλο http2 για συνεχιζόμενη επικοινωνία, σε αντίθεση με τη φύση της ενιαίας αίτησης του απλού κειμένου HTTP.
Η ουσία του προβλήματος smuggling προκύπτει με τη χρήση ενός αντίστροφου διακομιστή μεσολάβησης. Κανονικά, ο αντίστροφος διακομιστής μεσολάβησης επεξεργάζεται και προωθεί τα HTTP αιτήματα προς το backend, επιστρέφοντας την απάντηση του backend μετά από αυτό. Ωστόσο, όταν η κεφαλίδα Connection: Upgrade είναι παρούσα σε ένα HTTP αίτημα (συνήθως εμφανίζεται με συνδέσεις websocket), ο αντίστροφος διακομιστής μεσολάβησης διατηρεί μια μόνιμη σύνδεση μεταξύ πελάτη και διακομιστή, διευκολύνοντας την συνεχόμενη ανταλλαγή που απαιτείται από ορισμένα πρωτόκολλα. Για τις συνδέσεις H2C, η τήρηση του RFC απαιτεί την παρουσία τριών συγκεκριμένων κεφαλίδων:
Η ευπάθεια προκύπτει όταν, μετά την αναβάθμιση μιας σύνδεσης, ο αντίστροφος διακομιστής (reverse proxy) σταματά να διαχειρίζεται μεμονωμένα αιτήματα, υποθέτοντας ότι η εργασία του για δρομολόγηση έχει ολοκληρωθεί μετά την εγκαθίδρυση της σύνδεσης. Η εκμετάλλευση του H2C Smuggling επιτρέπει την παράκαμψη των κανόνων του αντίστροφου διακομιστή που εφαρμόζονται κατά την επεξεργασία αιτημάτων, όπως η δρομολόγηση βάσει διαδρομής, η αυθεντικοποίηση και η επεξεργασία WAF, υποθέτοντας ότι μια σύνδεση H2C έχει ξεκινήσει με επιτυχία.
Η ευπάθεια εξαρτάται από την διαχείριση των κεφαλίδων Upgrade και μερικές φορές Connection από τον αντίστροφο διακομιστή. Οι παρακάτω διακομιστές προωθούν εγγενώς αυτές τις κεφαλίδες κατά τη διάρκεια του proxy-pass, επιτρέποντας έτσι εγγενώς το H2C smuggling:
HAProxy
Traefik
Nuster
Αντίθετα, αυτές οι υπηρεσίες δεν προωθούν εγγενώς και τις δύο κεφαλίδες κατά τη διάρκεια του proxy-pass. Ωστόσο, μπορεί να έχουν ρυθμιστεί ανασφαλώς, επιτρέποντας την απροστάτευτη προώθηση των κεφαλίδων Upgrade και Connection:
AWS ALB/CLB
NGINX
Apache
Squid
Varnish
Kong
Envoy
Apache Traffic Server
Είναι κρίσιμο να σημειωθεί ότι όχι όλοι οι διακομιστές προωθούν εγγενώς τις κεφαλίδες που απαιτούνται για μια συμμορφούμενη αναβάθμιση σύνδεσης H2C. Έτσι, διακομιστές όπως οι AWS ALB/CLB, NGINX και Apache Traffic Server, μεταξύ άλλων, μπλοκάρουν φυσικά τις συνδέσεις H2C. Παρ' όλα αυτά, αξίζει να δοκιμαστεί η μη συμμορφούμενη παραλλαγή Connection: Upgrade, η οποία εξαιρεί την τιμή HTTP2-Settings από την κεφαλίδα Connection, καθώς ορισμένα backend μπορεί να μην συμμορφώνονται με τα πρότυπα.
Ανεξαρτήτως της συγκεκριμένης διαδρομής που έχει οριστεί στο URL proxy_pass (π.χ., http://backend:9999/socket.io), η εγκαθιδρυμένη σύνδεση προεπιλέγεται σε http://backend:9999. Αυτό επιτρέπει την αλληλεπίδραση με οποιαδήποτε διαδρομή εντός αυτού του εσωτερικού σημείου, εκμεταλλευόμενοι αυτή την τεχνική. Ως εκ τούτου, η καθορισμένη διαδρομή στο URL proxy_pass δεν περιορίζει την πρόσβαση.
Τα εργαλεία h2csmuggler by BishopFox και h2csmuggler by assetnote διευκολύνουν τις προσπάθειες να παρακαμφθούν οι προστασίες που επιβάλλει ο διακομιστής δημιουργώντας μια σύνδεση H2C, επιτρέποντας έτσι την πρόσβαση σε πόρους που προστατεύονται από τον διακομιστή.
Για περισσότερες πληροφορίες σχετικά με αυτή την ευπάθεια, ιδιαίτερα όσον αφορά το NGINX, ανατρέξτε σε αυτή την λεπτομερή πηγή.
Το websocket smuggling, σε αντίθεση με τη δημιουργία ενός HTTP2 τούνελ σε ένα σημείο πρόσβασης μέσω ενός διακομιστή, δημιουργεί ένα Websocket τούνελ για να παρακάμψει πιθανές περιορισμούς του διακομιστή και να διευκολύνει την άμεση επικοινωνία με το σημείο πρόσβασης.
Σε αυτό το σενάριο, ένας backend που προσφέρει μια δημόσια WebSocket API μαζί με μια μη προσβάσιμη εσωτερική REST API στοχεύεται από έναν κακόβουλο πελάτη που επιδιώκει πρόσβαση στην εσωτερική REST API. Η επίθεση εξελίσσεται σε αρκετά βήματα:
Ο πελάτης ξεκινά στέλνοντας ένα αίτημα Upgrade στον αντίστροφο διακομιστή με μια λανθασμένη έκδοση πρωτοκόλλου Sec-WebSocket-Version στην κεφαλίδα. Ο διακομιστής, αποτυγχάνοντας να επικυρώσει την κεφαλίδα Sec-WebSocket-Version, πιστεύει ότι το αίτημα Upgrade είναι έγκυρο και το προωθεί στον backend.
Ο backend απαντά με έναν κωδικό κατάστασης 426, υποδεικνύοντας την λανθασμένη έκδοση πρωτοκόλλου στην κεφαλίδα Sec-WebSocket-Version. Ο αντίστροφος διακομιστής, παραβλέποντας την κατάσταση της απάντησης του backend, υποθέτει ότι είναι έτοιμος για επικοινωνία WebSocket και μεταφέρει την απάντηση στον πελάτη.
Ως εκ τούτου, ο αντίστροφος διακομιστής παραπλανείται να πιστεύει ότι έχει εγκατασταθεί μια σύνδεση WebSocket μεταξύ του πελάτη και του backend, ενώ στην πραγματικότητα, ο backend είχε απορρίψει το αίτημα Upgrade. Παρ' όλα αυτά, ο διακομιστής διατηρεί μια ανοιχτή σύνδεση TCP ή TLS μεταξύ του πελάτη και του backend, επιτρέποντας στον πελάτη απεριόριστη πρόσβαση στην ιδιωτική REST API μέσω αυτής της σύνδεσης.
Οι επηρεαζόμενοι αντίστροφοι διακομιστές περιλαμβάνουν το Varnish, το οποίο αρνήθηκε να αντιμετωπίσει το ζήτημα, και την έκδοση 1.8.0 ή παλαιότερη του Envoy proxy, με τις μεταγενέστερες εκδόσεις να έχουν τροποποιήσει τον μηχανισμό αναβάθμισης. Άλλοι διακομιστές μπορεί επίσης να είναι ευάλωτοι.
Αυτό το σενάριο περιλαμβάνει έναν backend με δημόσια WebSocket API και δημόσια REST API για έλεγχο υγείας, μαζί με μια μη προσβάσιμη εσωτερική REST API. Η επίθεση, πιο περίπλοκη, περιλαμβάνει τα εξής βήματα:
Ο πελάτης στέλνει ένα αίτημα POST για να ενεργοποιήσει την API ελέγχου υγείας, συμπεριλαμβάνοντας μια επιπλέον κεφαλίδα HTTP Upgrade: websocket. Ο NGINX, που λειτουργεί ως αντίστροφος διακομιστής, ερμηνεύει αυτό ως ένα τυπικό αίτημα Upgrade βασισμένο αποκλειστικά στην κεφαλίδα Upgrade, παραβλέποντας τις άλλες πτυχές του αιτήματος, και το προωθεί στον backend.
Ο backend εκτελεί την API ελέγχου υγείας, επικοινωνώντας με έναν εξωτερικό πόρο που ελέγχεται από τον επιτιθέμενο, ο οποίος επιστρέφει μια HTTP απάντηση με κωδικό κατάστασης 101. Αυτή η απάντηση, μόλις ληφθεί από τον backend και προωθηθεί στον NGINX, παραπλανεί τον διακομιστή να πιστεύει ότι έχει εγκατασταθεί μια σύνδεση WebSocket λόγω της επικύρωσης μόνο του κωδικού κατάστασης.
Προειδοποίηση: Η πολυπλοκότητα αυτής της τεχνικής αυξάνεται καθώς απαιτεί τη δυνατότητα αλληλεπίδρασης με ένα σημείο πρόσβασης ικανό να επιστρέφει έναν κωδικό κατάστασης 101.
Τελικά, ο NGINX παραπλανείται να πιστεύει ότι υπάρχει μια σύνδεση WebSocket μεταξύ του πελάτη και του backend. Στην πραγματικότητα, δεν υπάρχει τέτοια σύνδεση· η API ελέγχου υγείας ήταν ο στόχος. Παρ' όλα αυτά, ο αντίστροφος διακομιστής διατηρεί την σύνδεση ανοιχτή, επιτρέποντας στον πελάτη να έχει πρόσβαση στην ιδιωτική REST API μέσω αυτής.
Οι περισσότεροι αντίστροφοι διακομιστές είναι ευάλωτοι σε αυτό το σενάριο, αλλά η εκμετάλλευση εξαρτάται από την παρουσία μιας εξωτερικής ευπάθειας SSRF, η οποία συνήθως θεωρείται χαμηλής σοβαρότητας.
Ελέγξτε τα εργαστήρια για να δοκιμάσετε και τα δύο σενάρια στο https://github.com/0ang3el/websocket-smuggle.git
Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
