Cache Poisoning and Cache Deception

Reading time: 17 minutes

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

The difference

वेब कैश पॉइज़निंग और वेब कैश धोखाधड़ी के बीच क्या अंतर है?

  • वेब कैश पॉइज़निंग में, हमलावर एप्लिकेशन को कैश में कुछ दुर्भावनापूर्ण सामग्री स्टोर करने के लिए मजबूर करता है, और यह सामग्री कैश से अन्य एप्लिकेशन उपयोगकर्ताओं को परोसी जाती है।
  • वेब कैश धोखाधड़ी में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की कुछ संवेदनशील सामग्री कैश में स्टोर करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से पुनः प्राप्त करता है।

Cache Poisoning

कैश पॉइज़निंग का उद्देश्य क्लाइंट-साइड कैश को इस तरह से हेरफेर करना है कि क्लाइंट अप्रत्याशित, आंशिक, या हमलावर के नियंत्रण में संसाधनों को लोड करने के लिए मजबूर हो जाएं। प्रभाव की सीमा प्रभावित पृष्ठ की लोकप्रियता पर निर्भर करती है, क्योंकि दूषित प्रतिक्रिया केवल उन उपयोगकर्ताओं को परोसी जाती है जो कैश संदूषण के दौरान पृष्ठ पर जाते हैं।

कैश पॉइज़निंग हमले का कार्यान्वयन कई चरणों में होता है:

  1. अनकीड इनपुट की पहचान: ये ऐसे पैरामीटर हैं, जो कैश में अनुरोध के लिए आवश्यक नहीं होते, लेकिन सर्वर द्वारा लौटाई गई प्रतिक्रिया को बदल सकते हैं। इन इनपुट की पहचान करना महत्वपूर्ण है क्योंकि इन्हें कैश को हेरफेर करने के लिए उपयोग किया जा सकता है।
  2. अनकीड इनपुट का शोषण: अनकीड इनपुट की पहचान करने के बाद, अगला चरण यह पता लगाना है कि इन पैरामीटर का दुरुपयोग कैसे किया जाए ताकि सर्वर की प्रतिक्रिया को इस तरह से संशोधित किया जा सके कि हमलावर को लाभ हो।
  3. सुनिश्चित करना कि दूषित प्रतिक्रिया कैश में है: अंतिम चरण यह सुनिश्चित करना है कि हेरफेर की गई प्रतिक्रिया कैश में स्टोर हो। इस तरह, कैश संदूषण के दौरान प्रभावित पृष्ठ को एक्सेस करने वाला कोई भी उपयोगकर्ता दूषित प्रतिक्रिया प्राप्त करेगा।

Discovery: Check HTTP headers

आमतौर पर, जब एक प्रतिक्रिया कैश में स्टोर की गई होती है, तो एक हेडर ऐसा संकेत देता है, आप इस पोस्ट में देख सकते हैं कि आपको किन हेडर पर ध्यान देना चाहिए: HTTP Cache headers.

Discovery: Caching error codes

यदि आप सोच रहे हैं कि प्रतिक्रिया कैश में स्टोर की जा रही है, तो आप खराब हेडर के साथ अनुरोध भेजने की कोशिश कर सकते हैं, जिसे स्थिति कोड 400 के साथ प्रतिक्रिया दी जानी चाहिए। फिर सामान्य रूप से अनुरोध तक पहुँचने की कोशिश करें और यदि प्रतिक्रिया 400 स्थिति कोड है, तो आप जानते हैं कि यह संवेदनशील है (और आप यहां तक कि DoS भी कर सकते हैं)।

आप अधिक विकल्प पा सकते हैं:

Cache Poisoning to DoS

हालांकि, ध्यान दें कि कभी-कभी इस प्रकार के स्थिति कोड कैश नहीं होते इसलिए यह परीक्षण विश्वसनीय नहीं हो सकता।

Discovery: Identify and evaluate unkeyed inputs

