Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

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:

1. Load the website.
2. Have an A record pointing to the local network and an AAAA (IPv6) pointing to a public website that you control.
3. Chrome will use the IPv6 for the initial request.
4. Shutdown the public server. This will send a reset.
5. 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!