How prevalent is DNS spoofing? Could a repeat of the Dyn/Mirai DDoS attack have the same results?

Two separate groups of academics have recently released research papers based on research into the Domain Name System (DNS). One has found that the overwhelming majority of popular site operators haven’t learned from the 2016 Dyn/Mirai incident/attack and set up a backup DNS server, and the other has shown that the rate of DNS spoofing, though still very small, has more than doubled in less than seven years.

DNS dependency

Carnegie Mellon University PhD student Aqsa Kashaf and her advisors Dr. Vyas Sekar and Dr. Yuvraj Agarwal have analyzed third party service dependencies in modern web services, with a special focus on DNS, CDN (Content Delivery Network), and SSL certificate revocation checking by CA (Certificate Authority).

Their research was meant to determine if incidents like the 2016 Dyn DDoS attack, the 2016 GlobalSign certificate revocation error and the 2019 Amazon Route 53 DDoS attack would lead to similar results (i.e., a great number of inaccessible sites) in 2020.

They compared the situation with the 100,000 most popular websites in 2020 with that from 2016, and found that 89.2% of the analyzed websites use a third-party DNS provider (instead of managing their own DNS server) and that 84.8% of the websites don’t have a provisioned backup DNS server (which would be used in case their primary DNS provider is temporarily incapacitated).

DNS spoofing

“6% of the top-100K websites that were critically dependent in 2016, have moved to a private DNS in 2020. On the other hand, 10.7% of the websites which used a private DNS in 2016, have moved to a single third party DNS provider. Between these snapshots, redundancy has remained roughly similar. Overall, critical dependency has increased by 4.7% in 2020. More popular websites, however, have decreased their critical dependency,” they noted.

They also found that the DNS ecosystem is heavily concentrated. One DNS provider (CloudFlare) critically serves 23% of the top 100K most popular websites, and three of the top 3 DNS providers (CloudFlare, AWS, GoDaddy) critically serve 38% of the top 100K websites.

One interesting finding is that the overwhelming majority of CloudFlare consumers haven’t provisioned backup DNS servers.

“The near-complete lack of redundancy in CloudFlare’s consumers is because it requires that DNS traffic is routed through the CloudFlare network to protect against DDoS and other attacks. This approach does not allow domains to register a secondary DNS provider,” they explained.

They also found a higher degree of redundancy in the consumers of Dyn, NS1, UltraDNS, and DNSMadeEasy, which may be explained by the fact that these providers encourage the use of secondary DNS provider by giving specific guidelines, and the fact that Dyn and NS1 have previously been victims of large-scale attacks.

Another interesting revelation is the inter-service dependencies (CA to DNS or CDN to DNS).

“72% of the websites are critically dependent on 3 DNS providers when we consider direct CA to DNS dependency as compared to 40% when we just account for website to DNS dependency,” the researchers pointed out. Major CDN providers, on the other hand, use private DNS.

Finally, the researchers have also analyzed third-party DNS dependencies in the top 200 US hospitals and 23 smart home companies, and found that critical dependency is also prevalent in those segments.

DNS spoofing

PhD Candidate Lan Wei and her advisor Dr. John Heidemann at University of Southern California / Information Sciences Institute have studied more than six years of public data about root DNS servers, and found that DNS spoofing occurs globally.

“DNS spoofing is when a third-party responds to a DNS query, allowing them to see and modify the reply. DNS spoofing can be accomplished by proxying, intercepting and mod- ifying traffic (proxying); DNS injection, where responses are returned more quickly than the official servers; or by modifying configurations in end hosts,” they explained.

Depending on the third party that performs it, it can be performed for benign or malicious reasons and can, therefore, be a threat to user’s privacy and security.

“Incorrect DNS responses from third parties have been used for ISPs to inject advertising; by governments to control Internet traffic and enforce government policies about speech or intellectual property; to launch person-in-the-middle attacks by malware; and by apparent nation-state-level actors to hijack content or for espionage.”

Through their research they discovered that DNS spoofing is still rare (occurring only in about 1.7% of observations) but has been increasing during the observed period, and that proxying is the most common DNS spoofing mechanism.

Another interesting finding: there are “overt spoofers” and “covert delayers” – the latter don’t alter the DNS replies, just delay their delivery. As the delays are considerable, it is likely that they are processing the DNS traffic differently, but the reason for this is unknown.

Finally, the researchers noted that DNSSEC can protect against some aspects of DNS spoofing, but it’s still not widely used “because of challenges integrating DNSSEC with DNS-based CDN redirection.”

In early 2019, the Corporation for Assigned Names and Numbers (ICANN) urged domain owners and DNS services to implement DNSSEC as soon as possible.

Vulnerability allows attackers to register malicious lookalikes of legitimate web domains

Cybercriminals were able to register malicious generic top-level domains (gTLDs) and subdomains imitating legitimate, prominent sites due to Verisign and several IaaS services allowing the use of specific characters that look very much like Latin letters, according to Matt Hamilton, principal security researcher at Soluble.

register malicious domains

To demonstrate the danger of these policies, he registered 25+ domains that resemble a variety of popular domains by using a mix of Latin and Unicode Latin IPA homoglyph characters.

“This vulnerability is similar to an IDN Homograph attack and presents all the same risks. An attacker could register a domain or subdomain which appears visually identical to its legitimate counterpart and perform social-engineering or insider attacks against an organization,” he pointed out.

Some homograph domains had already been registered

During this research he also discovered that, since 2017, more than a dozen homograph domains that imitated prominent financial, internet shopping, technology, and other Fortune 100 sites, have had active HTTPS certificates – meaning: they’ve already been registered.

“There is no legitimate or non-fraudulent justification for this activity (excluding the research I conducted for this responsible disclosure),” Hamilton noted, and posited that this technique was used in highly targeted social-engineering campaigns.

He also discovered that Google, for example, also allows the registration of bucket names that use Unicode Latin IPA Extension homoglyph characters. In fact, it also allows the registration of subdomains which contain mixed-scripts (e.g., Latin and Cyrillic characters), which should also be a no-no.

Mitigation and remediation

Hamilton contacted Verisign (which runs the .com and .net domains) and Google, Amazon, Wasabi and DigitalOcean (IaaS providers) in late 2019 and shared his discovery.

Everyone confirmed the receipt of the responsible disclosure report, but only Amazon and Verisign (so far) did something about the problem.

“Safeguarding the stability, security and resiliency of the critical infrastructure we operate is our top priority. While the underlying issue described by Mr. Hamilton is well understood by the global Internet community – and is the subject of active policy development by ICANN – we appreciate him providing additional timely details about how this issue may be exploited,” a Verisign spokesperson noted.

“Although we understand that ICANN has been on a path to address these issues globally, we have also proactively updated our systems and obtained the necessary approval from ICANN to implement the changes to the .com and .net top-level domains required to prevent the specific types of confusable homograph registrations detailed in Mr. Hamilton’s report.

Amazon changed its S3 bucket name validation policy to prevent registration of bucket names beginning with the punycode prefix “xn--”, preventing the use of these and all other Unicode homoglyphs.

Hamilton also pointed out that any TLD which allows Latin IPA characters is likely affected by this vulnerability, but that the majority of the most popular sites on the internet use gTLDs (namely .com).

He advises users who discover that someone has registered a homograph of one of their domains to submit an abuse report to the appropriate organization.

He has also promised to soon make available a tool that will help organizations generate homographs for their domains and discover whether they’ve been registered in the last few years.

Controversial sale of .org domain manager faces review at ICANN

A closeup of the letters

ICANN is reviewing the pending sale of the .org domain manager from a nonprofit to a private equity firm and says it could try to block the transfer.

The .org domain is managed by the Public Internet Registry (PIR), which is a subsidiary of the Internet Society, a nonprofit. The Internet Society is trying to sell PIR to private equity firm Ethos Capital.

ICANN (Internet Corporation for Assigned Names and Numbers) said last week that it sent requests for information to PIR in order to determine whether the transfer should be allowed. “ICANN will thoroughly evaluate the responses, and then ICANN has 30 additional days to provide or withhold its consent to the request,” the organization said.

ICANN, which is also a nonprofit, previously told the Financial Times that it “does not have authority over the proposed acquisition,” making it seem like the sale was practically a done deal. But even that earlier statement gave ICANN some wiggle room. ICANN “said its job was simply to ‘assure the continued operation of the .org domain’—implying that it could only stop the sale if the stability and security of the domain-name infrastructure were at risk,” the Financial Times wrote on November 28.

In its newer statement last week, ICANN noted that the .org registry agreement between PIR and ICANN requires PIR to “obtain ICANN’s prior approval before any transaction that would result in a change of control of the registry operator.”

