HTTP Response Smuggling / Desync
Last updated
Last updated
Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Η τεχνική αυτού του άρθρου προήλθε από το βίντεο: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
Πρώτα απ' όλα, αυτή η τεχνική καταχράται μια ευπάθεια HTTP Request Smuggling, οπότε πρέπει να γνωρίζετε τι είναι αυτό:
Η κύρια διαφορά μεταξύ αυτής της τεχνικής και μιας κοινής HTTP Request smuggling είναι ότι αντί να επιτίθεται στο αίτημα του θύματος προσθέτοντας ένα πρόθεμα σε αυτό, θα διαρρεύσουμε ή θα τροποποιήσουμε την απάντηση που λαμβάνει το θύμα. Αυτό γίνεται στέλνοντας, αντί να στείλουμε 1 αίτημα και μισό για να καταχραστούμε το HTTP Request smuggling, 2 πλήρη αιτήματα για να αποσυγχρονίσουμε την ουρά απαντήσεων των proxies.
Αυτό συμβαίνει επειδή θα μπορέσουμε να αποσυγχρονίσουμε την ουρά απαντήσεων έτσι ώστε η απάντηση από το νόμιμο αίτημα του θύματος να σταλεί στον επιτιθέμενο, ή εισάγοντας περιεχόμενο που ελέγχεται από τον επιτιθέμενο στην απάντηση προς το θύμα.
HTTP/1.1 επιτρέπει να ζητάμε διαφορετικούς πόρους χωρίς να χρειάζεται να περιμένουμε για τους προηγούμενους. Επομένως, αν υπάρχει ένας proxy στη μέση, είναι καθήκον του proxy να διατηρεί μια συγχρονισμένη αντιστοίχιση των αιτημάτων που αποστέλλονται στο backend και των απαντήσεων που προέρχονται από αυτό.
Ωστόσο, υπάρχει ένα πρόβλημα με την αποσυγχρονισμένη ουρά απαντήσεων. Αν ένας επιτιθέμενος στείλει μια επίθεση HTTP Response smuggling και οι απαντήσεις στο αρχικό αίτημα και το smuggled απαντηθούν αμέσως, η smuggled απάντηση δεν θα εισαχθεί μέσα στην ουρά της απάντησης του θύματος αλλά θα απλώς απορριφθεί ως σφάλμα.
Επομένως, είναι απαραίτητο το smuggled αίτημα να χρειάζεται περισσότερο χρόνο για να επεξεργαστεί μέσα στον backend server. Επομένως, μέχρι τη στιγμή που το smuggled αίτημα επεξεργάζεται, η επικοινωνία με τον επιτιθέμενο θα έχει τελειώσει.
Αν σε αυτή τη συγκεκριμένη κατάσταση ένα θύμα έχει στείλει ένα αίτημα και το smuggled αίτημα απαντηθεί πριν από το νόμιμο αίτημα, η smuggled απάντηση θα σταλεί στο θύμα. Επομένως, ο επιτιθέμενος θα ελέγχει το αίτημα "που εκτελείται" από το θύμα.
Επιπλέον, αν ο επιτιθέμενος εκτελέσει στη συνέχεια ένα αίτημα και η νόμιμη απάντηση στο αίτημα του θύματος απαντηθεί πριν από το αίτημα του επιτιθέμενου. Η απάντηση στο θύμα θα σταλεί στον επιτιθέμενο, κλέβοντας την απάντηση προς το θύμα (η οποία μπορεί να περιέχει για παράδειγμα την κεφαλίδα Set-Cookie).
Μια άλλη ενδιαφέρουσα διαφορά με την κοινή HTTP Request Smuggling είναι ότι, σε μια κοινή επίθεση smuggling, ο στόχος είναι να τροποποιηθεί η αρχή του αιτήματος του θύματος ώστε να εκτελέσει μια απροσδόκητη ενέργεια. Σε μια HTTP Response smuggling επίθεση, καθώς στέλνετε πλήρη αιτήματα, μπορείτε να εισάγετε σε ένα payload δεκάδες απαντήσεις που θα αποσυγχρονίζουν δεκάδες χρήστες που θα λαμβάνουν τις εισαγμένες απαντήσεις.
Εκτός από το ότι μπορείτε να κατανείμετε πιο εύκολα δεκάδες exploits σε νόμιμους χρήστες, αυτό θα μπορούσε επίσης να χρησιμοποιηθεί για να προκαλέσει μια DoS στον server.
Όπως εξηγήθηκε προηγουμένως, για να καταχραστείτε αυτή την τεχνική, είναι απαραίτητο το πρώτο smuggled μήνυμα προς τον server να απαιτεί πολύ χρόνο για να επεξεργαστεί.
Αυτή η χρονικά απαιτητική αίτηση είναι αρκετή αν θέλουμε απλώς να προσπαθήσουμε να κλέψουμε την απάντηση του θύματος. Αλλά αν θέλετε να εκτελέσετε μια πιο σύνθετη εκμετάλλευση, αυτή θα είναι μια κοινή δομή για την εκμετάλλευση.
Πρώτα απ' όλα το αρχικό αίτημα που καταχράται το HTTP Request smuggling, στη συνέχεια το χρονικά απαιτητικό αίτημα και μετά 1 ή περισσότερα payload αιτήματα των οποίων οι απαντήσεις θα σταλούν στα θύματα.
Όπως με τα γνωστά payloads HTTP Request Smuggling, μπορείτε να κλέψετε το αίτημα του θύματος με μια σημαντική διαφορά: Σε αυτή την περίπτωση χρειάζεστε απλώς το περιεχόμενο που θα ανακλαστεί στην απάντηση, δεν απαιτείται μόνιμη αποθήκευση.
Πρώτα, ο επιτιθέμενος στέλνει ένα payload που περιέχει ένα τελικό POST αίτημα με την ανακλαστική παράμετρο στο τέλος και μια μεγάλη Content-Length
Στη συνέχεια, μόλις το αρχικό αίτημα (μπλε) επεξεργαστεί και ενώ το ύπνο αίτημα επεξεργάζεται (κίτρινο), το επόμενο αίτημα που φτάνει από ένα θύμα θα προστεθεί στην ουρά αμέσως μετά την ανακλαστική παράμετρο:
Στη συνέχεια, το θύμα θα λάβει την απάντηση στο ύπνο αίτημα και αν εν τω μεταξύ ο επιτιθέμενος έστειλε ένα άλλο αίτημα, η απάντηση από το αίτημα ανακλαστικού περιεχομένου θα σταλεί σε αυτόν.
Μέχρι αυτό το σημείο, έχουμε μάθει πώς να καταχραστούμε τις επιθέσεις HTTP Request Smuggling για να ελέγξουμε το αίτημα του οποίου η απάντηση θα λάβει ένας πελάτης και πώς μπορείτε στη συνέχεια να κλέψετε την απάντηση που προοριζόταν για το θύμα.
Αλλά είναι ακόμα δυνατό να αποσυγχρονίσουμε ακόμα περισσότερες απαντήσεις.
Υπάρχουν ενδιαφέροντα αιτήματα όπως το HEAD αίτημα που είναι καθορισμένα να μην έχουν κανένα περιεχόμενο μέσα στο σώμα των απαντήσεων και που θα πρέπει (πρέπει) να περιέχουν την Content-Length του αιτήματος όπως αν ήταν ένα GET αίτημα.
Επομένως, αν ένας επιτιθέμενος εισάγει ένα HEAD αίτημα, όπως στις παρακάτω εικόνες:
Στη συνέχεια, μόλις το μπλε απαντηθεί στον επιτιθέμενο, το επόμενο αίτημα του θύματος θα εισαχθεί στην ουρά:
Στη συνέχεια, το θύμα θα λάβει την απάντηση από το HEAD αίτημα, το οποίο θα περιέχει μια Content-Length αλλά καθόλου περιεχόμενο. Επομένως, ο proxy δεν θα στείλει αυτή την απάντηση στο θύμα, αλλά θα περιμένει για κάποιο περιεχόμενο, το οποίο στην πραγματικότητα θα είναι η απάντηση στο κίτρινο αίτημα (επίσης εισαχθέν από τον επιτιθέμενο):
Ακολουθώντας το προηγούμενο παράδειγμα, γνωρίζοντας ότι μπορείτε να ελέγξετε το σώμα του αιτήματος του οποίου η απάντηση θα λάβει το θύμα και ότι μια HEAD απάντηση συνήθως περιέχει στα headers της την Content-Type και την Content-Length, μπορείτε να στείλετε ένα αίτημα όπως το παρακάτω για να προκαλέσετε XSS στο θύμα χωρίς η σελίδα να είναι ευάλωτη σε XSS:
Καταχρώντας την προηγουμένως σχολιασμένη επίθεση αποσυγχρονισμού απάντησης Content Confusion, αν η cache αποθηκεύει την απάντηση στο αίτημα που εκτελέστηκε από το θύμα και αυτή η απάντηση είναι μια εισαχθείσα που προκαλεί XSS, τότε η cache είναι δηλητηριασμένη.
Κακόβουλο αίτημα που περιέχει το payload XSS:
Κακόβουλη απάντηση προς το θύμα που περιέχει την κεφαλίδα που υποδεικνύει στην cache να αποθηκεύσει την απάντηση:
Σημειώστε ότι σε αυτή την περίπτωση αν ο "θύμα" είναι ο επιτιθέμενος μπορεί τώρα να εκτελέσει δηλητηρίαση cache σε αυθαίρετες διευθύνσεις URL καθώς μπορεί να ελέγξει τη διεύθυνση URL που θα αποθηκευτεί στην cache με την κακόβουλη απάντηση.
Αυτή η επίθεση είναι παρόμοια με την προηγούμενη, αλλά αντί να εισάγει ένα payload μέσα στην cache, ο επιτιθέμενος θα αποθηκεύει πληροφορίες του θύματος μέσα στην cache:
Ο στόχος αυτής της επίθεσης είναι να καταχραστεί ξανά την αποσυγχρονισμένη απάντηση προκειμένου να κάνει τον proxy να στείλει μια 100% απάντηση που έχει δημιουργηθεί από τον επιτιθέμενο.
Για να το πετύχει αυτό, ο επιτιθέμενος πρέπει να βρει ένα endpoint της διαδικτυακής εφαρμογής που αντικατοπτρίζει κάποιες τιμές μέσα στην απάντηση και να γνωρίζει την Content-Length της HEAD απάντησης.
Θα στείλει μια εκμετάλλευση όπως:
Αφού το πρώτο αίτημα επιλυθεί και σταλεί πίσω στον επιτιθέμενο, το αίτημα του θύματος προστίθεται στην ουρά:
Το θύμα θα λάβει ως απάντηση την HEAD απάντηση + το περιεχόμενο της δεύτερης απάντησης (που περιέχει μέρος των αντικατοπτριζόμενων δεδομένων):
Ωστόσο, σημειώστε πώς τα αντικατοπτριζόμενα δεδομένα είχαν μέγεθος σύμφωνα με την Content-Length της HEAD απάντησης που δημιούργησε μια έγκυρη HTTP απάντηση στην ουρά απαντήσεων.
Επομένως, το επόμενο αίτημα του δεύτερου θύματος θα λαμβάνει ως απάντηση κάτι εντελώς κατασκευασμένο από τον επιτιθέμενο. Καθώς η απάντηση είναι εντελώς κατασκευασμένη από τον επιτιθέμενο, μπορεί επίσης να κάνει τον proxy να αποθηκεύσει την απάντηση στην cache.
Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
