Cache Poisoning and Cache Deception
Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F916570657-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fr3Cb8nKOYrlGZdSyjbAy%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=9fbb29e6&sv=1)
Χρησιμοποιήστε Trickest για να δημιουργήσετε και να αυτοματοποιήσετε ροές εργασίας που υποστηρίζονται από τα πιο προηγμένα εργαλεία της κοινότητας. Αποκτήστε πρόσβαση σήμερα:
Η διαφορά
Ποια είναι η διαφορά μεταξύ της δηλητηρίασης της μνήμης cache και της απάτης μνήμης cache;
Στη δηλητηρίαση μνήμης cache, ο επιτιθέμενος προκαλεί την εφαρμογή να αποθηκεύσει κάποιο κακόβουλο περιεχόμενο στη μνήμη cache, και αυτό το περιεχόμενο σερβίρεται από τη μνήμη cache σε άλλους χρήστες της εφαρμογής.
Στην απάτη μνήμης cache, ο επιτιθέμενος προκαλεί την εφαρμογή να αποθηκεύσει κάποιο ευαίσθητο περιεχόμενο που ανήκει σε άλλο χρήστη στη μνήμη cache, και ο επιτιθέμενος στη συνέχεια ανακτά αυτό το περιεχόμενο από τη μνήμη cache.
Δηλητηρίαση Cache
Η δηλητηρίαση cache στοχεύει στη χειραγώγηση της μνήμης cache πλευράς πελάτη για να αναγκάσει τους πελάτες να φορτώσουν πόρους που είναι απροσδόκητοι, μερικοί ή υπό τον έλεγχο ενός επιτιθέμενου. Η έκταση της επίδρασης εξαρτάται από τη δημοτικότητα της επηρεαζόμενης σελίδας, καθώς η μολυσμένη απάντηση σερβίρεται αποκλειστικά σε χρήστες που επισκέπτονται τη σελίδα κατά την περίοδο μόλυνσης της cache.
Η εκτέλεση μιας επίθεσης δηλητηρίασης cache περιλαμβάνει αρκετά βήματα:
Ταυτοποίηση Μη Κλειδωμένων Εισόδων: Αυτές είναι παράμετροι που, αν και δεν απαιτούνται για να αποθηκευτεί ένα αίτημα στη μνήμη cache, μπορούν να αλλάξουν την απάντηση που επιστρέφει ο διακομιστής. Η ταυτοποίηση αυτών των εισόδων είναι κρίσιμη καθώς μπορούν να εκμεταλλευτούν για να χειραγωγήσουν τη μνήμη cache.
Εκμετάλλευση των Μη Κλειδωμένων Εισόδων: Αφού ταυτοποιηθούν οι μη κλειδωμένες είσοδοι, το επόμενο βήμα περιλαμβάνει την ανακάλυψη του τρόπου κακής χρήσης αυτών των παραμέτρων για να τροποποιηθεί η απάντηση του διακομιστή με τρόπο που να ωφελεί τον επιτιθέμενο.
Διασφάλιση ότι η Μολυσμένη Απάντηση είναι Αποθηκευμένη: Το τελικό βήμα είναι να διασφαλιστεί ότι η χειραγωγημένη απάντηση αποθηκεύεται στη μνήμη cache. Με αυτόν τον τρόπο, οποιοσδήποτε χρήστης έχει πρόσβαση στη μολυσμένη σελίδα ενώ η μνήμη cache είναι δηλητηριασμένη θα λάβει την μολυσμένη απάντηση.
Ανακάλυψη: Έλεγχος HTTP headers
Συνήθως, όταν μια απάντηση έχει αποθηκευτεί στη μνήμη cache, θα υπάρχει μια κεφαλίδα που το υποδεικνύει, μπορείτε να ελέγξετε ποιες κεφαλίδες πρέπει να προσέξετε σε αυτή την ανάρτηση: HTTP Cache headers.
Ανακάλυψη: Κωδικοί σφάλματος caching
Αν σκέφτεστε ότι η απάντηση αποθηκεύεται σε μια μνήμη cache, θα μπορούσατε να προσπαθήσετε να στείλετε αιτήματα με κακή κεφαλίδα, η οποία θα πρέπει να απαντηθεί με κωδικό κατάστασης 400. Στη συνέχεια, προσπαθήστε να αποκτήσετε πρόσβαση στο αίτημα κανονικά και αν η απάντηση είναι κωδικός κατάστασης 400, ξέρετε ότι είναι ευάλωτο (και θα μπορούσατε ακόμη και να εκτελέσετε DoS).
Μπορείτε να βρείτε περισσότερες επιλογές στο:
Cache Poisoning to DoSΩστόσο, σημειώστε ότι μερικές φορές αυτοί οι τύποι κωδικών κατάστασης δεν αποθηκεύονται στη μνήμη cache, οπότε αυτή η δοκιμή μπορεί να μην είναι αξιόπιστη.
Ανακάλυψη: Ταυτοποίηση και αξιολόγηση μη κλειδωμένων εισόδων
Μπορείτε να χρησιμοποιήσετε Param Miner για να επιτεθείτε σε παραμέτρους και κεφαλίδες που μπορεί να αλλάζουν την απάντηση της σελίδας. Για παράδειγμα, μια σελίδα μπορεί να χρησιμοποιεί την κεφαλίδα X-Forwarded-For
για να υποδείξει στον πελάτη να φορτώσει το σενάριο από εκεί:
Εξαγωγή επιβλαβούς απάντησης από τον διακομιστή back-end
Με την παράμετρο/κεφαλίδα που έχει εντοπιστεί, ελέγξτε πώς καθαρίζεται και πού αντικατοπτρίζεται ή επηρεάζει την απάντηση από την κεφαλίδα. Μπορείτε να το εκμεταλλευτείτε με κάποιον τρόπο (να εκτελέσετε XSS ή να φορτώσετε έναν κωδικό JS που ελέγχετε; να εκτελέσετε DoS;...)
Λάβετε την απάντηση που έχει αποθηκευτεί στην cache
Αφού έχετε εντοπίσει τη σελίδα που μπορεί να εκμεταλλευτεί, ποια παράμετρος/κεφαλίδα να χρησιμοποιήσετε και πώς να την εκμεταλλευτείτε, πρέπει να λάβετε τη σελίδα αποθηκευμένη στην cache. Ανάλογα με τον πόρο που προσπαθείτε να αποθηκεύσετε στην cache, αυτό μπορεί να πάρει κάποιο χρόνο, ίσως χρειαστεί να προσπαθήσετε για αρκετά δευτερόλεπτα.
Η κεφαλίδα X-Cache
στην απάντηση μπορεί να είναι πολύ χρήσιμη καθώς μπορεί να έχει την τιμή miss
όταν το αίτημα δεν αποθηκεύτηκε στην cache και την τιμή hit
όταν είναι αποθηκευμένο.
Η κεφαλίδα Cache-Control
είναι επίσης ενδιαφέρον να γνωρίζετε αν ένας πόρος αποθηκεύεται στην cache και πότε θα είναι η επόμενη φορά που ο πόρος θα αποθηκευτεί ξανά: Cache-Control: public, max-age=1800
Μια άλλη ενδιαφέρουσα κεφαλίδα είναι η Vary
. Αυτή η κεφαλίδα χρησιμοποιείται συχνά για να υποδείξει πρόσθετες κεφαλίδες που θεωρούνται μέρος του κλειδιού της cache ακόμη και αν κανονικά δεν είναι κλειδωμένες. Επομένως, αν ο χρήστης γνωρίζει το User-Agent
του θύματος που στοχεύει, μπορεί να δηλητηριάσει την cache για τους χρήστες που χρησιμοποιούν αυτό το συγκεκριμένο User-Agent
.
Μια ακόμη κεφαλίδα σχετική με την cache είναι η Age
. Ορίζει τον χρόνο σε δευτερόλεπτα που το αντικείμενο έχει παραμείνει στην cache του proxy.
Όταν αποθηκεύετε ένα αίτημα στην cache, να είστε προσεκτικοί με τις κεφαλίδες που χρησιμοποιείτε γιατί μερικές από αυτές μπορεί να χρησιμοποιηθούν απροσδόκητα ως κλειδωμένες και το θύμα θα χρειαστεί να χρησιμοποιήσει αυτή την ίδια κεφαλίδα. Πάντα δοκιμάστε μια Δηλητηρίαση Cache με διαφορετικούς περιηγητές για να ελέγξετε αν λειτουργεί.
Παραδείγματα Εκμετάλλευσης
Ευκολότερο παράδειγμα
Μια κεφαλίδα όπως το X-Forwarded-For
αντικατοπτρίζεται στην απάντηση χωρίς καθαρισμό.
Μπορείτε να στείλετε ένα βασικό payload XSS και να δηλητηριάσετε την cache ώστε όλοι όσοι έχουν πρόσβαση στη σελίδα να υποστούν XSS:
Note that this will poison a request to /en?region=uk
not to /en
Cache poisoning to DoS
Cache Poisoning to DoSΧρησιμοποιώντας την δηλητηρίαση της μνήμης cache για να εκμεταλλευτείτε τις ευπάθειες διαχείρισης cookies
Τα cookies θα μπορούσαν επίσης να ανακλώνται στην απόκριση μιας σελίδας. Εάν μπορείτε να το εκμεταλλευτείτε για να προκαλέσετε XSS, για παράδειγμα, θα μπορούσατε να είστε σε θέση να εκμεταλλευτείτε το XSS σε αρκετούς πελάτες που φορτώνουν την κακόβουλη απόκριση της μνήμης cache.
Σημειώστε ότι αν το ευάλωτο cookie χρησιμοποιείται πολύ από τους χρήστες, οι κανονικές αιτήσεις θα καθαρίζουν την cache.
Δημιουργία διαφορών με διαχωριστικά, κανονικοποίηση και τελείες
Ελέγξτε:
Cache Poisoning via URL discrepanciesΔηλητηρίαση cache με διαδρομή traversal για κλοπή API key
Αυτή η αναφορά εξηγεί πώς ήταν δυνατό να κλαπεί ένα OpenAI API key με μια διεύθυνση URL όπως https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123
επειδή οτιδήποτε ταιριάζει με /share/*
θα αποθηκευτεί στην cache χωρίς να κανονικοποιηθεί η διεύθυνση URL από το Cloudflare, κάτι που έγινε όταν η αίτηση έφτασε στον web server.
Αυτό εξηγείται επίσης καλύτερα σε:
Cache Poisoning via URL discrepanciesΧρήση πολλαπλών κεφαλίδων για εκμετάλλευση ευπαθειών δηλητηρίασης web cache
Μερικές φορές θα χρειαστεί να εκμεταλλευτείτε αρκετές μη κλειδωμένες εισόδους για να μπορέσετε να κακοποιήσετε μια cache. Για παράδειγμα, μπορεί να βρείτε μια Ανοιχτή ανακατεύθυνση αν ορίσετε το X-Forwarded-Host
σε ένα domain που ελέγχετε και το X-Forwarded-Scheme
σε http
. Αν ο server προωθεί όλα τα HTTP αιτήματα σε HTTPS και χρησιμοποιεί την κεφαλίδα X-Forwarded-Scheme
ως το όνομα του domain για την ανακατεύθυνση. Μπορείτε να ελέγξετε πού δείχνει η σελίδα μέσω της ανακατεύθυνσης.
Εκμετάλλευση με περιορισμένο Vary
header
Vary
headerΑν διαπιστώσετε ότι ο X-Host
header χρησιμοποιείται ως όνομα τομέα για τη φόρτωση ενός JS πόρου αλλά ο Vary
header στην απάντηση υποδεικνύει User-Agent
. Τότε, πρέπει να βρείτε έναν τρόπο να εξάγετε το User-Agent του θύματος και να δηλητηριάσετε την cache χρησιμοποιώντας αυτόν τον user agent:
Fat Get
Στείλτε ένα GET αίτημα με το αίτημα στη διεύθυνση URL και στο σώμα. Αν ο web server χρησιμοποιεί αυτό από το σώμα αλλά ο cache server αποθηκεύει αυτό από τη διεύθυνση URL, οποιοσδήποτε έχει πρόσβαση σε αυτή τη διεύθυνση URL θα χρησιμοποιήσει στην πραγματικότητα την παράμετρο από το σώμα. Όπως η ευπάθεια που βρήκε ο James Kettle στον ιστότοπο του Github:
There it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get
Parameter Cloacking
Για παράδειγμα, είναι δυνατόν να διαχωρίσετε παραμέτρους σε διακομιστές ruby χρησιμοποιώντας τον χαρακτήρα ;
αντί για &
. Αυτό θα μπορούσε να χρησιμοποιηθεί για να τοποθετήσετε τις τιμές παραμέτρων χωρίς κλειδί μέσα σε κλειδωμένες και να τις εκμεταλλευτείτε.
Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking
Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
Μάθετε εδώ πώς να εκτελέσετε Cache Poisoning επιθέσεις εκμεταλλευόμενοι το HTTP Request Smuggling.
Automated testing for Web Cache Poisoning
Ο Web Cache Vulnerability Scanner μπορεί να χρησιμοποιηθεί για αυτόματη δοκιμή για web cache poisoning. Υποστηρίζει πολλές διαφορετικές τεχνικές και είναι πολύ παραμετροποιήσιμος.
Example usage: wcvs -u example.com
Vulnerable Examples
Apache Traffic Server (CVE-2021-27577)
Το ATS προώθησε το τμήμα μέσα στο URL χωρίς να το αφαιρέσει και δημιούργησε το κλειδί cache χρησιμοποιώντας μόνο τον host, το path και το query (αγνοώντας το τμήμα). Έτσι, το αίτημα /#/../?r=javascript:alert(1)
στάλθηκε στο backend ως /#/../?r=javascript:alert(1)
και το κλειδί cache δεν είχε το payload μέσα του, μόνο host, path και query.
GitHub CP-DoS
Η αποστολή μιας κακής τιμής στην κεφαλίδα content-type προκάλεσε μια 405 cached απάντηση. Το κλειδί cache περιείχε το cookie, επομένως ήταν δυνατόν να επιτεθεί μόνο σε μη αυθεντικοποιημένους χρήστες.
GitLab + GCP CP-DoS
Το GitLab χρησιμοποιεί GCP buckets για να αποθηκεύει στατικό περιεχόμενο. GCP Buckets υποστηρίζουν την κεφαλίδα x-http-method-override
. Έτσι, ήταν δυνατόν να σταλεί η κεφαλίδα x-http-method-override: HEAD
και να δηλητηριαστεί η cache ώστε να επιστρέφει ένα κενό σώμα απάντησης. Θα μπορούσε επίσης να υποστηρίξει τη μέθοδο PURGE
.
Rack Middleware (Ruby on Rails)
Σε εφαρμογές Ruby on Rails, συχνά χρησιμοποιείται το Rack middleware. Ο σκοπός του κώδικα Rack είναι να πάρει την τιμή της κεφαλίδας x-forwarded-scheme
και να την ορίσει ως το σχήμα του αιτήματος. Όταν σταλεί η κεφαλίδα x-forwarded-scheme: http
, συμβαίνει μια 301 ανακατεύθυνση στην ίδια τοποθεσία, προκαλώντας ενδεχομένως μια Άρνηση Υπηρεσίας (DoS) σε αυτόν τον πόρο. Επιπλέον, η εφαρμογή μπορεί να αναγνωρίσει την κεφαλίδα X-forwarded-host
και να ανακατευθύνει τους χρήστες στον καθορισμένο host. Αυτή η συμπεριφορά μπορεί να οδηγήσει στη φόρτωση αρχείων JavaScript από τον διακομιστή ενός επιτιθέμενου, θέτοντας σε κίνδυνο την ασφάλεια.
403 and Storage Buckets
Το Cloudflare προηγουμένως αποθήκευε 403 απαντήσεις. Η προσπάθεια πρόσβασης σε S3 ή Azure Storage Blobs με λανθασμένες κεφαλίδες Authorization θα είχε ως αποτέλεσμα μια 403 απάντηση που αποθηκεύτηκε. Αν και το Cloudflare έχει σταματήσει να αποθηκεύει 403 απαντήσεις, αυτή η συμπεριφορά μπορεί να είναι ακόμα παρούσα σε άλλες υπηρεσίες proxy.
Injecting Keyed Parameters
Οι caches συχνά περιλαμβάνουν συγκεκριμένες παραμέτρους GET στο κλειδί cache. Για παράδειγμα, το Varnish του Fastly αποθήκευε την παράμετρο size
σε αιτήματα. Ωστόσο, αν μια URL-encoded έκδοση της παραμέτρου (π.χ. siz%65
) αποσταλεί επίσης με λανθασμένη τιμή, το κλειδί cache θα κατασκευαστεί χρησιμοποιώντας την σωστή παράμετρο size
. Ωστόσο, το backend θα επεξεργαστεί την τιμή στην URL-encoded παράμετρο. Η URL-encoding της δεύτερης παραμέτρου size
οδήγησε στην παράλειψή της από την cache αλλά στη χρήση της από το backend. Η εκχώρηση μιας τιμής 0 σε αυτή την παράμετρο είχε ως αποτέλεσμα ένα cacheable 400 Bad Request σφάλμα.
User Agent Rules
Ορισμένοι προγραμματιστές αποκλείουν αιτήματα με user-agents που ταιριάζουν με αυτά εργαλείων υψηλής κυκλοφορίας όπως το FFUF ή το Nuclei για να διαχειριστούν το φορτίο του διακομιστή. Σαρκαστικά, αυτή η προσέγγιση μπορεί να εισάγει ευπάθειες όπως το cache poisoning και το DoS.
Illegal Header Fields
Το RFC7230 καθορίζει τους αποδεκτούς χαρακτήρες στα ονόματα κεφαλίδων. Οι κεφαλίδες που περιέχουν χαρακτήρες εκτός της καθορισμένης tchar περιοχής θα έπρεπε ιδανικά να προκαλούν μια 400 Bad Request απάντηση. Στην πράξη, οι διακομιστές δεν τηρούν πάντα αυτό το πρότυπο. Ένα αξιοσημείωτο παράδειγμα είναι το Akamai, το οποίο προωθεί κεφαλίδες με μη έγκυρους χαρακτήρες και αποθηκεύει οποιοδήποτε 400 σφάλμα, αρκεί να μην είναι παρούσα η κεφαλίδα cache-control
. Ένα εκμεταλλεύσιμο μοτίβο εντοπίστηκε όπου η αποστολή μιας κεφαλίδας με έναν παράνομο χαρακτήρα, όπως το \
, θα είχε ως αποτέλεσμα ένα cacheable 400 Bad Request σφάλμα.
Finding new headers
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
Cache Deception
Ο στόχος του Cache Deception είναι να κάνει τους πελάτες να φορτώνουν πόρους που πρόκειται να αποθηκευτούν από την cache με τις ευαίσθητες πληροφορίες τους.
Πρώτα απ' όλα σημειώστε ότι οι επέκταση όπως .css
, .js
, .png
κ.λπ. είναι συνήθως ρυθμισμένες να αποθηκεύονται στην cache. Επομένως, αν αποκτήσετε πρόσβαση στο www.example.com/profile.php/nonexistent.js
, η cache θα αποθηκεύσει πιθανώς την απάντηση επειδή βλέπει την επέκταση .js
. Αλλά, αν η εφαρμογή αναπαράγει με το ευαίσθητο περιεχόμενο χρήστη που αποθηκεύεται στο www.example.com/profile.php, μπορείτε να κλέψετε αυτά τα περιεχόμενα από άλλους χρήστες.
Άλλα πράγματα για δοκιμή:
www.example.com/profile.php/.js
www.example.com/profile.php/.css
www.example.com/profile.php/test.js
www.example.com/profile.php/../test.js
www.example.com/profile.php/%2e%2e/test.js
Χρησιμοποιήστε λιγότερο γνωστές επεκτάσεις όπως
.avif
Ένα άλλο πολύ σαφές παράδειγμα μπορεί να βρεθεί σε αυτή τη γραφή: https://hackerone.com/reports/593712. Στο παράδειγμα, εξηγείται ότι αν φορτώσετε μια ανύπαρκτη σελίδα όπως http://www.example.com/home.php/non-existent.css, το περιεχόμενο του http://www.example.com/home.php (με τις ευαίσθητες πληροφορίες του χρήστη) θα επιστραφεί και ο διακομιστής cache θα αποθηκεύσει το αποτέλεσμα. Στη συνέχεια, ο επιτιθέμενος μπορεί να αποκτήσει πρόσβαση στο http://www.example.com/home.php/non-existent.css στον δικό του περιηγητή και να παρατηρήσει τις εμπιστευτικές πληροφορίες των χρηστών που είχαν πρόσβαση πριν.
Σημειώστε ότι ο cache proxy θα πρέπει να είναι ρυθμισμένος να αποθηκεύει αρχεία βάσει της επέκτασης του αρχείου (.css) και όχι βάσει του content-type. Στο παράδειγμα http://www.example.com/home.php/non-existent.css θα έχει ένα text/html
content-type αντί για ένα text/css
mime type (το οποίο είναι το αναμενόμενο για ένα .css αρχείο).
Μάθετε εδώ πώς να εκτελέσετε Cache Deceptions επιθέσεις εκμεταλλευόμενοι το HTTP Request Smuggling.
Automatic Tools
toxicache: Σαρωτής Golang για να βρείτε ευπάθειες web cache poisoning σε μια λίστα URL και να δοκιμάσετε πολλές τεχνικές έγχυσης.
References
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F916570657-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fr3Cb8nKOYrlGZdSyjbAy%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=9fbb29e6&sv=1)
Χρησιμοποιήστε Trickest για να δημιουργήσετε και να ** αυτοματοποιήσετε ροές εργασίας** που υποστηρίζονται από τα πιο προηγμένα εργαλεία της κοινότητας. Αποκτήστε πρόσβαση σήμερα:
Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated