Cloud security researchers from Wiz.io were poking around at Amazon Web Services' Route53 Domain Name Service (DNS) earlier this year when they suddenly realized that its self-service domain registration system let them set up a new hosted zone with the same name as the real AWS name server it was using. Within seconds, they watched in shock as their phony name server got flooded with DNS queries from other AWS customers' networks: external and internal IP addresses, computer names for finance, human resources, production servers, and organization names.

All told, they got traffic from more than 15,000 different AWS customers and a million endpoint devices, all after registering a phony AWS name server as ns-852.awsdns-42.net, the same name as an actual AWS name server.

"We were trying figure out how break DNS and we had no idea what traffic we were getting" at first, says Ami Luttwak, co-founder and CTO of Wiz.io as well as a former member of Microsoft's cloud security team. "In theory, if you register a name server name ... it shouldn't have any impact."

DNS services such as AWS Route53 let customers update their domain name and the name server to which their domains point for DNS queries. The researchers say they just created a new hosted zone inside ns-852.awsdns-42.net with the same moniker and pointed it to their IP address. Then they received DNS queries from Route53 customers' devices to their rogue and same-named server.

The researchers were able to use that traffic to gather a treasure trove of information on Fortune 500 firms including a commodities-trading firm, 45 US government agencies, and 85 government agencies overseas. They gleaned from that traffic data details such as the physical locations of offices and employees at some of the organizations. "We understood then that we were on top of an unbelievable set of intelligence, just by tapping for a few hours into a small portion of the network," Luttwak says. "I called it a nation-state intelligence capability using a simple domain registration."

The researchers were, for instance, able to use the DNS query data to drill down into office locations and numbers of employees at the trading firm as well as that of a large credit union subsidiary with a branch office in Iran, and other organizations.

AWS fixed the hole in mid-February, shortly after the researchers alerted it back in January, but at least two other providers the researchers contacted about the flaw have not yet fixed it in their DNS services. An AWS spokesperson did not provide any details but confirmed that Route53 "is not affected by this issue," adding that the service "prevents the creation of Hosted Zones for DNS names associated to Route53 name servers."

All it took to close the vulnerability in AWS Route53 was placing the official AWS name-server name on a so-called "ignore" list, explains Shir Tamari, head of Wiz.io's security research team. "The problem was anyone could register the official name servers on the platform, so they put the list of their name servers on an 'ignore' list so" attackers can't register them anymore.

"It was a very quick and efficient fix," Tamari adds.

Two other DNS-as-a-service providers harbor the vulnerability - which is basically an implementation flaw, according to the researchers. The Wiz.io team has alerted the affected vendors but would not disclose their names since the issues have not yet been fixed. Luttwak and Tamari will present their findings in August at Black Hat USA in Las Vegas.

"O.G." DNS Meets DNSaaS
The attack takes advantage of a gray area in the DNS infrastructure: an unintended and unexpected consequence of the combination of traditional, old-school DNS technology on some Windows machines and today's cloud DNS service features. Traditional DNS client software is old — some of which was written 20 years ago — and not built for cloud-based enterprise infrastructures, but instead for trusted internal enterprise domains.

Endpoints reveal sensitive information when they query the DNS server, the researchers say, and much of this is a result of the complexity of DNS itself. "DNS clients perform non-standard queries, and DNS providers allow customers to enter their own DNS zones in their server," which creates a risky combination, Luttwak says. The clients reveal details via their Dynamic DNS updates that would be fine in an internal DNS infrastructure environment but when operating within a cloud-based DNS service could leak to other customers of that service provider.

"So, when an endpoint working from home … is no longer using an [internal] DNS resolver and is accessing the network from their DNS server," it updated the researchers' rogue name server instead of its own, he explains. "It's a combination of the new world where you are able to do registration of shared domains, and in all of the algorithms put into Windows 20 years ago that [use] logic built for when there was no Internet problem — that wasn't for shared DNS servers. So, the endpoints register their locations with the" cloud-based name servers, he says.

There's also the IPv6 factor: The researchers found some devices using the newer version of the Internet Protocol (IP) were exposed and thus accessible to an attacker. "Out of the millions of endpoints that sent us Dynamic DNS data, we noticed that internal IPv6 endpoints are accessible," notes Tamari. For that reason, users working from home or outside the office and running on IPv6 risk exposing their devices to the Internet.

Tamari says the researchers found that some 6% of IPv6 devices are exposed via HTTP, RDP (Remote Desktop Protocol), and SMB, for example.

The researchers say they can't confirm whether any attackers have employed this weakness in the DNS, but they are sounding the alarm that it could also exist in other DNS providers' services. "It's important for all DNS providers" to ensure they're not leaving their customers exposed via this vulnerable DNS setup, Luttwak says.

The vuln is different from other flaws the research team has seen in cloud services. It's not a classic software bug: "The logic flows lead to unexpected results," he says. "They are hard to find, these new types of vulnerabilities. It's in the logic of how you build the [DNS] service."

DNS providers should use the DNS RFC's specifications for reserved domain names, validate domains, and verify ownership of domains, the researchers note.

Defending Your DNS
Organizations also have options for protecting their DNS traffic from DNS hijacking: "There are specific things organizations can do to ensure that DynamicDNS doesn't go to a malicious server," Tamari says, such as firewalls, and tools that monitor DNS traffic to and from endpoints.