आप Param Miner का उपयोग कर सकते हैं पैरामीटर और हेडर को ब्रूट-फोर्स करने के लिए जो पृष्ठ की प्रतिक्रिया को बदल सकते हैं। उदाहरण के लिए, एक पृष्ठ X-Forwarded-For हेडर का उपयोग कर सकता है यह संकेत देने के लिए कि क्लाइंट को वहां से स्क्रिप्ट लोड करना है:

html
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

बैक-एंड सर्वर से हानिकारक प्रतिक्रिया प्राप्त करना

पैरामीटर/हेडर की पहचान करने के बाद, यह जांचें कि इसे सैनिटाइज कैसे किया जा रहा है और यह कहाँ प्रतिबिंबित हो रहा है या हेडर से प्रतिक्रिया को प्रभावित कर रहा है। क्या आप इसे किसी भी तरह से दुरुपयोग कर सकते हैं (एक XSS प्रदर्शन करें या अपने द्वारा नियंत्रित JS कोड लोड करें? एक DoS प्रदर्शन करें?...)

प्रतिक्रिया को कैश करें

एक बार जब आप उस पृष्ठ की पहचान कर लेते हैं जिसे दुरुपयोग किया जा सकता है, किस पैरामीटर/हेडर का उपयोग करना है और कैसे इसका दुरुपयोग करना है, तो आपको पृष्ठ को कैश करना होगा। जिस संसाधन को आप कैश में प्राप्त करने की कोशिश कर रहे हैं, उसके आधार पर इसमें कुछ समय लग सकता है, आपको कई सेकंड तक प्रयास करना पड़ सकता है।

प्रतिक्रिया में X-Cache हेडर बहुत उपयोगी हो सकता है क्योंकि इसमें miss का मान हो सकता है जब अनुरोध कैश नहीं किया गया था और hit का मान जब इसे कैश किया गया है।
हेडर Cache-Control भी जानने के लिए दिलचस्प है कि क्या कोई संसाधन कैश किया जा रहा है और अगली बार कब संसाधन फिर से कैश किया जाएगा: Cache-Control: public, max-age=1800

एक और दिलचस्प हेडर Vary है। यह हेडर अक्सर अतिरिक्त हेडर्स को संकेतित करने के लिए उपयोग किया जाता है जो कैश कुंजी के भाग के रूप में माना जाता है, भले ही वे सामान्यतः अनकुंजीकृत हों। इसलिए, यदि उपयोगकर्ता लक्षित पीड़ित का User-Agent जानता है, तो वह उस विशेष User-Agent का उपयोग करने वाले उपयोगकर्ताओं के लिए कैश को विषाक्त कर सकता है।

कैश से संबंधित एक और हेडर Age है। यह परिभाषित करता है कि वस्तु प्रॉक्सी कैश में कितने सेकंड से है।

अनुरोध को कैश करते समय, आप जिन हेडर्स का उपयोग करते हैं, उनके साथ सावधान रहें क्योंकि उनमें से कुछ अनपेक्षित रूप से कीड के रूप में उपयोग किए जा सकते हैं और पीड़ित को उसी हेडर का उपयोग करना होगा। हमेशा विभिन्न ब्राउज़रों के साथ कैश पॉइज़निंग का परीक्षण करें यह जांचने के लिए कि यह काम कर रहा है या नहीं।

शोषण के उदाहरण

सबसे आसान उदाहरण

एक हेडर जैसे X-Forwarded-For को प्रतिक्रिया में असैनिटाइज्ड रूप से प्रतिबिंबित किया जा रहा है।
आप एक बुनियादी XSS पेलोड भेज सकते हैं और कैश को विषाक्त कर सकते हैं ताकि जो कोई भी पृष्ठ तक पहुँचता है वह XSS हो जाएगा:

html
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

ध्यान दें कि यह /en?region=uk के लिए एक अनुरोध को विषाक्त करेगा, /en के लिए नहीं

DoS के लिए कैश विषाक्तता

Cache Poisoning to DoS

