HTTP Response Smuggling / Desync

Reading time: 8 minutes

Η τεχνική αυτού του άρθρου προήλθε από το βίντεο: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s

HTTP Request Queue Desynchronisation

Πρώτα απ' όλα, αυτή η τεχνική καταχράται μια ευπάθεια HTTP Request Smuggling, οπότε πρέπει να ξέρετε τι είναι αυτό:

Η κύρια διαφορά μεταξύ αυτής της τεχνικής και μιας κοινής HTTP Request smuggling είναι ότι αντί να επιτίθεται στο αίτημα του θύματος προσθέτοντας ένα πρόθεμα σε αυτό, θα διαρρεύσουμε ή θα τροποποιήσουμε την απάντηση που λαμβάνει το θύμα. Αυτό γίνεται στέλνοντας, αντί να στείλουμε 1 αίτημα και μισό για να καταχραστούμε το HTTP Request smuggling, 2 πλήρη αιτήματα για να αποσυγχρονίσουμε την ουρά απαντήσεων των proxies.

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

HTTP Pipeline Desync

HTTP/1.1 επιτρέπει να ζητάμε διαφορετικούς πόρους χωρίς να χρειάζεται να περιμένουμε για τους προηγούμενους. Επομένως, αν υπάρχει ένας proxy στη μέση, είναι καθήκον του proxy να διατηρεί μια συγχρονισμένη αντιστοίχιση αιτημάτων που αποστέλλονται στο backend και απαντήσεων που προέρχονται από αυτό.

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

Επομένως, είναι απαραίτητο το smuggled αίτημα να χρειάζεται περισσότερο χρόνο για να επεξεργαστεί μέσα στον backend server. Έτσι, μέχρι τη στιγμή που το smuggled αίτημα επεξεργάζεται, η επικοινωνία με τον επιτιθέμενο θα έχει τελειώσει.

Αν σε αυτή τη συγκεκριμένη κατάσταση ένα θύμα έχει στείλει ένα αίτημα και το smuggled αίτημα απαντηθεί πριν από το νόμιμο αίτημα, η smuggled απάντηση θα σταλεί στο θύμα. Επομένως, ο επιτιθέμενος θα ελέγχει το αίτημα που "εκτελείται" από το θύμα.

Επιπλέον, αν ο επιτιθέμενος εκτελέσει ένα αίτημα και η νόμιμη απάντηση στο αίτημα του θύματος απαντηθεί πριν από το αίτημα του επιτιθέμενου. Η απάντηση στο θύμα θα σταλεί στον επιτιθέμενο, κλέβοντας την απάντηση προς το θύμα (η οποία μπορεί να περιέχει για παράδειγμα την κεφαλίδα Set-Cookie).

Multiple Nested Injections

Μια άλλη ενδιαφέρουσα διαφορά με την κοινή HTTP Request Smuggling είναι ότι, σε μια κοινή επίθεση smuggling, ο στόχος είναι να τροποποιηθεί η αρχή του αιτήματος του θύματος ώστε να εκτελέσει μια απροσδόκητη ενέργεια. Σε μια HTTP Response smuggling επίθεση, καθώς στέλνετε πλήρη αιτήματα, μπορείτε να εισάγετε σε ένα payload δεκάδες απαντήσεις που θα αποσυγχρονίζουν δεκάδες χρήστες που θα λαμβάνουν τις εισαγμένες απαντήσεις.

Εκτός από το ότι μπορείτε να κατανείμετε πιο εύκολα δεκάδες exploits σε νόμιμους χρήστες, αυτό θα μπορούσε επίσης να χρησιμοποιηθεί για να προκαλέσει μια DoS στον server.

Exploit Organisation

Όπως εξηγήθηκε προηγουμένως, για να καταχραστείτε αυτή την τεχνική, είναι απαραίτητο το πρώτο smuggled μήνυμα προς τον server να απαιτεί πολύ χρόνο για να επεξεργαστεί.

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

Πρώτα απ' όλα το αρχικό αίτημα που καταχράται το HTTP Request smuggling, στη συνέχεια το χρονικά απαιτητικό αίτημα και μετά 1 ή περισσότερα payload αιτήματα των οποίων οι απαντήσεις θα σταλούν στα θύματα.

Abusing HTTP Response Queue Desynchronisation

Capturing other users' requests

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

Πρώτα, ο επιτιθέμενος στέλνει ένα payload που περιέχει ένα τελικό POST αίτημα με την ανακλαστική παράμετρο στο τέλος και μια μεγάλη Content-Length.

Στη συνέχεια, μόλις το αρχικό αίτημα (μπλε) επεξεργαστεί και ενώ το ύπνο αίτημα επεξεργάζεται (κίτρινο), το επόμενο αίτημα που φτάνει από ένα θύμα θα προστεθεί στην ουρά αμέσως μετά την ανακλαστική παράμετρο:

