# DNS Rebinding Youtube videos:\ ## How to DNS rebinding bypass SOP ? DNS rebinding is a clever technique attackers utilize to circumvent the Same-Origin Policy (SOP) – a fundamental browser security measure. The SOP prevents scripts loaded from one origin (combination of protocol, host, and port) from interacting with resources from a different origin. DNS rebinding exploits how DNS resolution and browser caching work to bypass this restriction. Here's how attackers exploit DNS rebinding to bypass the SOP: 1. Malicious Domain and Short TTL: An attacker sets up a malicious website (e.g., `attacker.com`) and controls its DNS server. Initially, they configure the DNS records to point to a public server they control and set a very short Time-to-Live (TTL) value for the DNS record, effectively instructing the browser not to cache the DNS entry for very long. 2. Victim Accesses Malicious Website: The attacker employs tactics like phishing to trick a victim into visiting their malicious website. 3. Initial DNS Resolution and Script Execution: The victim's browser resolves `attacker.com` to the attacker's public server and loads the malicious webpage, which contains JavaScript designed to exploit vulnerabilities. 4. DNS Rebinding: As the script continues to run, the attacker's DNS server changes the IP address associated with `attacker.com` to a private IP address within the victim's local network (e.g., `127.0.0.1` or the IP of a router or internal device). 5. Cross-Origin Requests: The script then makes subsequent requests to `attacker.com`. Because the browser is still in the context of `attacker.com`, it perceives these requests as same-origin, even though the DNS resolution has redirected them to a private IP address. This bypasses the SOP, allowing the malicious script to interact with internal resources or sensitive data on the victim's network that would otherwise be inaccessible.\
### Risks and Consequences DNS rebinding attacks pose serious risks, potentially leading to: * Data Exfiltration: Attackers can steal sensitive information from internal services or devices. * Unauthorized Access: They can gain control of internal machines or services within a private network. * Disruption of Services: Attackers can disrupt businesses by manipulating internal systems. * Financial Losses and Reputational Damage: These attacks can result in legal expenses, fines, and a loss of trust from customers and stakeholders. ### Mitigation and Prevention Organizations and users can implement several measures to protect themselves from DNS rebinding attacks: * Use HTTPS for Internal Services: Employing HTTPS for all private services helps validate server identities and encrypt data, hindering an attacker's ability to establish malicious connections. * Restrict JavaScript Execution: Limit the ability of untrusted JavaScript to run on your network. This can be achieved through Content Security Policies, [regularly updating software to patch vulnerabilities](https://heimdalsecurity.com/blog/dns-rebinding/), and educating users about the risks of visiting suspicious websites. * DNS Pinning: Implement DNS pinning, which forces browsers to cache DNS resolution results for a fixed period, regardless of the TTL value. This prevents attackers from rapidly changing the IP address associated with a hostname. * Filter DNS Responses with Private IPs: Configure DNS resolvers to block responses that return private, loopback, or non-routable IP addresses. * Enforce Host Header Validation: Configure internal web servers to reject requests with unrecognized or unexpected host headers. * Require Authentication on Internal Services: Enforce strong authentication mechanisms for accessing all internal services to prevent attackers from interacting with them even if they manage to reach them via DNS rebinding. * Network Segmentation: Segment internal networks to limit the impact of a successful DNS rebinding attack by isolating different resources. * Use a Protective DNS Solution: Partner with a reputable DNS security provider that offers real-time protection, monitors for suspicious DNS query patterns, and utilizes threat intelligence to block known DNS rebinding attack indicators. By understanding the mechanics of DNS rebinding attacks and implementing robust security practices, organizations and individuals can significantly reduce their vulnerability and protect against this persistent threat. ### Bypassing Server-Side Request Forgery (SSRF) Checks with DNS Rebinding DNS rebinding can be used to bypass common SSRF checks that involve validating the hostname of a URL provided to the server. Many applications implement allowlists or denylists to restrict the domains or IP addresses that the server can send requests to. DNS rebinding exploits how DNS resolution works to trick the server into believing it's accessing a legitimate, whitelisted resource, only to then redirect the request to an internal or unauthorized location. Here's a step-by-step breakdown of how DNS rebinding can bypass SSRF checks: 1. Initial DNS Resolution (Allowlist Bypass): * The attacker registers a domain name, say `malicious.com`, and controls its DNS server. * Initially, the attacker configures the DNS record for `malicious.com` to resolve to a public IP address they control (e.g., 1.2.3.4), or an IP address that would pass the SSRF check's allowlist. * The attacker then crafts a malicious request to a vulnerable endpoint of the target application, providing the URL `http://malicious.com/payload` as input. * The vulnerable application resolves `malicious.com` to the attacker's controlled IP (1.2.3.4), passing the initial allowlist check. 2. DNS Rebinding and Subsequent Request (Internal Network Access): * Before the application makes a connection to `malicious.com`, the attacker rapidly changes the DNS configuration for `malicious.com` to resolve to a private IP address within the target's internal network (e.g., 10.0.0.1 or 127.0.0.1 - localhost) and sets a very short Time-to-Live (TTL) for the DNS record. * The application, after the initial DNS lookup and allowlist check, attempts to make the actual HTTP request to `malicious.com`. * If the DNS cache has expired or the application re-resolves the domain name, it will now resolve to the internal IP address (10.0.0.1 or 127.0.0.1). * Because the hostname of the request remains `malicious.com`, which has already passed the initial allowlist check, the server proceeds to make the request to the internal IP address, effectively bypassing the SSRF check. * The attacker can then exploit this access to perform actions like scanning internal ports, accessing internal services or metadata APIs (e.g., AWS metadata service), or exploiting other vulnerabilities on internal systems. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://n0m4dsec.gitbook.io/sec-book/additional-topics/dns-rebinding.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.