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 που θα αποθηκευτεί με την κακόβουλη απάντηση.
Αυτή η επίθεση είναι παρόμοια με την προηγούμενη, αλλά αντί να εισάγει ένα payload μέσα στην cache, ο επιτιθέμενος θα αποθηκεύει πληροφορίες του θύματος μέσα στην cache:
Ο στόχος αυτής της επίθεσης είναι να καταχραστεί ξανά την αποσυγχρονισμένη απάντηση προκειμένου να κάνει τον proxy να στείλει μια 100% απάντηση που έχει δημιουργηθεί από τον επιτιθέμενο.
Για να το επιτύχει αυτό, ο επιτιθέμενος πρέπει να βρει ένα endpoint της διαδικτυακής εφαρμογής που αντικατοπτρίζει κάποιες τιμές μέσα στην απάντηση και να γνωρίζει την Content-Length της HEAD απάντησης.
Θα στείλει μια εκμετάλλευση όπως:
Αφού η πρώτη αίτηση επιλυθεί και σταλεί πίσω στον επιτιθέμενο, η αίτηση του θύματος προστίθεται στην ουρά:
Το θύμα θα λάβει ως απάντηση την HEAD απάντηση + το περιεχόμενο της δεύτερης αίτησης (που περιέχει μέρος των ανακλαστικών δεδομένων):
Ωστόσο, σημειώστε πώς τα ανακλαστικά δεδομένα είχαν μέγεθος σύμφωνα με την Content-Length της HEAD απάντησης που δημιούργησε μια έγκυρη HTTP απάντηση στην ουρά απαντήσεων.
Επομένως, η επόμενη αίτηση του δεύτερου θύματος θα λαμβάνει ως απάντηση κάτι εντελώς κατασκευασμένο από τον επιτιθέμενο. Καθώς η απάντηση είναι εντελώς κατασκευασμένη από τον επιτιθέμενο, μπορεί επίσης να κάνει τον proxy να αποθηκεύσει την απάντηση.
Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