Στη συνέχεια, το θύμα θα λάβει την απάντηση στο ύπνο αίτημα και αν εν τω μεταξύ ο επιτιθέμενος έστειλε ένα άλλο αίτημα, η απάντηση από το αίτημα ανακλαστικού περιεχομένου θα σταλεί σε αυτόν.

Response Desynchronisation

Μέχρι αυτό το σημείο, έχουμε μάθει πώς να καταχραστούμε τις επιθέσεις HTTP Request Smuggling για να ελέγξουμε το αίτημα του οποίου η απάντηση θα λάβει ένας πελάτης και πώς μπορείτε στη συνέχεια να κλέψετε την απάντηση που προοριζόταν για το θύμα.

Αλλά είναι ακόμα δυνατό να αποσυγχρονίσουμε ακόμα περισσότερες απαντήσεις.

Υπάρχουν ενδιαφέροντα αιτήματα όπως το HEAD αίτημα που καθορίζεται να μην έχει κανένα περιεχόμενο μέσα στο σώμα των απαντήσεων και που θα πρέπει (πρέπει) να περιέχει την Content-Length του αιτήματος όπως αν ήταν ένα GET αίτημα.

Επομένως, αν ένας επιτιθέμενος εισάγει ένα HEAD αίτημα, όπως στις παρακάτω εικόνες:

Στη συνέχεια, μόλις το μπλε απαντηθεί στον επιτιθέμενο, το επόμενο αίτημα του θύματος θα εισαχθεί στην ουρά:

Στη συνέχεια, το θύμα θα λάβει την απάντηση από το HEAD αίτημα, το οποίο θα περιέχει μια Content-Length αλλά καθόλου περιεχόμενο. Επομένως, ο proxy δεν θα στείλει αυτή την απάντηση στο θύμα, αλλά θα περιμένει για κάποιο περιεχόμενο, το οποίο στην πραγματικότητα θα είναι η απάντηση στο κίτρινο αίτημα (επίσης εισαχθέν από τον επιτιθέμενο):

Content Confusion

Ακολουθώντας το προηγούμενο παράδειγμα, γνωρίζοντας ότι μπορείτε να ελέγξετε το σώμα του αιτήματος του οποίου η απάντηση θα λάβει το θύμα και ότι μια HEAD απάντηση συνήθως περιέχει στα headers της την Content-Type και την Content-Length, μπορείτε να στείλετε ένα αίτημα όπως το παρακάτω για να προκαλέσετε XSS στο θύμα χωρίς η σελίδα να είναι ευάλωτη σε XSS:

Cache Poisoning

Καταχρώντας την προηγουμένως σχολιασμένη επίθεση αποσυγχρονισμού απάντησης Content Confusion, αν η cache αποθηκεύει την απάντηση στο αίτημα που εκτελέστηκε από το θύμα και αυτή η απάντηση είναι μια εισαχθείσα που προκαλεί XSS, τότε η cache είναι δηλητηριασμένη.

Κακόβουλο αίτημα που περιέχει το payload XSS:

Κακόβουλη απάντηση προς το θύμα που περιέχει την κεφαλίδα που υποδεικνύει στην cache να αποθηκεύσει την απάντηση:

Web Cache Deception

Αυτή η επίθεση είναι παρόμοια με την προηγούμενη, αλλά αντί να εισάγει ένα payload μέσα στην cache, ο επιτιθέμενος θα αποθηκεύει πληροφορίες του θύματος μέσα στην cache:

Response Splitting

Ο στόχος αυτής της επίθεσης είναι να καταχραστεί ξανά την αποσυγχρονισμένη απάντηση προκειμένου να κάνει τον proxy να στείλει μια 100% απάντηση που έχει δημιουργηθεί από τον επιτιθέμενο.

Για να το επιτύχει αυτό, ο επιτιθέμενος πρέπει να βρει ένα endpoint της διαδικτυακής εφαρμογής που αντικατοπτρίζει κάποιες τιμές μέσα στην απάντηση και να γνωρίζει την Content-Length της HEAD απάντησης.

Θα στείλει ένα exploit όπως:

Αφού το πρώτο αίτημα επιλυθεί και σταλεί πίσω στον επιτιθέμενο, το αίτημα του θύματος προστίθεται στην ουρά:

Το θύμα θα λάβει ως απάντηση την HEAD απάντηση + το περιεχόμενο της δεύτερης απάντησης (περιέχοντας μέρος των ανακλαστικών δεδομένων):

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

Επομένως, το επόμενο αίτημα του δεύτερου θύματος θα λαμβάνει ως απάντηση κάτι εντελώς κατασκευασμένο από τον επιτιθέμενο. Καθώς η απάντηση είναι εντελώς κατασκευασμένη από τον επιτιθέμενο, μπορεί επίσης να κάνει τον proxy να αποθηκεύσει την απάντηση στην cache.