A Security Loophole to Intercept Dynamic DNS Traffic
Whenever you run into a network problem, the wise network admin or sysadmin always remembers “It’s always DNS [Domain Name Service].” Because, well, it often is DNS.
So, we should be surprised when at the Black Hat USA 2021 security conference cloud security firm Wiz Chief Technology Officer Ami Luttwak and head of research Shir Tamari discovered a simple loophole that allowed them to intercept dynamic DNS (DDNS) traffic going through managed DNS providers like Amazon and Google.
And, yes, that includes the DDNS you’re using on your cloud. And, if you think that’s bad, just wait until you see just how trivial this attack is.
Our intrepid researchers found that “simply registering certain ‘special’ domains, specifically the name of the name server itself, has unexpected consequences on all other customers using the name server. It breaks the isolation between tenants. We successfully registered one type of special domain, but we suspect there are many others.”
In other words, by registering a duplicate domain server name, they broke the isolation between DNS tenants. This means, for those of you who haven’t suffered from fixing endless DNS problems, you get control of the hosted zone. This means you can steer DNS traffic to your IP address. So, “whenever a DNS client queries this name server about itself (which thousands of devices do automatically to update their IP address within their managed network — more on that in a minute), that traffic goes directly to our IP address.”
To be precise, all they did was register a new domain on the Amazon Web Services (AWS)’ Route 53 cloud DNS service platform with the same name as Route 53’s official DNS server. Technically, they created a new “hosted zone” inside AWS name server ns-1611.awsdns-09.co.uk and named it “ns-852.awsdns-42.net. AWS Route 53 has around 2,000 DNS servers that are used and shared among all their customers, any of them could have been targeted. This is such a trivial attack that I’m not even sure I could call it a hack.
This isn’t just a Route 53 problem. They found that other managed DNS providers, such as Google Cloud DNS and Akamai were also vulnerable. Combine this with the rise in remote work, and all kinds of fun new holes can be found “in the fabric of this decades-old protocol designed for a world where employees and servers were all ‘on-prem.'”
I’d disagree with the last, DNS was never designed for an on-premises world. For better or worse, though, many DNS implementations treat it as if the services were on-premises and secure behind the corporate firewall. As you all know, it’s been a long, long time since that was a safe, or even sane, assumption.
Because of this, the researchers gained partial control of the hosted DNS zone. So, when they point DNS queries to their IP address, whenever a DNS client queries this name server about itself, which thousands of devices do automatically to update their IP address within their managed network, that traffic goes directly to their IP address. Remember what I said about trusting the DNS server as if you controlled it? There you go.
The theory was that DNS hosts provide an easy-to-use, self-service platform that enables users to make updates to their domain name and what name servers it points to. Customers can add any domain name they want. For instance, you could even claim google.com or I.have.the.best.website.com) because these domain names aren’t registered outside their zone and never make it to the authoritative domain registries. This relies on “The basic assumption is that there is full isolation between you and other customers. Route53 doesn’t verify that I own amazon.com because nothing that I register on my DNS is supposed to have any impact on other customers.”
Oh well, it’s a lovely idea, but it’s not true. Once they duplicated a DNS registry name, they suddenly got slammed by millions of DNS queries. So what, you may be thinking? How big a deal is it to know that someone at some company was — horrors! — checking into pornhub.com instead of their worksite?
Well, if that was all, it still is noteworthy, but not too damaging. Alas, that’s not the case. It turns out Windows machines make frequent DDNS queries about their own IP address. And, since they assume they’re working with a safe internal network they send along far more than just their internal IP address. Oh no, they also include much more valuable intel such as internal and external IP addresses, computer names, employee names, and office locations.
No one it seems had a clue that could happen. The researchers were able to use their DDNS wiretaps to listen to more than 15,000 organizations. That included Fortune 500 companies, 45 U.S. government agencies, and 85 international government agencies. Want to know, for example, how many employees your competitor has in San Francisco and what systems they’re running? No problem!
Microsoft could fix this problem, but they have chosen not to. Wiz states that “when we reported our discovery to Microsoft, they told us that they did not consider it a vulnerability but rather a known misconfiguration that occurs when an organization works with external DNS resolvers.”
Right. Sure.
In all fairness, this is one of those problems that fall into a gray area. Who should be responsible for fixing it? Microsoft? Microsoft? Managed DNS services? Your company?
The DDNS service providers, fortunately, have picked up a security clue. AWS and Google have fixed it. Others, however, may not. And as Wiz points out “Ultimately, customers are responsible for configuring their DNS resolvers properly so dynamic DNS updates do not leave the internal network.”
You should be asking by now, “Am I vulnerable?” To find out use Wiz’s Dynamic DNS Leakage Tester. I’m lucky enough that my sites and servers weren’t vulnerable. You might not be so lucky. Check now and if you’re open to attack. If you are, get to work on it. Wiz is happy to help via a special e-mail address or you can join their slack group.