ICANN can raise “reasonable” objection

The registry agreement lets ICANN request transaction details “including information about the party acquiring control, its ultimate parent entity, and whether they meet the ICANN-adopted registry operator criteria (as well as financial resources, and operational and technical capabilities),” ICANN noted. ICANN’s 30-day review period begins after PIR provides those details.

Per the registry agreement, ICANN said it will apply “a standard of reasonableness” when determining whether to allow the change in control over the .org domain. As Domain Name Wire noted in a news story, whether ICANN can block the transfer using that standard “might ultimately have to be determined by the courts.”

The agreement between PIR and ICANN designates PIR as the registry operator for the .org top-level domain. It says that “neither party may assign any of its rights and obligations under this Agreement without the prior written approval of the other party, which approval will not be unreasonably withheld.”

Concern about price hikes, transparency

The pending sale comes a few months after ICANN approved a contract change that eliminates price caps on .org domain names. The sale has raised concerns that Ethos Capital could impose large price hikes.

ICANN says it wants to make the transaction-review process more transparent. But ICANN apparently needs PIR’s permission to publish the request for information and PIR’s responses, and so far PIR has refused a request to make documents public. In last week’s letter to PIR and the Internet Society, ICANN General Counsel and Secretary John Jeffrey urged PIR to make the information public:

As you are well aware, transparency is a cornerstone of ICANN and how ICANN acts to protect the public interest while performing its role. In light of the level of interest in the recently announced acquisition of PIR, both within the ICANN community and more generally, we continue to believe that it is critical that your Request, and the questions and answers in follow up to the Request, and any other related materials, be made public.

While PIR has previously declined our request to publish the Request, we urge you to reconsider. We also think there would be great value for us to publish the questions that you are asked and your answers to those questions. We will of course provide you with the opportunity to redact portions of the documents that you believe contain personally identifiable information before posting and renew that offer here.

As you, [ISOC CEO] Andrew [Sullivan], stated publicly during a webcast meeting in which you participated on 5 December 2019, you are uncomfortable with the lack of transparency. Many of us watching the communications on this transaction are also uncomfortable.

In sum, we again reiterate our belief that it is imperative that you commit to completing this process in an open and transparent manner, starting with publishing the Request and related material, and allowing us to publish our questions to you, and your full responses.

We contacted PIR today and the organization said it isn’t able to comply with the request to make documents public because of confidentiality agreements. PIR told Ars:

PIR is committed to being transparent with ICANN and the Internet community, and PIR is working to answer ICANN’s questions and address why this acquisition will be good for the .org community. But like any company in the middle of an acquisition, and consistent with other changes of control that have been reviewed by ICANN, we are limited in what we can release publicly due to confidential[it]y agreements with other parties and proprietary information involving the transaction.

PIR defends sale

PIR CEO Jon Nevett defended the pending sale in a blog post last week, calling it “the best path for .org’s future.”

“[A] diversified portfolio is much better, and less risky, than relying on one company like Public Interest Registry—in one industry—for nearly all of its funding,” Nevett wrote.

Under the Internet Society’s ownership, PIR has “been in perpetual ‘harvest’ mode, where PIR sends the fruits of our labor to support the amazing work they do,” Nevett continued. “A relationship with Ethos will allow us to invest in .org, enabling us to deliver more to the .org community, and the Internet at-large.”

But critics of the sale want guarantees in writing that the new owner won’t impose big price increases. ICANN’s Noncommercial Stakeholders Group (NCSG) has called on the ICANN board to require public-interest protections in the sale. For example, the NCSG said that before any wholesale price increases, .org domain registrants should be given “six months to renew their domains for periods of up to 20 years at the pre-existing annual rate.”

Ethos Capital should also have to commit to content neutrality with a pledge that it “will not suspend or take away domains based on their publication of political, cultural, social, ethnic, religious, and personal content, even untrue, offensive, indecent, or unethical material, like that protected under the US First Amendment,” the NCSG said.

If Ethos Capital refuses to make those commitments, ICANN should “exercise its right” from the registry agreement to withhold its approval, the NCSG said.

When contacted by Ars, PIR said that its existing agreement with ICANN “requires that PIR provide notification six months in advance of any price increase” and that “PIR under new ownership will honor the terms of that contract.” However, PIR did not commit to accepting the NCSG proposals.