Cache Poisoning and Cache Deception
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
The difference
वेब कैश पॉइज़निंग और वेब कैश धोखाधड़ी के बीच क्या अंतर है?
वेब कैश पॉइज़निंग में, हमलावर एप्लिकेशन को कैश में कुछ दुर्भावनापूर्ण सामग्री संग्रहीत करने के लिए मजबूर करता है, और यह सामग्री अन्य एप्लिकेशन उपयोगकर्ताओं को कैश से परोसी जाती है।
वेब कैश धोखाधड़ी में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की कुछ संवेदनशील सामग्री कैश में संग्रहीत करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से पुनः प्राप्त करता है।
Cache Poisoning
कैश पॉइज़निंग का उद्देश्य क्लाइंट-साइड कैश को इस तरह से हेरफेर करना है कि क्लाइंट अप्रत्याशित, आंशिक, या हमलावर के नियंत्रण में संसाधनों को लोड करने के लिए मजबूर हो जाएं। प्रभाव की सीमा प्रभावित पृष्ठ की लोकप्रियता पर निर्भर करती है, क्योंकि दूषित प्रतिक्रिया केवल उन उपयोगकर्ताओं को परोसी जाती है जो कैश संदूषण के दौरान पृष्ठ पर जाते हैं।
कैश पॉइज़निंग हमले का कार्यान्वयन कई चरणों में होता है:
अनकीद इनपुट की पहचान: ये ऐसे पैरामीटर हैं जो, हालांकि कैश में अनुरोध के लिए आवश्यक नहीं हैं, सर्वर द्वारा लौटाई गई प्रतिक्रिया को बदल सकते हैं। इन इनपुट की पहचान करना महत्वपूर्ण है क्योंकि इन्हें कैश को हेरफेर करने के लिए शोषित किया जा सकता है।
अनकीद इनपुट का शोषण: अनकीद इनपुट की पहचान करने के बाद, अगला कदम यह पता लगाना है कि इन पैरामीटरों का दुरुपयोग कैसे किया जाए ताकि सर्वर की प्रतिक्रिया को इस तरह से संशोधित किया जा सके कि हमलावर को लाभ हो।
सुनिश्चित करना कि दूषित प्रतिक्रिया कैश में संग्रहीत है: अंतिम कदम यह सुनिश्चित करना है कि हेरफेर की गई प्रतिक्रिया कैश में संग्रहीत है। इस तरह, प्रभावित पृष्ठ को एक्सेस करने वाला कोई भी उपयोगकर्ता जब कैश दूषित हो, तो दूषित प्रतिक्रिया प्राप्त करेगा।
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 हेडर का उपयोग कर सकता है ताकि क्लाइंट को वहां से स्क्रिप्ट लोड करने के लिए संकेत दिया जा सके:
बैक-एंड सर्वर से हानिकारक प्रतिक्रिया प्राप्त करें
पैरामीटर/हेडर की पहचान करने के बाद, यह जांचें कि इसे सैनिटाइज कैसे किया जा रहा है और यह कहाँ प्रतिबिंबित हो रहा है या हेडर से प्रतिक्रिया को प्रभावित कर रहा है। क्या आप इसे किसी भी तरह से दुरुपयोग कर सकते हैं (एक 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 हो जाएगा:
ध्यान दें कि यह /en?region=uk के लिए एक अनुरोध को विषाक्त करेगा, /en के लिए नहीं
DoS के लिए कैश विषाक्तता
Cache Poisoning to DoSकुकी-हैंडलिंग कमजोरियों का लाभ उठाने के लिए वेब कैश विषाक्तता का उपयोग करना
कुकीज़ को एक पृष्ठ की प्रतिक्रिया पर भी परिलक्षित किया जा सकता है। यदि आप इसका दुरुपयोग करके उदाहरण के लिए XSS का कारण बन सकते हैं, तो आप उन कई क्लाइंट्स में XSS का लाभ उठाने में सक्षम हो सकते हैं जो दुर्भावनापूर्ण कैश प्रतिक्रिया को लोड करते हैं।
ध्यान दें कि यदि कमजोर कुकी का उपयोग उपयोगकर्ताओं द्वारा बहुत अधिक किया जाता है, तो नियमित अनुरोध कैश को साफ कर देंगे।
डेलिमिटर्स, सामान्यीकरण और डॉट्स के साथ विसंगतियों का निर्माण
जांचें:
Cache Poisoning via URL discrepanciesAPI कुंजी चुराने के लिए पथ ट्रैवर्सल के साथ कैश पॉइज़निंग
यह लेख समझाता है कि कैसे एक URL जैसे https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 के साथ OpenAI API कुंजी चुराना संभव था क्योंकि /share/* से मेल खाने वाली कोई भी चीज़ कैश की जाएगी बिना Cloudflare द्वारा URL को सामान्यीकृत किए, जो तब किया गया जब अनुरोध वेब सर्वर तक पहुंचा।
यह भी बेहतर तरीके से समझाया गया है:
Cache Poisoning via URL discrepanciesवेब कैश पॉइज़निंग कमजोरियों का शोषण करने के लिए कई हेडर का उपयोग करना
कभी-कभी आपको कैश का दुरुपयोग करने के लिए कई अनकीड इनपुट्स का शोषण करने की आवश्यकता होगी। उदाहरण के लिए, यदि आप X-Forwarded-Host को एक डोमेन पर सेट करते हैं जो आपके द्वारा नियंत्रित है और X-Forwarded-Scheme को http पर सेट करते हैं, तो आप एक Open redirect पा सकते हैं। यदि सर्वर सभी HTTP अनुरोधों को HTTPS पर फॉरवर्ड कर रहा है और X-Forwarded-Scheme हेडर का उपयोग रीडायरेक्ट के लिए डोमेन नाम के रूप में कर रहा है। आप नियंत्रित कर सकते हैं कि रीडायरेक्ट द्वारा पृष्ठ कहाँ इंगित किया गया है।
सीमित Vary हेडर के साथ शोषण
Vary हेडर के साथ शोषणयदि आप पाते हैं कि X-Host हेडर JS संसाधन लोड करने के लिए डोमेन नाम के रूप में उपयोग किया जा रहा है लेकिन प्रतिक्रिया में Vary हेडर User-Agent को इंगित कर रहा है। तो, आपको पीड़ित के User-Agent को निकालने और उस उपयोगकर्ता एजेंट का उपयोग करके कैश को विषाक्त करने का एक तरीका खोजना होगा:
Fat Get
URL में अनुरोध और शरीर में अनुरोध के साथ GET अनुरोध भेजें। यदि वेब सर्वर शरीर से एक का उपयोग करता है लेकिन कैश सर्वर URL से एक को कैश करता है, तो कोई भी उस URL तक पहुँचने पर वास्तव में शरीर से पैरामीटर का उपयोग करेगा। जैसे कि vuln जेम्स केटल ने 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
उदाहरण के लिए, यह 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-encoded संस्करण (जैसे, siz%65) भी एक गलत मान के साथ भेजा गया, तो कैश कुंजी सही size पैरामीटर का उपयोग करके बनाई जाएगी। फिर भी, बैकएंड URL-encoded पैरामीटर में मान को संसाधित करेगा। दूसरे size पैरामीटर को URL-encode करने से इसे कैश द्वारा छोड़ दिया गया लेकिन बैकएंड द्वारा उपयोग किया गया। इस पैरामीटर को 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 में संग्रहीत sensitive उपयोगकर्ता सामग्री के साथ 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 तक पहुँच सकता है और पहले पहुँचने वाले उपयोगकर्ताओं की confidential information देख सकता है।
ध्यान दें कि cache proxy को फ़ाइलों को extension के आधार पर cache करने के लिए कॉन्फ़िगर किया जाना चाहिए (.css) और सामग्री-प्रकार के आधार पर नहीं। उदाहरण में http://www.example.com/home.php/non-existent.css का text/html सामग्री-प्रकार होगा न कि .css फ़ाइल के लिए अपेक्षित text/css mime प्रकार।
यहां जानें कि कैसे Cache Deceptions हमलों को HTTP Request Smuggling का दुरुपयोग करके किया जाता है।
Automatic Tools
toxicache: URLs की एक सूची में वेब कैश पॉइज़निंग कमजोरियों को खोजने और कई इंजेक्शन तकनीकों का परीक्षण करने के लिए Golang स्कैनर।
References
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
