mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
133 lines
15 KiB
Markdown
133 lines
15 KiB
Markdown
# HTTP Response Smuggling / Desync
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|
||
|
||
**Η τεχνική αυτού του άρθρου προήλθε από το βίντεο:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](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 απάντηση δεν θα εισαχθεί μέσα στην ουρά της απάντησης του θύματος αλλά θα **απλώς απορριφθεί ως σφάλμα**.
|
||
|
||
.png>)
|
||
|
||
Επομένως, είναι απαραίτητο το **smuggled** **αίτημα** **να χρειάζεται περισσότερο χρόνο για να επεξεργαστεί** μέσα στον backend server. Έτσι, μέχρι τη στιγμή που το smuggled αίτημα επεξεργάζεται, η επικοινωνία με τον επιτιθέμενο θα έχει τελειώσει.
|
||
|
||
Αν σε αυτή τη συγκεκριμένη κατάσταση ένα **θύμα έχει στείλει ένα αίτημα** και το **smuggled αίτημα απαντηθεί πριν** από το νόμιμο αίτημα, η **smuggled απάντηση θα σταλεί στο θύμα**. Επομένως, ο επιτιθέμενος θα **ελέγχει το αίτημα που "εκτελείται" από το θύμα**.
|
||
|
||
Επιπλέον, αν ο **επιτιθέμενος εκτελέσει ένα αίτημα** και η **νόμιμη απάντηση** στο **αίτημα** του **θύματος** **απαντηθεί** **πριν** από το αίτημα του επιτιθέμενου. Η **απάντηση στο θύμα θα σταλεί στον επιτιθέμενο**, **κλέβοντας** την απάντηση προς το θύμα (η οποία μπορεί να περιέχει για παράδειγμα την κεφαλίδα **Set-Cookie**).
|
||
|
||
.png>)
|
||
|
||
.png>)
|
||
|
||
### 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 <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||
|
||
Όπως με τα γνωστά payloads HTTP Request Smuggling, μπορείτε να **κλέψετε το αίτημα του θύματος** με μια σημαντική διαφορά: Σε αυτή την περίπτωση χρειάζεστε απλώς το **περιεχόμενο που θα ανακλαστεί στην απάντηση**, **δεν απαιτείται μόνιμη αποθήκευση**.
|
||
|
||
Πρώτα, ο επιτιθέμενος στέλνει ένα payload που περιέχει ένα **τελικό POST αίτημα με την ανακλαστική παράμετρο** στο τέλος και μια μεγάλη Content-Length.
|
||
|
||
.png>)
|
||
|
||
Στη συνέχεια, μόλις το **αρχικό αίτημα** (μπλε) **επεξεργαστεί** και **ενώ** το **ύπνο** αίτημα επεξεργάζεται (κίτρινο), το **επόμενο αίτημα που φτάνει από ένα θύμα** θα **προστεθεί στην ουρά αμέσως μετά την ανακλαστική παράμετρο**:
|
||
|
||
.png>)
|
||
|
||
Στη συνέχεια, το **θύμα** θα **λάβει** την **απάντηση** στο **ύπνο** αίτημα και αν εν τω μεταξύ ο **επιτιθέμενος** **έστειλε** **ένα άλλο** **αίτημα**, η **απάντηση από το αίτημα ανακλαστικού περιεχομένου θα σταλεί σε αυτόν**.
|
||
|
||
## Response Desynchronisation
|
||
|
||
Μέχρι αυτό το σημείο, έχουμε μάθει πώς να καταχραστούμε τις επιθέσεις HTTP Request Smuggling για να **ελέγξουμε** το **αίτημα** **του οποίου** **η απάντηση** θα **λάβει** ένας **πελάτης** και πώς μπορείτε στη συνέχεια να **κλέψετε την απάντηση που προοριζόταν για το θύμα**.
|
||
|
||
Αλλά είναι ακόμα δυνατό να **αποσυγχρονίσουμε ακόμα** περισσότερες απαντήσεις.
|
||
|
||
Υπάρχουν ενδιαφέροντα αιτήματα όπως το **HEAD** αίτημα που καθορίζεται να μην έχει **κανένα περιεχόμενο μέσα στο σώμα των απαντήσεων** και που θα πρέπει (πρέπει) να **περιέχει την Content-Length** του αιτήματος όπως **αν ήταν ένα GET αίτημα**.
|
||
|
||
Επομένως, αν ένας επιτιθέμενος **εισάγει** ένα **HEAD** αίτημα, όπως στις παρακάτω εικόνες:
|
||
|
||
.png>)
|
||
|
||
Στη συνέχεια, **μόλις το μπλε απαντηθεί στον επιτιθέμενο**, το επόμενο αίτημα του θύματος θα εισαχθεί στην ουρά:
|
||
|
||
.png>)
|
||
|
||
Στη συνέχεια, το **θύμα** θα **λάβει** την **απάντηση** από το **HEAD** αίτημα, το οποίο **θα περιέχει μια Content-Length αλλά καθόλου περιεχόμενο**. Επομένως, ο proxy **δεν θα στείλει αυτή την απάντηση** στο θύμα, αλλά θα **περιμένει** για κάποιο **περιεχόμενο**, το οποίο στην πραγματικότητα θα είναι η **απάντηση στο κίτρινο αίτημα** (επίσης εισαχθέν από τον επιτιθέμενο):
|
||
|
||
.png>)
|
||
|
||
### Content Confusion
|
||
|
||
Ακολουθώντας το προηγούμενο παράδειγμα, γνωρίζοντας ότι μπορείτε να **ελέγξετε το σώμα** του αιτήματος του οποίου η απάντηση θα λάβει το θύμα και ότι μια **HEAD** **απάντηση** συνήθως περιέχει στα headers της την **Content-Type και την Content-Length**, μπορείτε να **στείλετε ένα αίτημα όπως το παρακάτω** για να **προκαλέσετε XSS** στο θύμα χωρίς η σελίδα να είναι ευάλωτη σε XSS:
|
||
|
||
.png>)
|
||
|
||
### Cache Poisoning
|
||
|
||
Καταχρώντας την προηγουμένως σχολιασμένη επίθεση αποσυγχρονισμού απάντησης Content Confusion, **αν η cache αποθηκεύει την απάντηση στο αίτημα που εκτελέστηκε από το θύμα και αυτή η απάντηση είναι μια εισαχθείσα που προκαλεί XSS, τότε η cache είναι δηλητηριασμένη**.
|
||
|
||
Κακόβουλο αίτημα που περιέχει το payload XSS:
|
||
|
||
.png>)
|
||
|
||
Κακόβουλη απάντηση προς το θύμα που περιέχει την κεφαλίδα που υποδεικνύει στην cache να αποθηκεύσει την απάντηση:
|
||
|
||
.png>)
|
||
|
||
> [!WARNING]
|
||
> Σημειώστε ότι σε αυτή την περίπτωση αν ο **"θύμα" είναι ο επιτιθέμενος** μπορεί τώρα να εκτελέσει **δηλητηρίαση cache σε αυθαίρετες διευθύνσεις URL** καθώς μπορεί να **ελέγξει τη διεύθυνση URL που θα αποθηκευτεί στην cache** με την κακόβουλη απάντηση.
|
||
|
||
### Web Cache Deception
|
||
|
||
Αυτή η επίθεση είναι παρόμοια με την προηγούμενη, αλλά **αντί να εισάγει ένα payload μέσα στην cache, ο επιτιθέμενος θα αποθηκεύει πληροφορίες του θύματος μέσα στην cache:**
|
||
|
||
.png>)
|
||
|
||
### Response Splitting
|
||
|
||
Ο **στόχος** αυτής της επίθεσης είναι να καταχραστεί ξανά την **αποσυγχρονισμένη** **απάντηση** προκειμένου να **κάνει τον proxy να στείλει μια 100% απάντηση που έχει δημιουργηθεί από τον επιτιθέμενο**.
|
||
|
||
Για να το επιτύχει αυτό, ο επιτιθέμενος πρέπει να βρει ένα endpoint της διαδικτυακής εφαρμογής που **αντικατοπτρίζει κάποιες τιμές μέσα στην απάντηση** και **να γνωρίζει την Content-Length της HEAD απάντησης**.
|
||
|
||
Θα στείλει ένα **exploit** όπως:
|
||
|
||
.png>)
|
||
|
||
Αφού το πρώτο αίτημα επιλυθεί και σταλεί πίσω στον επιτιθέμενο, το **αίτημα του θύματος προστίθεται στην ουρά**:
|
||
|
||
.png>)
|
||
|
||
Το θύμα θα λάβει ως απάντηση την **HEAD απάντηση + το περιεχόμενο της δεύτερης απάντησης (περιέχοντας μέρος των ανακλαστικών δεδομένων):**
|
||
|
||
.png>)
|
||
|
||
Ωστόσο, σημειώστε πώς τα **ανακλαστικά δεδομένα είχαν μέγεθος σύμφωνα με την Content-Length** της **HEAD** απάντησης που **δημιούργησε μια έγκυρη HTTP απάντηση στην ουρά απαντήσεων**.
|
||
|
||
Επομένως, το **επόμενο αίτημα του δεύτερου θύματος** θα **λαμβάνει** ως **απάντηση κάτι εντελώς κατασκευασμένο από τον επιτιθέμενο**. Καθώς η απάντηση είναι εντελώς κατασκευασμένη από τον επιτιθέμενο, μπορεί επίσης να **κάνει τον proxy να αποθηκεύσει την απάντηση στην cache**.
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|