Bypassing PNA and SOP: Exploiting Cloud Metadata Services via DNS Rebinding

TLDR: Modern browser security controls like Private Network Access (PNA) and Same-Origin Policy (SOP) are designed to prevent unauthorized access to internal network services. This research demonstrates that by manipulating DNS A and AAAA records, attackers can force browsers to prioritize public IP addresses before switching to private ones, effectively bypassing these protections. This technique allows for the exfiltration of sensitive data from cloud metadata services and internal web applications, and the provided dns-delay-server tool makes reproducing these attacks straightforward.

Browser security is often treated as a solved problem by developers, but the reality is that the boundary between the public internet and internal networks is thinner than most realize. When you are running a headless browser in a cloud environment, you are essentially placing a powerful, automated agent inside your own perimeter. If that agent can be tricked into interacting with internal services, the entire concept of a secure internal network starts to crumble. The research presented at Black Hat 2023 on split-second DNS rebinding is a masterclass in how subtle timing differences and DNS record manipulation can turn a standard browser into an internal reconnaissance tool.

The Mechanics of the Rebind

DNS rebinding is not a new concept, but its application against modern browser security features like Private Network Access (PNA) is where the real danger lies. At its core, the attack relies on the browser's willingness to trust the DNS resolution process. An attacker controls a domain, such as evil.com, and sets up a malicious DNS server. When the victim's browser requests the IP address for evil.com, the server returns a public IP address that points to an attacker-controlled web server.

The browser loads the initial page from this public IP, which contains malicious JavaScript. This script then performs a series of requests to the same domain. Because the browser caches the DNS response, it assumes the domain still resolves to the public IP. However, if the attacker's DNS server is configured to return a short Time-to-Live (TTL) or simply cycle through records, the next request will trigger a new DNS lookup. This time, the server returns a private IP address, such as 169.254.169.254, which is the standard endpoint for AWS EC2 metadata services.

The browser, believing it is still talking to the same origin, allows the request to proceed. This is the critical failure point. The Same-Origin Policy (SOP) is bypassed because the browser thinks the internal service is the same entity as the malicious public site.

Forcing the Switch with A and AAAA Records

The most interesting part of this research is how the attacker forces the browser to switch from a public to a private IP address reliably. While traditional rebinding relies on waiting for a cache to expire, modern browsers are smarter. They often perform parallel lookups for both A (IPv4) and AAAA (IPv6) records.

By returning an A record for a public IP and a AAAA record for a private IP, or vice versa, an attacker can influence the browser's connection logic. Chrome and other Chromium-based browsers prioritize IPv6 over IPv4. If you provide a public IPv6 address and a private IPv4 address, the browser will attempt to connect to the public one first. If the attacker's web server then resets the connection, the browser will fall back to the next available address in its list—the private IPv4 address.

This is the "split-second" part of the attack. You are not just waiting for a cache to clear; you are actively manipulating the browser's connection stack to force it into the internal network.

Practical Exploitation on Engagements

For a pentester, this is a high-impact finding. If you are testing an application that allows users to input URLs for screenshots, PDF generation, or web scraping, you are likely looking at an SSRF vector. If that application runs on a cloud instance, it is almost certainly sitting next to a metadata service containing IAM credentials.

During an engagement, you can use the dns-delay-server to automate this process. The tool is designed to serve static files until it receives a request to a specific endpoint, at which point it resets the connection. This forces the browser to re-resolve the domain, allowing you to swap the IP address mid-flight.

The impact is not limited to metadata services. Any internal service that does not check the Host header—a common misconfiguration—is a potential target. You can use this technique to probe internal APIs, administrative interfaces, or even internal databases that are not exposed to the public internet.

Defensive Considerations

Defending against this requires a defense-in-depth approach. First, ensure that your cloud instances are using IMDSv2, which requires a session-oriented token for metadata requests. This effectively kills the simplest form of SSRF because an attacker cannot easily obtain the token via a standard GET request.

Second, implement network-level restrictions. Your web workers or headless browsers should not have network access to internal segments unless absolutely necessary. If they must access internal resources, use a dedicated proxy that enforces strict allow-lists for domains and IP ranges. Finally, ensure that your internal services are not just relying on network-level security; they should validate the Host header and implement proper authentication, even for requests originating from within the local network.

DNS rebinding remains a potent threat because it exploits the fundamental trust browsers place in the DNS protocol. As long as browsers continue to prioritize performance and connectivity, there will be opportunities to manipulate their behavior. Keep your metadata services locked down and your internal network segments isolated.