CDNs के माध्यम से कैश विषाक्तता

इस लेख में निम्नलिखित सरल परिदृश्य समझाया गया है:

  • CDN /share/ के तहत किसी भी चीज़ को कैश करेगा
  • CDN %2F..%2F को डिकोड या सामान्यीकृत नहीं करेगा, इसलिए, इसका उपयोग अन्य संवेदनशील स्थानों तक पहुँचने के लिए पथ यात्रा के रूप में किया जा सकता है जो कैश किए जाएंगे जैसे https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123
  • वेब सर्वर %2F..%2F को डिकोड और सामान्यीकृत करेगा, और /api/auth/session के साथ प्रतिक्रिया देगा, जिसमें प्रमाणन टोकन शामिल है।

कुकी-हैंडलिंग कमजोरियों का शोषण करने के लिए वेब कैश विषाक्तता का उपयोग करना

कुकीज़ को एक पृष्ठ की प्रतिक्रिया पर भी परिलक्षित किया जा सकता है। यदि आप इसका दुरुपयोग करके उदाहरण के लिए XSS का कारण बन सकते हैं, तो आप उन कई क्लाइंट्स में XSS का शोषण करने में सक्षम हो सकते हैं जो दुर्भावनापूर्ण कैश प्रतिक्रिया को लोड करते हैं।

html
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

ध्यान दें कि यदि कमजोर कुकी का उपयोग उपयोगकर्ताओं द्वारा बहुत अधिक किया जाता है, तो नियमित अनुरोध कैश को साफ कर देंगे।

सीमाओं, सामान्यीकरण और बिंदुओं के साथ विसंगतियों का निर्माण

जांचें:

Cache Poisoning via URL discrepancies

API कुंजी चुराने के लिए पथ यात्रा के साथ कैश विषाक्तता

