कैश पॉइज़निंग और कैश धोखाधड़ी

Reading time: 16 minutes

अंतर

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

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

कैश पॉइज़निंग

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

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

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

खोज: HTTP हेडर की जांच करें

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

खोज: कैशिंग त्रुटि कोड

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

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

Cache Poisoning to DoS

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

खोज: अनकीड इनपुट की पहचान और मूल्यांकन करें

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

<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 हो जाएगा:

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

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

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

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 हेडर का उपयोग रीडायरेक्ट के लिए डोमेन नाम के रूप में कर रहा है। आप रीडायरेक्ट द्वारा पृष्ठ को इंगित करने के स्थान को नियंत्रित कर सकते हैं।

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 को निकालने और उस उपयोगकर्ता एजेंट का उपयोग करके कैश को विषाक्त करने का एक तरीका खोजना होगा:

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

ध्यान दें कि कैश प्रॉक्सी को फ़ाइलों को कैश करने के लिए कॉन्फ़िगर किया जाना चाहिए फाइल के एक्सटेंशन (.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

• https://portswigger.net/web-security/web-cache-poisoning
• https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities
• https://hackerone.com/reports/593712
• https://youst.in/posts/cache-poisoning-at-scale/
• https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9
• https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/