Cache Poisoning and Cache Deception
Last updated
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:
वेब कैश पॉइज़निंग और वेब कैश धोखाधड़ी के बीच क्या अंतर है?
वेब कैश पॉइज़निंग में, हमलावर एप्लिकेशन को कैश में कुछ दुर्भावनापूर्ण सामग्री संग्रहीत करने के लिए मजबूर करता है, और यह सामग्री अन्य एप्लिकेशन उपयोगकर्ताओं को कैश से प्रदान की जाती है।
वेब कैश धोखाधड़ी में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की कुछ संवेदनशील सामग्री कैश में संग्रहीत करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से पुनः प्राप्त करता है।
कैश पॉइज़निंग का उद्देश्य क्लाइंट-साइड कैश को इस तरह से हेरफेर करना है कि क्लाइंट अप्रत्याशित, आंशिक, या हमलावर के नियंत्रण में संसाधनों को लोड करने के लिए मजबूर हों। प्रभाव की सीमा प्रभावित पृष्ठ की लोकप्रियता पर निर्भर करती है, क्योंकि दूषित प्रतिक्रिया केवल उन उपयोगकर्ताओं को प्रदान की जाती है जो कैश संदूषण के दौरान पृष्ठ पर जाते हैं।
कैश पॉइज़निंग हमले का कार्यान्वयन कई चरणों में होता है:
अनकीड इनपुट की पहचान: ये ऐसे पैरामीटर हैं जो, हालांकि कैश में अनुरोध के लिए आवश्यक नहीं हैं, सर्वर द्वारा लौटाई गई प्रतिक्रिया को बदल सकते हैं। इन इनपुट की पहचान करना महत्वपूर्ण है क्योंकि इन्हें कैश को हेरफेर करने के लिए उपयोग किया जा सकता है।
अनकीड इनपुट का शोषण: अनकीड इनपुट की पहचान करने के बाद, अगला कदम यह पता लगाना है कि इन पैरामीटरों का दुरुपयोग कैसे किया जाए ताकि सर्वर की प्रतिक्रिया को इस तरह से संशोधित किया जा सके कि हमलावर को लाभ हो।
सुनिश्चित करना कि दूषित प्रतिक्रिया कैश में संग्रहीत है: अंतिम कदम यह सुनिश्चित करना है कि हेरफेर की गई प्रतिक्रिया कैश में संग्रहीत है। इस तरह, कैश संदूषित होने के दौरान प्रभावित पृष्ठ तक पहुंचने वाला कोई भी उपयोगकर्ता दूषित प्रतिक्रिया प्राप्त करेगा।
आमतौर पर, जब एक प्रतिक्रिया कैश में संग्रहीत की गई होती है, तो एक हेडर इस बात का संकेत देता है, आप इस पोस्ट में देख सकते हैं कि आपको किन हेडर पर ध्यान देना चाहिए: HTTP Cache headers.
यदि आप सोच रहे हैं कि प्रतिक्रिया कैश में संग्रहीत की जा रही है, तो आप खराब हेडर के साथ अनुरोध भेजने की कोशिश कर सकते हैं, जिसे स्थिति कोड 400 के साथ प्रतिक्रिया दी जानी चाहिए। फिर सामान्य रूप से अनुरोध तक पहुंचने की कोशिश करें और यदि प्रतिक्रिया 400 स्थिति कोड है, तो आप जानते हैं कि यह कमजोर है (और आप यहां तक कि DoS भी कर सकते हैं)।
आप अधिक विकल्प पा सकते हैं:
Cache Poisoning to DoSहालांकि, ध्यान दें कि कभी-कभी इस प्रकार के स्थिति कोड कैश नहीं होते इसलिए यह परीक्षण विश्वसनीय नहीं हो सकता।
आप 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 के लिए नहीं
कुकीज़ को एक पृष्ठ के उत्तर पर भी परिलक्षित किया जा सकता है। यदि आप इसका दुरुपयोग करके उदाहरण के लिए XSS उत्पन्न कर सकते हैं, तो आप उन कई क्लाइंट्स में XSS का लाभ उठाने में सक्षम हो सकते हैं जो दुर्भावनापूर्ण कैश उत्तर को लोड करते हैं।
ध्यान दें कि यदि कमजोर कुकी का उपयोग उपयोगकर्ताओं द्वारा बहुत अधिक किया जाता है, तो नियमित अनुरोध कैश को साफ कर देंगे।
जांचें:
Cache Poisoning via URL discrepanciesयह लेख समझाता है कि कैसे एक 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 हेडर के साथ शोषणयदि आप पाते हैं कि X-Host हेडर JS संसाधन को लोड करने के लिए डोमेन नाम के रूप में उपयोग किया जा रहा है लेकिन प्रतिक्रिया में Vary हेडर User-Agent को इंगित कर रहा है। तब, आपको पीड़ित के User-Agent को निकालने और उस उपयोगकर्ता एजेंट का उपयोग करके कैश को विषाक्त करने का एक तरीका खोजना होगा:
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
उदाहरण के लिए, यह ; अक्षर का उपयोग करके parameters को ruby सर्वरों में अलग करना संभव है, इसके बजाय &। इसका उपयोग बिना कुंजी वाले पैरामीटर मानों को कुंजी वाले में डालने और उनका दुरुपयोग करने के लिए किया जा सकता है।
Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking
यहां जानें कि कैसे Cache Poisoning हमलों को HTTP Request Smuggling का दुरुपयोग करके किया जाता है।
Web Cache Vulnerability Scanner का उपयोग वेब कैश पॉइज़निंग के लिए स्वचालित रूप से परीक्षण करने के लिए किया जा सकता है। यह कई विभिन्न तकनीकों का समर्थन करता है और अत्यधिक अनुकूलन योग्य है।
Example usage: wcvs -u example.com
ATS ने URL के अंदर के अंश को बिना हटाए अग्रेषित किया और केवल होस्ट, पथ और क्वेरी का उपयोग करके कैश कुंजी उत्पन्न की (अंश की अनदेखी करते हुए)। इसलिए अनुरोध /#/../?r=javascript:alert(1) को बैकएंड पर /#/../?r=javascript:alert(1) के रूप में भेजा गया और कैश कुंजी में इसका पेलोड नहीं था, केवल होस्ट, पथ और क्वेरी।
सामग्री-प्रकार हेडर में एक खराब मान भेजने से 405 कैश्ड प्रतिक्रिया उत्पन्न हुई। कैश कुंजी में कुकी शामिल थी, इसलिए केवल अनधिकृत उपयोगकर्ताओं पर हमला करना संभव था।
GitLab स्थिर सामग्री को स्टोर करने के लिए GCP बकेट का उपयोग करता है। GCP Buckets हेडर x-http-method-override का समर्थन करते हैं। इसलिए यह संभव था कि हेडर x-http-method-override: HEAD भेजा जाए और कैश को खाली प्रतिक्रिया शरीर लौटाने के लिए विषाक्त किया जाए। यह PURGE विधि का भी समर्थन कर सकता है।
Ruby on Rails अनुप्रयोगों में, Rack मिडलवेयर का अक्सर उपयोग किया जाता है। Rack कोड का उद्देश्य x-forwarded-scheme हेडर के मान को लेना और इसे अनुरोध की योजना के रूप में सेट करना है। जब हेडर x-forwarded-scheme: http भेजा जाता है, तो उसी स्थान पर 301 रीडायरेक्ट होता है, जो उस संसाधन के लिए सेवा से इनकार (DoS) का कारण बन सकता है। इसके अतिरिक्त, अनुप्रयोग X-forwarded-host हेडर को मान्यता दे सकता है और उपयोगकर्ताओं को निर्दिष्ट होस्ट पर रीडायरेक्ट कर सकता है। यह व्यवहार हमलावर के सर्वर से JavaScript फ़ाइलों को लोड करने का कारण बन सकता है, जो सुरक्षा जोखिम पैदा करता है।
Cloudflare ने पहले 403 प्रतिक्रियाओं को कैश किया था। गलत प्राधिकरण हेडर के साथ S3 या Azure Storage Blobs तक पहुँचने का प्रयास करने पर 403 प्रतिक्रिया उत्पन्न होती थी जो कैश हो जाती थी। हालांकि Cloudflare ने 403 प्रतिक्रियाओं को कैश करना बंद कर दिया है, यह व्यवहार अन्य प्रॉक्सी सेवाओं में अभी भी मौजूद हो सकता है।
कैश अक्सर कैश कुंजी में विशिष्ट GET पैरामीटर शामिल करते हैं। उदाहरण के लिए, Fastly का Varnish अनुरोधों में size पैरामीटर को कैश करता है। हालाँकि, यदि पैरामीटर का URL-कोडित संस्करण (जैसे, siz%65) भी एक गलत मान के साथ भेजा गया, तो कैश कुंजी सही size पैरामीटर का उपयोग करके बनाई जाएगी। फिर भी, बैकएंड URL-कोडित पैरामीटर में मान को संसाधित करेगा। दूसरे size पैरामीटर को URL-कोडिंग करने से इसे कैश द्वारा छोड़ दिया गया लेकिन बैकएंड द्वारा उपयोग किया गया। इस पैरामीटर को 0 का मान असाइन करने से कैशेबल 400 Bad Request त्रुटि उत्पन्न हुई।
कुछ डेवलपर्स उच्च-ट्रैफ़िक उपकरणों जैसे FFUF या Nuclei के अनुरोधों को ब्लॉक करते हैं ताकि सर्वर लोड को प्रबंधित किया जा सके। विडंबना यह है कि यह दृष्टिकोण कैश पॉइज़निंग और DoS जैसी कमजोरियों को पेश कर सकता है।
RFC7230 हेडर नामों में स्वीकार्य वर्णों को निर्दिष्ट करता है। हेडरों में निर्दिष्ट tchar रेंज के बाहर के वर्ण होने पर आदर्श रूप से 400 Bad Request प्रतिक्रिया उत्पन्न होनी चाहिए। व्यवहार में, सर्वर हमेशा इस मानक का पालन नहीं करते हैं। एक उल्लेखनीय उदाहरण Akamai है, जो अवैध वर्णों के साथ हेडरों को अग्रेषित करता है और किसी भी 400 त्रुटि को कैश करता है, जब तक कि cache-control हेडर मौजूद नहीं है। एक exploitable पैटर्न पहचाना गया था जहां अवैध वर्ण जैसे \ के साथ हेडर भेजने पर कैशेबल 400 Bad Request त्रुटि उत्पन्न होती है।
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
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 सामग्री-प्रकार होगा, न कि text/css माइम प्रकार (जो .css फ़ाइल के लिए अपेक्षित है)।
यहां जानें कि कैसे Cache Deceptions हमलों को HTTP Request Smuggling का दुरुपयोग करके किया जाता है।
toxicache: Golang स्कैनर जो URLs की एक सूची में वेब कैश पॉइज़निंग कमजोरियों को खोजने और कई इंजेक्शन तकनीकों का परीक्षण करने के लिए है।
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