यह लेख समझाता है कि कैसे एक URL जैसे https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 के साथ OpenAI API कुंजी चुराना संभव था क्योंकि /share/* से मेल खाने वाली कोई भी चीज़ कैश की जाएगी बिना Cloudflare द्वारा URL को सामान्यीकृत किए, जो तब किया गया जब अनुरोध वेब सर्वर तक पहुंचा।

यह भी बेहतर तरीके से समझाया गया है:

Cache Poisoning via URL discrepancies

वेब कैश विषाक्तता कमजोरियों का लाभ उठाने के लिए कई हेडर का उपयोग करना

कभी-कभी आपको कैश का दुरुपयोग करने के लिए कई अनकीद इनपुट्स का लाभ उठाने की आवश्यकता होगी। उदाहरण के लिए, आप एक Open redirect पा सकते हैं यदि आप X-Forwarded-Host को एक डोमेन पर सेट करते हैं जो आपके द्वारा नियंत्रित है और X-Forwarded-Scheme को http पर सेट करते हैं। यदि सर्वर सभी HTTP अनुरोधों को HTTPS पर आगे बढ़ा रहा है और X-Forwarded-Scheme हेडर का उपयोग रीडायरेक्ट के लिए डोमेन नाम के रूप में कर रहा है। आप नियंत्रित कर सकते हैं कि रीडायरेक्ट द्वारा पृष्ठ कहाँ इंगित किया गया है।

html
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

सीमित Vary हेडर के साथ शोषण

यदि आप पाते हैं कि X-Host हेडर JS संसाधन लोड करने के लिए डोमेन नाम के रूप में उपयोग किया जा रहा है लेकिन प्रतिक्रिया में Vary हेडर User-Agent को इंगित कर रहा है। तो, आपको पीड़ित के User-Agent को बाहर निकालने और उस उपयोगकर्ता एजेंट का उपयोग करके कैश को ज़हर देने का एक तरीका खोजना होगा:

html
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

URL में अनुरोध और शरीर में अनुरोध के साथ GET अनुरोध भेजें। यदि वेब सर्वर शरीर से एक का उपयोग करता है लेकिन कैश सर्वर URL से एक को कैश करता है, तो कोई भी उस URL को एक्सेस करने पर वास्तव में शरीर से पैरामीटर का उपयोग करेगा। जैसे कि vuln James Kettle ने Github वेबसाइट पर पाया:

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

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

उदाहरण के लिए, parameters को 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 का उपयोग वेब कैश पॉइज़निंग के लिए स्वचालित रूप से परीक्षण करने के लिए किया जा सकता है। यह कई विभिन्न तकनीकों का समर्थन करता है और अत्यधिक अनुकूलन योग्य है।

Example usage: wcvs -u example.com

Vulnerable Examples

Apache Traffic Server (CVE-2021-27577)

ATS ने URL के अंदर के अंश को बिना हटाए आगे बढ़ाया और केवल होस्ट, पथ और क्वेरी का उपयोग करके कैश कुंजी उत्पन्न की (अंश की अनदेखी करते हुए)। इसलिए अनुरोध /#/../?r=javascript:alert(1) को बैकएंड पर /#/../?r=javascript:alert(1) के रूप में भेजा गया और कैश कुंजी में इसका पेलोड नहीं था, केवल होस्ट, पथ और क्वेरी।

GitHub CP-DoS

सामग्री-प्रकार हेडर में एक खराब मान भेजने से 405 कैश्ड प्रतिक्रिया उत्पन्न हुई। कैश कुंजी में कुकी शामिल थी, इसलिए केवल अनधिकृत उपयोगकर्ताओं पर हमला करना संभव था।

GitLab + GCP CP-DoS

GitLab स्थिर सामग्री को स्टोर करने के लिए GCP बकेट का उपयोग करता है। GCP Buckets हेडर x-http-method-override का समर्थन करते हैं। इसलिए, हेडर x-http-method-override: HEAD भेजना संभव था और कैश को खाली प्रतिक्रिया शरीर लौटाने के लिए विषाक्त करना संभव था। यह PURGE विधि का भी समर्थन कर सकता था।

Rack Middleware (Ruby on Rails)

Ruby on Rails अनुप्रयोगों में, Rack मिडलवेयर का अक्सर उपयोग किया जाता है। Rack कोड का उद्देश्य x-forwarded-scheme हेडर के मान को लेना और इसे अनुरोध की योजना के रूप में सेट करना है। जब हेडर x-forwarded-scheme: http भेजा जाता है, तो उसी स्थान पर 301 रीडायरेक्ट होता है, जो उस संसाधन के लिए सेवा से इनकार (DoS) का कारण बन सकता है। इसके अतिरिक्त, अनुप्रयोग X-forwarded-host हेडर को मान्यता दे सकता है और उपयोगकर्ताओं को निर्दिष्ट होस्ट पर रीडायरेक्ट कर सकता है। यह व्यवहार हमलावर के सर्वर से JavaScript फ़ाइलों को लोड करने का कारण बन सकता है, जो सुरक्षा जोखिम पैदा करता है।

403 and Storage Buckets

Cloudflare ने पहले 403 प्रतिक्रियाओं को कैश किया था। गलत प्राधिकरण हेडर के साथ S3 या Azure Storage Blobs तक पहुंचने का प्रयास करने पर 403 प्रतिक्रिया उत्पन्न होती थी जो कैश हो जाती थी। हालांकि, Cloudflare ने 403 प्रतिक्रियाओं को कैश करना बंद कर दिया है, यह व्यवहार अन्य प्रॉक्सी सेवाओं में अभी भी मौजूद हो सकता है।

Injecting Keyed Parameters

कैश अक्सर कैश कुंजी में विशिष्ट GET पैरामीटर शामिल करते हैं। उदाहरण के लिए, Fastly का Varnish अनुरोधों में size पैरामीटर को कैश करता है। हालाँकि, यदि पैरामीटर का URL-कोडित संस्करण (जैसे, siz%65) भी एक गलत मान के साथ भेजा गया, तो कैश कुंजी सही size पैरामीटर का उपयोग करके बनाई जाएगी। फिर भी, बैकएंड URL-कोडित पैरामीटर में मान को संसाधित करेगा। दूसरे size पैरामीटर को URL-कोडिंग करने से इसे कैश द्वारा छोड़ दिया गया लेकिन बैकएंड द्वारा उपयोग किया गया। इस पैरामीटर को 0 का मान असाइन करने से कैशेबल 400 Bad Request त्रुटि उत्पन्न हुई।

User Agent Rules

कुछ डेवलपर्स उच्च-ट्रैफ़िक उपकरणों जैसे FFUF या Nuclei के अनुरोधों को ब्लॉक करते हैं ताकि सर्वर लोड को प्रबंधित किया जा सके। विडंबना यह है कि यह दृष्टिकोण कैश पॉइज़निंग और DoS जैसी कमजोरियों को पेश कर सकता है।

Illegal Header Fields

RFC7230 हेडर नामों में स्वीकार्य वर्णों को निर्दिष्ट करता है। हेडर में निर्दिष्ट tchar रेंज के बाहर के वर्णों को शामिल करने वाले हेडर को आदर्श रूप से 400 Bad Request प्रतिक्रिया उत्पन्न करनी चाहिए। व्यवहार में, सर्वर हमेशा इस मानक का पालन नहीं करते हैं। एक उल्लेखनीय उदाहरण Akamai है, जो अवैध वर्णों वाले हेडर को आगे बढ़ाता है और किसी भी 400 त्रुटि को कैश करता है, जब तक कि cache-control हेडर मौजूद नहीं है। एक exploitable पैटर्न की पहचान की गई थी जहां अवैध वर्ण जैसे \ वाला हेडर भेजने से कैशेबल 400 Bad Request त्रुटि उत्पन्न होती है।

Finding new headers

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

Cache Deception

Cache Deception का लक्ष्य है कि ग्राहक उन संसाधनों को लोड करें जो कैश द्वारा उनके संवेदनशील जानकारी के साथ सहेजे जाने वाले हैं।

सबसे पहले, ध्यान दें कि extensions जैसे .css, .js, .png आदि आमतौर पर सहेजे जाने के लिए कॉन्फ़िगर किए जाते हैं। इसलिए, यदि आप www.example.com/profile.php/nonexistent.js तक पहुंचते हैं, तो कैश शायद प्रतिक्रिया को सहेज लेगा क्योंकि यह .js extension को देखता है। लेकिन, यदि application सुरक्षित उपयोगकर्ता सामग्री के साथ www.example.com/profile.php के साथ replaying कर रहा है, तो आप अन्य उपयोगकर्ताओं से उन सामग्री को चुरा सकते हैं।

परीक्षण करने के लिए अन्य चीजें:

  • 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 (उपयोगकर्ता की संवेदनशील जानकारी के साथ) की सामग्री लौटाई जाएगी और कैश सर्वर परिणाम को सहेज लेगा।
फिर, attacker अपने ब्राउज़र में http://www.example.com/home.php/non-existent.css तक पहुंच सकता है और पहले पहुंचने वाले उपयोगकर्ताओं की गोपनीय जानकारी देख सकता है।

ध्यान दें कि cache proxy को फ़ाइलों को extension के आधार पर cache करने के लिए कॉन्फ़िगर किया जाना चाहिए (.css) और सामग्री-प्रकार के आधार पर नहीं। उदाहरण में http://www.example.com/home.php/non-existent.css का text/html सामग्री-प्रकार होगा न कि .css फ़ाइल के लिए अपेक्षित text/css माइम प्रकार।

यहां जानें कि कैसे Cache Deceptions हमलों को HTTP Request Smuggling का दुरुपयोग करके किया जाता है।

Automatic Tools

  • toxicache: Golang स्कैनर जो URLs की एक सूची में वेब कैश पॉइज़निंग कमजोरियों को खोजने और कई इंजेक्शन तकनीकों का परीक्षण करने के लिए है।

References

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें