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!

History of DNS Spoofing Vulnerabilities & Patches - 306

Nick Sullivan & Marek Vavruša - CloudflarePosted 5 Years Ago
  • Domain Name System (DNS) is used for determining which domain name (https://google.com) matches which IP address. Who likes to type IP addresses straight into the browser? DNS makes it possible to use domains instead of IPs.
  • Quote from article "Still, the most common transport protocol for message exchange is UDP, which has the advantages of being fast, ubiquitous and requiring no setup. Because UDP is stateless, the pairing of a response to an outstanding query is based on two main factors: the source address and port pair, and information in the DNS message. "
  • The issue is that the sessions are unauthenticated. As long as an attacker knows the IP address & port of the connection, the domain name can be spoofed. However, back when DNS was made, this was thought of; each request has 2 bytes of entropy at the beginning of the message.
  • The first attack is simple, yet works. "...whenever a recursive resolver queried the authoritative name server for a given domain, an attacker would flood the resolver with DNS responses for some or all of the 65 thousand or so possible message IDs". When the DNS server gets this result, this is the expected domain that will now be sent back to the user.
  • What was the fix to this first attack? Port Randomization! By randomizing the port of the request, an attacker did not know WHERE to send the IDs to. This takes the amount of IDs to brute force from 65 thousand to 1 billion (which is infeasible). The next few attacks discussed are about figuring WHICH port something is on to launch the OG attack.
  • The bypass to the port randomization was the fragmentation attack. UDP allows for packets to be broken into multiple fragments. So, an attacker could do the following:
    1. Create a legitimate connection that is fragmented & send the first packet.
    2. In the second packet, CHANGE the ID of the packet. Now, the previous attack works because we can NOW spoof the usage of the previous request. Although, this packet MUST arrive prior to the actual request packet.
    3. Do this over & over again until the proper ID is guessed.
    NOTE: This does not go around the port randomization itself but figures how to use an attackers OWN connection in order to spoof the the ID.
  • The solution to the previous problem (with Cloudflare) was to make a request from MULTIPLE DNS servers at once and check against each other. Although the 65 thousand (2 bytes) can be brute forced on ONE connection, 2 or more connections becomes nearly impossible.
  • I asked myself: "What if you did a port scan in order to know WHICH ports were in use for a query"? That is the idea behind this next attack, but it requires a little bit more intricacy than using nmap. This is done with ICMP error messages & rate limiting.
  • Some background information on ICMP rate limiting. First, if the port is open for ICMP (for a specific IP address) then the rate limit is NOT changed. If the port is NOT open (for the IP address), then the rate limit is increased. Recall, that if we spoof the IP address in the UDP request, we will NOT get the request back.
  • So, what is the problem? The rate limiting can be used as an Oracle to figure out WHICH ports are NOT open! If the rate limit HAS been met, then we know that the spoofed request went through. Otherwise, it did not. Using this, we can figure out which ports are open for the specific IP!
  • Once we know the port open for this IP, we can launch the original DNS spoofing attack again. Cloudflare mitigated this bug by switching a connection over to TCP if port enumeration attempt is done.
  • In this a good solution though? Considering these bypasses have come & gone, there has to be a better solution to this: authenticated DNS. In fact, there is such a thing: DNS over HTTPs (DoH) and DNS over TLS. There IS a solution to the original DNS problem but these other DNS solutions have not been widely adopted yet.