CORS - Misconfigurations & Bypass
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)
Cross-Origin Resource Sharing (CORS) मानक सर्वरों को यह परिभाषित करने की अनुमति देता है कि कौन उनके संसाधनों तक पहुँच सकता है और कौन से HTTP अनुरोध विधियाँ बाहरी स्रोतों से अनुमत हैं।
एक same-origin नीति यह अनिवार्य करती है कि एक सर्वर जो एक संसाधन का अनुरोध कर रहा है और जो सर्वर संसाधन होस्ट कर रहा है, वही प्रोटोकॉल (जैसे, http://), डोमेन नाम (जैसे, internal-web.com), और पोर्ट (जैसे, 80) साझा करें। इस नीति के तहत, केवल समान डोमेन और पोर्ट से वेब पृष्ठों को संसाधनों तक पहुँचने की अनुमति है।
http://normal-website.com/example/example.html के संदर्भ में same-origin नीति का अनुप्रयोग निम्नलिखित रूप में दर्शाया गया है:
http://normal-website.com/example/
हाँ: समान योजना, डोमेन, और पोर्ट
http://normal-website.com/example2/
हाँ: समान योजना, डोमेन, और पोर्ट
https://normal-website.com/example/
नहीं: भिन्न योजना और पोर्ट
http://en.normal-website.com/example/
नहीं: भिन्न डोमेन
http://www.normal-website.com/example/
नहीं: भिन्न डोमेन
http://normal-website.com:8080/example/
नहीं: भिन्न पोर्ट*
*Internet Explorer समान-उत्पत्ति नीति को लागू करते समय पोर्ट संख्या की अनदेखी करता है, जिससे यह पहुँच की अनुमति मिलती है।
Access-Control-Allow-Origin Headerयह हेडर कई उत्पत्ति की अनुमति दे सकता है, एक null मान, या एक वाइल्डकार्ड *। हालाँकि, कोई भी ब्राउज़र कई उत्पत्ति का समर्थन नहीं करता, और वाइल्डकार्ड * के उपयोग पर सीमाएँ हैं। (वाइल्डकार्ड को अकेले उपयोग किया जाना चाहिए, और Access-Control-Allow-Credentials: true के साथ इसका उपयोग अनुमति नहीं है।)
यह हेडर एक सर्वर द्वारा जारी किया जाता है एक क्रॉस-डोमेन संसाधन अनुरोध के जवाब में जो एक वेबसाइट द्वारा आरंभ किया गया है, जिसमें ब्राउज़र स्वचालित रूप से एक Origin हेडर जोड़ता है।
Access-Control-Allow-Credentials Headerडिफ़ॉल्ट रूप से, क्रॉस-उत्पत्ति अनुरोध बिना क्रेडेंशियल्स जैसे कुकीज़ या ऑथराइजेशन हेडर के किए जाते हैं। फिर भी, एक क्रॉस-डोमेन सर्वर क्रेडेंशियल्स भेजे जाने पर प्रतिक्रिया को पढ़ने की अनुमति दे सकता है जब वह Access-Control-Allow-Credentials हेडर को true पर सेट करता है।
यदि इसे true पर सेट किया गया है, तो ब्राउज़र क्रेडेंशियल्स (कुकीज़, ऑथराइजेशन हेडर, या TLS क्लाइंट सर्टिफिकेट) को संचारित करेगा।
जब विशेष परिस्थितियों के तहत क्रॉस-डोमेन अनुरोध शुरू किया जाता है, जैसे कि गैर-मानक HTTP विधि (HEAD, GET, POST के अलावा कुछ भी), नए हेडर पेश करना, या एक विशेष Content-Type हेडर मान का उपयोग करना, तो एक प्री-फ्लाइट अनुरोध की आवश्यकता हो सकती है। यह प्रारंभिक अनुरोध, OPTIONS विधि का उपयोग करते हुए, सर्वर को आगामी क्रॉस-ओरिजिन अनुरोध के इरादों के बारे में सूचित करने के लिए है, जिसमें HTTP विधियाँ और हेडर शामिल हैं जिनका वह उपयोग करने का इरादा रखता है।
क्रॉस-ओरिजिन रिसोर्स शेयरिंग (CORS) प्रोटोकॉल इस प्री-फ्लाइट जांच की मांग करता है ताकि अनुरोधित क्रॉस-ओरिजिन ऑपरेशन की व्यवहार्यता का निर्धारण किया जा सके, जो अनुमत विधियों, हेडरों और मूल की विश्वसनीयता की पुष्टि करता है। प्री-फ्लाइट अनुरोध की आवश्यकता से बचने के लिए किन परिस्थितियों का पालन किया जाता है, इसके लिए Mozilla Developer Network (MDN) द्वारा प्रदान किए गए व्यापक गाइड का संदर्भ लें।
यह ध्यान रखना महत्वपूर्ण है कि प्री-फ्लाइट अनुरोध की अनुपस्थिति प्रतिक्रिया के लिए प्राधिकरण हेडर ले जाने की आवश्यकता को समाप्त नहीं करती है। इन हेडरों के बिना, ब्राउज़र क्रॉस-ओरिजिन अनुरोध से प्रतिक्रिया को संसाधित करने में असमर्थ है।
PUT विधि का उपयोग करने के साथ-साथ Special-Request-Header नामक एक कस्टम हेडर का उपयोग करने के लिए प्री-फ्लाइट अनुरोध का निम्नलिखित चित्रण पर विचार करें:
उत्तर में, सर्वर हेडर वापस कर सकता है जो स्वीकृत विधियों, अनुमत मूल, और अन्य CORS नीति विवरणों को इंगित करते हैं, जैसा कि नीचे दिखाया गया है:
Access-Control-Allow-Headers: यह हेडर यह निर्दिष्ट करता है कि वास्तविक अनुरोध के दौरान कौन से हेडर का उपयोग किया जा सकता है। इसे सर्वर द्वारा सेट किया जाता है ताकि क्लाइंट से अनुरोधों में अनुमत हेडर का संकेत दिया जा सके।
Access-Control-Expose-Headers: इस हेडर के माध्यम से, सर्वर क्लाइंट को सूचित करता है कि कौन से हेडर सरल प्रतिक्रिया हेडर के अलावा प्रतिक्रिया के हिस्से के रूप में उजागर किए जा सकते हैं।
Access-Control-Max-Age: यह हेडर यह दर्शाता है कि प्री-फ्लाइट अनुरोध के परिणामों को कितनी देर तक कैश किया जा सकता है। सर्वर अधिकतम समय सेट करता है, सेकंड में, जो प्री-फ्लाइट अनुरोध द्वारा लौटाई गई जानकारी को पुन: उपयोग किया जा सकता है।
Access-Control-Request-Headers: प्री-फ्लाइट अनुरोधों में उपयोग किया जाता है, यह हेडर क्लाइंट द्वारा सेट किया जाता है ताकि सर्वर को सूचित किया जा सके कि क्लाइंट वास्तविक अनुरोध में कौन से HTTP हेडर का उपयोग करना चाहता है।
Access-Control-Request-Method: यह हेडर, जो प्री-फ्लाइट अनुरोधों में भी उपयोग किया जाता है, क्लाइंट द्वारा सेट किया जाता है ताकि यह संकेत दिया जा सके कि वास्तविक अनुरोध में कौन सा HTTP विधि का उपयोग किया जाएगा।
Origin: यह हेडर स्वचालित रूप से ब्राउज़र द्वारा सेट किया जाता है और क्रॉस-ओरिजिन अनुरोध के मूल को दर्शाता है। इसका उपयोग सर्वर द्वारा यह आकलन करने के लिए किया जाता है कि क्या आने वाले अनुरोध को CORS नीति के आधार पर अनुमति दी जानी चाहिए या अस्वीकृत किया जाना चाहिए।
ध्यान दें कि आमतौर पर (सामग्री-प्रकार और सेट किए गए हेडर के आधार पर) एक GET/POST अनुरोध में कोई प्री-फ्लाइट अनुरोध नहीं भेजा जाता (अनुरोध प्रत्यक्ष भेजा जाता है), लेकिन यदि आप प्रतिक्रिया के हेडर/शरीर तक पहुंचना चाहते हैं, तो इसमें एक Access-Control-Allow-Origin हेडर होना चाहिए जो इसकी अनुमति देता है। इसलिए, CORS CSRF के खिलाफ सुरक्षा नहीं करता (लेकिन यह सहायक हो सकता है)।
Access-Control-Request-Local-Network: यह हेडर क्लाइंट के अनुरोध में शामिल किया जाता है ताकि यह संकेत दिया जा सके कि पूछताछ एक स्थानीय नेटवर्क संसाधन के लिए है। यह सर्वर को सूचित करने के लिए एक मार्कर के रूप में कार्य करता है कि अनुरोध स्थानीय नेटवर्क के भीतर से उत्पन्न होता है।
Access-Control-Allow-Local-Network: इसके जवाब में, सर्वर इस हेडर का उपयोग यह संप्रेषित करने के लिए करते हैं कि अनुरोधित संसाधन को स्थानीय नेटवर्क के बाहर की संस्थाओं के साथ साझा करने की अनुमति है। यह विभिन्न नेटवर्क सीमाओं के पार संसाधनों को साझा करने के लिए एक हरी बत्ती के रूप में कार्य करता है, जबकि सुरक्षा प्रोटोकॉल को बनाए रखते हुए नियंत्रित पहुंच सुनिश्चित करता है।
एक मान्य प्रतिक्रिया जो स्थानीय नेटवर्क अनुरोध की अनुमति देती है को प्रतिक्रिया में Access-Controls-Allow-Local_network: true हेडर भी होना चाहिए:
ध्यान दें कि लिनक्स 0.0.0.0 आईपी इन आवश्यकताओं को बायपास करने के लिए काम करता है ताकि localhost तक पहुंचा जा सके क्योंकि उस आईपी पते को "स्थानीय" नहीं माना जाता है।
यदि आप स्थानीय एंडपॉइंट का सार्वजनिक आईपी पता (जैसे राउटर का सार्वजनिक आईपी) का उपयोग करते हैं तो स्थानीय नेटवर्क आवश्यकताओं को बायपास करना भी संभव है। क्योंकि कई अवसरों पर, भले ही सार्वजनिक आईपी तक पहुंचा जा रहा हो, यदि यह स्थानीय नेटवर्क से है, तो पहुंच दी जाएगी।
ध्यान दें कि भले ही निम्नलिखित कॉन्फ़िगरेशन सुपर अनुमति देने वाला लग सकता है:
यह ब्राउज़रों द्वारा अनुमति नहीं है और इसलिए क्रेडेंशियल्स इस अनुरोध के साथ नहीं भेजे जाएंगे।
यह देखा गया है कि Access-Control-Allow-Credentials को true पर सेट करना अधिकांश वास्तविक हमलों के लिए एक पूर्वापेक्षा है। यह सेटिंग ब्राउज़र को क्रेडेंशियल्स भेजने और प्रतिक्रिया पढ़ने की अनुमति देती है, जिससे हमले की प्रभावशीलता बढ़ती है। इसके बिना, ब्राउज़र को अनुरोध करने के लाभ को स्वयं करने की तुलना में कम कर दिया जाता है, क्योंकि उपयोगकर्ता के कुकीज़ का लाभ उठाना असंभव हो जाता है।
एक अपवाद है जहां पीड़ित का नेटवर्क स्थान प्रमाणीकरण के एक रूप के रूप में कार्य करता है। यह पीड़ित के ब्राउज़र का उपयोग एक प्रॉक्सी के रूप में करने की अनुमति देता है, आईपी-आधारित प्रमाणीकरण को दरकिनार करते हुए इंट्रानेट अनुप्रयोगों तक पहुँचने के लिए। यह विधि DNS रीबाइंडिंग के प्रभाव में समानताएँ साझा करती है लेकिन इसे शोषण करना सरल है।
Access-Control-Allow-Origin में Origin का परावर्तनवास्तविक परिदृश्य जहां Origin हेडर का मान Access-Control-Allow-Origin में परावर्तित होता है, सिद्धांत रूप से असंभव है क्योंकि इन हेडरों को संयोजित करने पर प्रतिबंध हैं। हालाँकि, डेवलपर्स जो कई URL के लिए CORS सक्षम करना चाहते हैं, वे Origin हेडर के मान को कॉपी करके Access-Control-Allow-Origin हेडर को गतिशील रूप से उत्पन्न कर सकते हैं। यह दृष्टिकोण कमजोरियों को पेश कर सकता है, विशेष रूप से जब एक हमलावर एक ऐसा डोमेन उपयोग करता है जिसका नाम वैध दिखने के लिए डिज़ाइन किया गया है, जिससे प्रमाणीकरण लॉजिक को धोखा दिया जा सके।
null उत्पत्ति का शोषणnull उत्पत्ति, जिसे रीडायरेक्ट या स्थानीय HTML फ़ाइलों जैसी स्थितियों के लिए निर्दिष्ट किया गया है, एक अद्वितीय स्थिति रखती है। कुछ अनुप्रयोग इस उत्पत्ति को स्थानीय विकास को सुविधाजनक बनाने के लिए व्हाइटलिस्ट करते हैं, अनजाने में किसी भी वेबसाइट को एक सैंडबॉक्स किए गए iframe के माध्यम से null उत्पत्ति की नकल करने की अनुमति देते हैं, इस प्रकार CORS प्रतिबंधों को बायपास करते हैं।
जब एक डोमेन व्हाइटलिस्ट का सामना करना पड़ता है, तो बायपास के अवसरों का परीक्षण करना महत्वपूर्ण है, जैसे कि हमलावर के डोमेन को व्हाइटलिस्टेड डोमेन में जोड़ना या सबडोमेन टेकओवर कमजोरियों का लाभ उठाना। इसके अतिरिक्त, डोमेन मान्यता के लिए उपयोग की जाने वाली नियमित अभिव्यक्तियाँ डोमेन नामकरण परंपराओं में बारीकियों को नजरअंदाज कर सकती हैं, जिससे और भी बायपास के अवसर उत्पन्न होते हैं।
Regex पैटर्न आमतौर पर अल्फ़ान्यूमेरिक, डॉट (.), और हाइफ़न (-) वर्णों पर ध्यान केंद्रित करते हैं, अन्य संभावनाओं की अनदेखी करते हैं। उदाहरण के लिए, एक डोमेन नाम जो ऐसे वर्णों को शामिल करने के लिए तैयार किया गया है जिन्हें ब्राउज़रों और regex पैटर्न द्वारा अलग तरीके से व्याख्यायित किया जाता है, सुरक्षा जांचों को बायपास कर सकता है। Safari, Chrome, और Firefox द्वारा सबडोमेन में अंडरस्कोर वर्णों के प्रबंधन से यह स्पष्ट होता है कि कैसे ऐसे भिन्नताएँ डोमेन मान्यता तर्क को दरकिनार करने के लिए उपयोग की जा सकती हैं।
इस बायपास जांच की अधिक जानकारी और सेटिंग्स के लिए: https://www.corben.io/advanced-cors-techniques/ और https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397
डेवलपर्स अक्सर CORS शोषण से बचाने के लिए सुरक्षा तंत्र लागू करते हैं, उन डोमेन को व्हाइटलिस्ट करके जिन्हें जानकारी मांगने की अनुमति है। इन सावधानियों के बावजूद, सिस्टम की सुरक्षा पूरी तरह से सुरक्षित नहीं है। व्हाइटलिस्टेड डोमेनों के भीतर एक भी कमजोर सबडोमेन की उपस्थिति अन्य कमजोरियों, जैसे कि XSS (क्रॉस-साइट स्क्रिप्टिंग) के माध्यम से CORS शोषण के लिए दरवाजे खोल सकती है।
उदाहरण के लिए, उस परिदृश्य पर विचार करें जहाँ एक डोमेन, requester.com, को दूसरे डोमेन, provider.com से संसाधनों तक पहुँचने के लिए व्हाइटलिस्ट किया गया है। सर्वर-साइड कॉन्फ़िगरेशन कुछ इस तरह दिख सकता है:
इस सेटअप में, requester.com के सभी सबडोमेन को एक्सेस की अनुमति है। हालाँकि, यदि कोई सबडोमेन, जैसे sub.requester.com, XSS कमजोरियों के साथ समझौता किया गया है, तो एक हमलावर इस कमजोरी का लाभ उठा सकता है। उदाहरण के लिए, sub.requester.com तक पहुँच रखने वाला एक हमलावर XSS कमजोरी का उपयोग करके CORS नीतियों को बायपास कर सकता है और provider.com पर संसाधनों तक दुर्भावनापूर्ण तरीके से पहुँच प्राप्त कर सकता है।
PortSwigger का URL validation bypass cheat sheet ने पाया कि कुछ ब्राउज़र डोमेन नामों के भीतर अजीब वर्णों का समर्थन करते हैं।
Chrome और Firefox अंडरस्कोर _ का समर्थन करते हैं जो Origin हेडर को मान्य करने के लिए लागू किए गए regexes को बायपास कर सकते हैं:
Safari विशेष वर्णों को डोमेन नाम में स्वीकार करने में और भी अधिक लचीला है:
यह संभव है कि HTTP हेडर इंजेक्शन के माध्यम से सर्वर-साइड कैश पॉइज़निंग का लाभ उठाकर, एक संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS) भेद्यता उत्पन्न की जा सके। यह परिदृश्य तब सामने आता है जब एक एप्लिकेशन अवैध वर्णों के लिए Origin हेडर को साफ़ करने में विफल रहता है, जो विशेष रूप से इंटरनेट एक्सप्लोरर और एज उपयोगकर्ताओं के लिए एक भेद्यता उत्पन्न करता है। ये ब्राउज़र (0x0d) को एक वैध HTTP हेडर टर्मिनेटर के रूप में मानते हैं, जिससे HTTP हेडर इंजेक्शन भेद्यताएँ उत्पन्न होती हैं।
निम्नलिखित अनुरोध पर विचार करें जहाँ Origin हेडर को हेरफेर किया गया है:
Internet Explorer और Edge प्रतिक्रिया को इस प्रकार समझते हैं:
While directly exploiting this vulnerability by making a web browser send a malformed header is not feasible, a crafted request can be manually generated using tools like Burp Suite. This method could lead to a server-side cache saving the response and inadvertently serving it to others. The crafted payload aims to alter the page's character set to UTF-7, a character encoding often associated with XSS vulnerabilities due to its ability to encode characters in a way that can be executed as script in certain contexts.
For further reading on stored XSS vulnerabilities, see PortSwigger.
Note: HTTP हेडर इंजेक्शन कमजोरियों का शोषण, विशेष रूप से सर्वर-साइड कैश पॉइज़निंग के माध्यम से, सभी उपयोगकर्ता-प्रदत्त इनपुट, जिसमें HTTP हेडर शामिल हैं, को मान्य और स्वच्छ करने के महत्व को रेखांकित करता है। हमेशा एक मजबूत सुरक्षा मॉडल का उपयोग करें जिसमें इनपुट मान्यता शामिल हो ताकि ऐसी कमजोरियों को रोका जा सके।
In this scenario, an instance of a web page reflecting the contents of a custom HTTP header without proper encoding is observed. Specifically, the web page reflects back the contents included in a X-User-id header, which could include malicious JavaScript, as demonstrated by the example where the header contains an SVG image tag designed to execute JavaScript code on load.
Cross-Origin Resource Sharing (CORS) नीतियाँ कस्टम हेडर भेजने की अनुमति देती हैं। हालांकि, बिना CORS प्रतिबंधों के कारण ब्राउज़र द्वारा सीधे प्रतिक्रिया को प्रस्तुत किए बिना, ऐसी इंजेक्शन की उपयोगिता सीमित लग सकती है। महत्वपूर्ण बिंदु तब आता है जब ब्राउज़र के कैश व्यवहार पर विचार किया जाता है। यदि Vary: Origin हेडर निर्दिष्ट नहीं किया गया है, तो यह संभव हो जाता है कि दुर्भावनापूर्ण प्रतिक्रिया को ब्राउज़र द्वारा कैश किया जाए। इसके बाद, यह कैश की गई प्रतिक्रिया सीधे URL पर नेविगेट करते समय प्रस्तुत की जा सकती है, प्रारंभिक अनुरोध पर सीधे प्रस्तुत करने की आवश्यकता को दरकिनार करते हुए। यह तंत्र हमले की विश्वसनीयता को बढ़ाता है क्योंकि यह क्लाइंट-साइड कैशिंग का लाभ उठाता है।
To illustrate this attack, a JavaScript example is provided, designed to be executed in the environment of a web page, such as through a JSFiddle. This script performs a simple action: it sends a request to a specified URL with a custom header containing the malicious JavaScript. Upon successful request completion, it attempts to navigate to the target URL, potentially triggering the execution of the injected script if the response has been cached without proper handling of the Vary: Origin header.
Here's a summarized breakdown of the JavaScript used to execute this attack:
XSSI, जिसे Cross-Site Script Inclusion के नाम से भी जाना जाता है, एक प्रकार की भेद्यता है जो इस तथ्य का लाभ उठाती है कि Same Origin Policy (SOP) तब लागू नहीं होती जब संसाधनों को स्क्रिप्ट टैग का उपयोग करके शामिल किया जाता है। इसका कारण यह है कि स्क्रिप्ट को विभिन्न डोमेन से शामिल किया जा सकता है। यह भेद्यता एक हमलावर को स्क्रिप्ट टैग का उपयोग करके शामिल की गई किसी भी सामग्री को एक्सेस और पढ़ने की अनुमति देती है।
यह भेद्यता विशेष रूप से महत्वपूर्ण हो जाती है जब यह गतिशील JavaScript या JSONP (JSON with Padding) की बात आती है, विशेष रूप से जब ऑब्जेक्ट-ऑथोरिटी जानकारी जैसे कि कुकीज़ का उपयोग प्रमाणीकरण के लिए किया जाता है। जब किसी अलग होस्ट से संसाधन का अनुरोध किया जाता है, तो कुकीज़ शामिल होती हैं, जिससे वे हमलावर के लिए उपलब्ध हो जाती हैं।
इस भेद्यता को बेहतर ढंग से समझने और कम करने के लिए, आप https://github.com/kapytein/jsonp पर उपलब्ध BurpSuite प्लगइन का उपयोग कर सकते हैं। यह प्लगइन आपकी वेब अनुप्रयोगों में संभावित XSSI भेद्यताओं की पहचान करने और उन्हें संबोधित करने में मदद कर सकता है।
XSSI के विभिन्न प्रकारों और उन्हें कैसे शोषण करें, इसके बारे में अधिक पढ़ें।
अनुरोध में एक callback पैरामीटर जोड़ने का प्रयास करें। शायद पृष्ठ को JSONP के रूप में डेटा भेजने के लिए तैयार किया गया था। इस मामले में, पृष्ठ Content-Type: application/javascript के साथ डेटा वापस भेजेगा, जो CORS नीति को बायपास करेगा।
Access-Control-Allow-Origin प्रतिबंध को बायपास करने का एक तरीका यह है कि एक वेब अनुप्रयोग से आपके पक्ष में अनुरोध करने के लिए कहा जाए और प्रतिक्रिया वापस भेजी जाए। हालाँकि, इस परिदृश्य में, अंतिम पीड़ित के क्रेडेंशियल्स नहीं भेजे जाएंगे क्योंकि अनुरोध एक अलग डोमेन पर किया गया है।
CORS-escape: यह उपकरण एक प्रॉक्सी प्रदान करता है जो आपके अनुरोध को इसके हेडर के साथ आगे बढ़ाता है, जबकि अनुरोधित डोमेन से मेल खाने के लिए Origin हेडर को भी स्पूफ करता है। यह प्रभावी रूप से CORS नीति को बायपास करता है। यहाँ XMLHttpRequest के साथ एक उदाहरण उपयोग है:
simple-cors-escape: यह उपकरण अनुरोधों को प्रॉक्सी करने के लिए एक वैकल्पिक दृष्टिकोण प्रदान करता है। आपके अनुरोध को जैसा है वैसा पास करने के बजाय, सर्वर निर्दिष्ट पैरामीटर के साथ अपना स्वयं का अनुरोध करता है।
आप CORS जांचों जैसे e.origin === window.origin को एक iframe बनाकर और उससे एक नई विंडो खोलकर बायपास कर सकते हैं। अधिक जानकारी के लिए निम्नलिखित पृष्ठ में देखें:
TTL के माध्यम से DNS रीबाइंडिंग एक तकनीक है जिसका उपयोग DNS रिकॉर्ड को हेरफेर करके कुछ सुरक्षा उपायों को बायपास करने के लिए किया जाता है। यह कैसे काम करता है:
हमलावर एक वेब पृष्ठ बनाता है और पीड़ित को इसे एक्सेस करने के लिए कहता है।
फिर हमलावर अपने डोमेन का DNS (IP) बदलता है ताकि यह पीड़ित के वेब पृष्ठ की ओर इशारा करे।
पीड़ित का ब्राउज़र DNS प्रतिक्रिया को कैश करता है, जिसमें TTL (Time to Live) मान हो सकता है जो यह दर्शाता है कि DNS रिकॉर्ड को कितनी देर तक मान्य माना जाना चाहिए।
जब TTL समाप्त होता है, तो पीड़ित का ब्राउज़र एक नया DNS अनुरोध करता है, जिससे हमलावर को पीड़ित के पृष्ठ पर JavaScript कोड निष्पादित करने की अनुमति मिलती है।
पीड़ित के IP पर नियंत्रण बनाए रखकर, हमलावर बिना किसी कुकीज़ को पीड़ित सर्वर पर भेजे जानकारी एकत्र कर सकता है।
यह ध्यान रखना महत्वपूर्ण है कि ब्राउज़रों में कैशिंग तंत्र होते हैं जो इस तकनीक के तात्कालिक दुरुपयोग को रोक सकते हैं, भले ही TTL मान कम हो।
DNS रीबाइंडिंग पीड़ित द्वारा किए गए स्पष्ट IP जांचों को बायपास करने के लिए या उन परिदृश्यों के लिए उपयोगी हो सकती है जहां एक उपयोगकर्ता या बॉट एक विस्तारित अवधि के लिए एक ही पृष्ठ पर रहता है, जिससे कैश समाप्त हो जाता है।
यदि आपको DNS रीबाइंडिंग का दुरुपयोग करने का एक त्वरित तरीका चाहिए, तो आप https://lock.cmpxchg8b.com/rebinder.html जैसी सेवाओं का उपयोग कर सकते हैं।
अपने स्वयं के DNS रीबाइंडिंग सर्वर को चलाने के लिए, आप DNSrebinder (https://github.com/mogwailabs/DNSrebinder) जैसे उपकरणों का उपयोग कर सकते हैं। इसमें आपके स्थानीय पोर्ट 53/udp को उजागर करना, इसके लिए एक A रिकॉर्ड बनाना (जैसे, ns.example.com), और पहले बनाए गए A उपडोमेन (जैसे, ns.example.com) की ओर इशारा करने वाला एक NS रिकॉर्ड बनाना शामिल है। ns.example.com उपडोमेन का कोई भी उपडोमेन तब आपके होस्ट द्वारा हल किया जाएगा।
आप आगे की समझ और प्रयोग के लिए http://rebind.it/singularity.html पर एक सार्वजनिक रूप से चलने वाले सर्वर का भी अन्वेषण कर सकते हैं।
DNS कैश बाढ़ के माध्यम से DNS रीबाइंडिंग एक और तकनीक है जिसका उपयोग ब्राउज़रों के कैशिंग तंत्र को बायपास करने और एक दूसरा DNS अनुरोध करने के लिए किया जाता है। यह कैसे काम करता है:
प्रारंभ में, जब पीड़ित एक DNS अनुरोध करता है, तो इसे हमलावर के IP पते के साथ उत्तर दिया जाता है।
कैशिंग रक्षा को बायपास करने के लिए, हमलावर एक सेवा कार्यकर्ता का लाभ उठाता है। सेवा कार्यकर्ता DNS कैश को बाढ़ करता है, जो प्रभावी रूप से कैश किए गए हमलावर सर्वर नाम को हटा देता है।
जब पीड़ित का ब्राउज़र एक दूसरा DNS अनुरोध करता है, तो इसे अब IP पते 127.0.0.1 के साथ उत्तर दिया जाता है, जो आमतौर पर लोकलहोस्ट को संदर्भित करता है।
सेवा कार्यकर्ता के साथ DNS कैश को बाढ़ करके, हमलावर DNS समाधान प्रक्रिया को हेरफेर कर सकता है और पीड़ित के ब्राउज़र को एक दूसरा अनुरोध करने के लिए मजबूर कर सकता है, इस बार हमलावर के इच्छित IP पते को हल करते हुए।
कैशिंग रक्षा को बायपास करने का एक और तरीका DNS प्रदाता में एक ही उपडोमेन के लिए कई IP पते का उपयोग करना है। यह कैसे काम करता है:
हमलावर DNS प्रदाता में एक ही उपडोमेन के लिए दो A रिकॉर्ड (या दो IPs के साथ एक A रिकॉर्ड) सेट करता है।
जब एक ब्राउज़र इन रिकॉर्ड्स की जांच करता है, तो यह दोनों IP पते प्राप्त करता है।
यदि ब्राउज़र पहले हमलावर के IP पते का उपयोग करने का निर्णय लेता है, तो हमलावर एक पेलोड प्रदान कर सकता है जो उसी डोमेन पर HTTP अनुरोध करता है।
हालाँकि, एक बार जब हमलावर पीड़ित के IP पते को प्राप्त कर लेता है, तो वे पीड़ित के ब्राउज़र को उत्तर देना बंद कर देते हैं।
पीड़ित का ब्राउज़र, यह महसूस करते हुए कि डोमेन अनुप्रतिक्रियाशील है, दूसरे दिए गए IP पते का उपयोग करने के लिए आगे बढ़ता है।
दूसरे IP पते तक पहुँचकर, ब्राउज़र Same Origin Policy (SOP) को बायपास करता है, जिससे हमलावर इसका दुरुपयोग कर सकता है और जानकारी एकत्र और एक्सफिल्ट्रेट कर सकता है।
यह तकनीक उन ब्राउज़रों के व्यवहार का लाभ उठाती है जब एक डोमेन के लिए कई IP पते प्रदान किए जाते हैं। प्रतिक्रियाओं को रणनीतिक रूप से नियंत्रित करके और ब्राउज़र के IP पते के चयन में हेरफेर करके, एक हमलावर SOP का शोषण कर सकता है और पीड़ित से जानकारी प्राप्त कर सकता है।
ध्यान दें कि लोकलहोस्ट तक पहुँचने के लिए आपको Windows में 127.0.0.1 और Linux में 0.0.0.0 को रीबाइंड करने का प्रयास करना चाहिए। प्रदाताओं जैसे godaddy या cloudflare ने मुझे IP 0.0.0.0 का उपयोग करने की अनुमति नहीं दी, लेकिन AWS route53 ने मुझे 2 IPs के साथ एक A रिकॉर्ड बनाने की अनुमति दी, जिनमें से एक "0.0.0.0" है।
अधिक जानकारी के लिए आप https://unit42.paloaltonetworks.com/dns-rebinding/ देख सकते हैं।
यदि आंतरिक IPs की अनुमति नहीं है, तो वे 0.0.0.0 को प्रतिबंधित करना भूल सकते हैं (Linux और Mac पर काम करता है)
यदि आंतरिक IPs की अनुमति नहीं है, तो localhost के लिए एक CNAME के साथ उत्तर दें (Linux और Mac पर काम करता है)
यदि आंतरिक IPs को DNS प्रतिक्रियाओं के रूप में अनुमति नहीं है, तो आप आंतरिक सेवाओं के लिए CNAMEs के साथ उत्तर दे सकते हैं जैसे www.corporate.internal।
आप पिछले बायपास तकनीकों और निम्नलिखित उपकरण का उपयोग कैसे करें, इसके बारे में अधिक जानकारी Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference में पा सकते हैं।
Singularity of Origin एक उपकरण है जो DNS रीबाइंडिंग हमलों को करने के लिए है। इसमें हमलावर सर्वर DNS नाम के IP पते को लक्षित मशीन के IP पते पर रीबाइंड करने और लक्षित मशीन पर कमजोर सॉफ़्टवेयर का शोषण करने के लिए हमलावर पेलोड प्रदान करने के लिए आवश्यक घटक शामिल हैं।
आंतरिक सेवाओं में TLS का उपयोग करें
डेटा तक पहुँचने के लिए प्रमाणीकरण का अनुरोध करें
Host हेडर को मान्य करें
https://wicg.github.io/private-network-access/: प्रस्ताव जब सार्वजनिक सर्वर आंतरिक सर्वरों तक पहुँच प्राप्त करना चाहते हैं तो हमेशा एक प्री-फ्लाइट अनुरोध भेजें
CORS नीतियों में संभावित गलत कॉन्फ़िगरेशन को फज़ करें
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
