Full Report
DNS rebinding is a fairly well-known attack used in various situations. The idea is to trick the browser on the origin of the website by changing IP address between DNS requests. For instance, if it's 1.2.3.4 initially but an internal IP afterwards, like 127.0.0.1, then we can make requests to localhost and bypass the same origin policy. Historically, these were used for accessing internal networks of users within the browser. With the invention of headless browsers, this has became a good attack method on it as well. In a previous post by the authors, they used this to get access to EC2 metadata credentials on their product. They could run this as long as they wanted, with no time constraints. However, what if we don't have unlimited time? The main constraint of DNS rebinding is the time between DNS lookups. Since browsers cache DNS, we need a way to force a new lookup. A popular way to force a new lookup is by flushing the cache by overloading it with so many entries, which takes about 10 seconds. However, other things like Ubuntu will take 5 minutes or VPNs take 30. In previous research, Craig Heffner performed DNS rebinding by relying with multiple A records for the same domain in the same response. The 2 records were a public IP and a private IP. To make this exploitable, the browser must use the public IP first then the private one later. To force the usage of the second (private) entry a TCP RST was sent to the browser on the original IP address would fallback to the second one, which was a private IP. With this in mind, they decided to look various browsers to see if new techniques could be discovered. On Safari, the private record is prioritized. Additionally, the requests for the A record and AAAA records were done in parallel. Once the first DNS response is received, regardless of the ipv4 or ipv6 status, this will be used for the DNS request. Putting this information together, a slight delay on the private IP will lead to a quick DNS rebind. First, return the public IP for the website in one of the responses, but faster than the other. Once the private IP is returned, the browser will use this one instead. Now, we have a super faster DNS rebinding attack on Safari. On Chrome, it has a priority list: local IPv6, public IPv6, local IPv4 and public IPv4. When Chrome knows about multiple IP addresses, it will try a different IP address as soon as one of the servers resets the connection. So, putting this all together, we can attack the browser as follows: Load the website. Have an A record pointing to the local network and an AAAA (IPv6) pointing to a public website that you control. Chrome will use the IPv6 for the initial request. Shutdown the public server. This will send a reset. The loaded page will now use the private IPv4 address instead of the IPv6, allowing for a SOP bypass. Private Network Access (PNA) is a specification for blocking pages loaded over HTTP to make request to private networks. This prevents the exploitability of DNS rebinding because we can no longer access private IPs. However, in Chrome where this is implemented, this is NOT done on iFrames yet. The attack is exactly the same as the previous Chrome issue except with a twist of using an iFrame in the middle of it. From the previous step 5, instead of making the request to localhost directly, we do this inside of an iFrame. Load the private URL in an iFrame. After this has been done, inject a script into the loaded iFrame. Now, you can make requests successfully with the DNS rebinding. Overall, an amazing list of techniques to make DNS rebinding more exploitable. This is one of the best articles I've read in a long time and is just amazing research. Thank you Daniel!
Analysis Summary
# Tool/Technique: DNS Rebinding Exploitation Techniques
## Overview
The techniques summarized focus on exploiting DNS rebinding vulnerabilities in web browsers (specifically Safari and Chrome/Chromium-based browsers) to bypass the Same Origin Policy (SOP) and access internal network resources or sensitive application metadata (like EC2 metadata credentials). The goal is to achieve reliable, "split-second" rebinds, overcoming traditional time constraints imposed by DNS caching.
## Technical Details
- Type: Technique
- Platform: Web Browsers (Safari, Chrome, Edge), Headless Browsers (e.g., Chromium used for PDF generation or screenshots)
- Capabilities: Bypassing SOP, accessing localhost services, exploiting metadata services, bypassing Private Network Access (PNA) restrictions in specific contexts (like iframes).
- First Seen: The base concept of DNS rebinding is well-known; specific techniques described relate to modern browser behavior documented around 2023/2024.
## MITRE ATT&CK Mapping
- T1568 - Obtaining Capabilities
- T1568.002 - Compromise Software Component
- While DNS rebinding primarily targets the browser/application logic, it facilitates access to internal resources:
- T1071 - Application Layer Protocol
- T1071.001 - Web Protocols
- T1543 - Break Out Box
- This technique effectively breaks out from the browser's origin confinement.
- T1549 - Inter-Process Communication (If communicating with local services)
## Functionality
### Core Capabilities
- **Forcing New DNS Lookups:** Techniques discussed to overcome caching include cache flushing (approx. 10 seconds) or relying on operating system/VPN resolvers caching (5 minutes to 30 minutes).
- **Multiple A Record Exploitation (Craig Heffner/Singularity method):** Returning multiple A records (public and private IP) and relying on an external trigger (like a TCP RST on the public IP) to force the browser to fall back to the private IP.
### Advanced Features
- **Split-Second Safari Rebind:** Exploiting Safari’s parallel A and AAAA record querying. The technique involves returning the public IP quickly and the private IP slightly later. Because Safari prioritizes private records only after receiving a response, a slight delay on the private response allows the browser to initially use the public IP, and then immediately switch to the faster-resolved private IP when it arrives, leading to a hard-fast rebind.
- **Chromium (Chrome/Edge) IPv4/IPv6 Rebind:**
1. Set an AAAA record pointing to a **public** address and an A record pointing to a **private** address.
2. Chrome prioritizes local IPv6 > public IPv6 > local IPv4 > public IPv4.
3. Initial connection uses the public IPv6 server.
4. The attacker shuts down the public IPv6 server, causing a connection reset.
5. Chrome falls back to the next available IP address according to its priority list, which ends up being the private IPv4 address, bypassing SOP.
- **iFrame PNA Bypass (Chromium):** Private Network Access (PNA) intends to block HTTP pages from accessing private networks. However, the research found this restriction was not applied to requests initiated within an `<iframe>`. The attack involves loading the target URL in an iFrame, using the standard DNS rebinding technique outlined above to redirect the iFrame's requests to a local address, and then injecting a script into the newly loaded iFrame to execute the local requests successfully.
## Indicators of Compromise
No specific network IOCs or file hashes were provided, as the focus is on the client-side attack technique configuration.
- Network Indicators: DNS records configured with associated public and private IP addresses.
## Associated Threat Actors
The research is attributed to Daniel Thatcher and presented as novel findings against modern browsers, rather than being tied to known threat groups.
## Detection Methods
Detection relies on monitoring DNS responses or network connections that exhibit the described fallback behavior immediately after connection initiation or reset events.
- Behavioral detection: Monitoring for connection resets to public IPs immediately preceding established connections to internal/private IP ranges on the same domain name or originating from domains configured with multiple IP records.
- Monitoring for unexpected internal resource access from web contexts protected by SOP/PNA (especially within iframes).
## Mitigation Strategies
- **Browser Updates:** Resolving the specific prioritization logic flaws identified in Safari and older Chrome versions, and ensuring PNA restrictions apply consistently across document contexts, including iframes.
- **DNS Configuration:** Avoiding configurations that present both public and private IPs for the same domain (e.g., avoiding dual A/AAAA records pointing to vastly different network scopes if possible, or being aware of potential risks).
- **Patching/Hardening:** Ensure all browser software (client and headless instances) is up-to-date to incorporate fixes for fast rebinding vulnerabilities and PNA application to iframes.
## Related Tools/Techniques
- Traditional DNS Rebinding
- Singularity (framework utilizing multiple A records)
- Headless Browser Exploitation (Targeting metadata access in environments like EC2)