March 22, 2019 saw the completion of the final important step in the Key Signing Key (KSK) rollover – a process which began about a year and half ago. What may be less well known is that post rollover, and until just a couple days ago, Verisign was receiving a dramatically increasing number of root DNSKEY queries, to the tune of 75 times higher than previously observed, and accounting for ~7 percent of all transactions at the root servers we operate.(more…)
Recent events1,2 have shown the threat of domain hijacking is very real; however, it is also largely
preventable. As Verisign previously noted3,
there are many security controls that registrants can utilize to help
strengthen their security posture. Verisign would like to reiterate this advice
within the context of the recent domain hijacking reports.
Domains are an important element of internet infrastructure; their functionality and security rely upon many factors such as their delegated name servers. Name server delegations introduce complex and subtle inter-dependencies between domains and their authoritative name servers. Compromise of any name server in the delegation hierarchy can lead to a potential hijacking scenario. Targeted name server compromises in the delegation hierarchy can facilitate a complete hijack of a domain or set of domains, while name server compromises deeper in the delegation hierarchy may result in partial hijacking, since not all name servers in the hierarchy are involved in every DNS resolution request. A compromised name server is capable of diverting DNS requests to malicious servers controlled by threat actors and can be weaponized for phishing attacks or other nefarious purposes.
Over the past several weeks, security professionals have issued reports1, 2 about the hijacking of various domains via their name server delegations. These changes were likely made using compromised registrar credentials and are believed to be backed by a foreign nation state entity1, 2. During the attacks, the threat actors used the traffic directed to their infrastructure to launch spear phishing campaigns against various government entities in northern Africa and the Middle East. These targeted spear phishing attempts were facilitated by the transitive trust4 placed on the compromised domains and their delegated name servers.
Several of the compromised domains contained hosts that were specified as name servers for numerous top-level domains (TLDs) including country code TLDs5 in the northern African and Middle East regions. Subsequently, DNS traffic resolution for corresponding reliant zones were partially/completely routed to the threat actors’ infrastructure. This redirection of DNS traffic facilitated their ability to target specific government and industry entities in the targeted countries. While the domains did not employ a domain locking tool, some were DNSSEC6 signed, which helped mitigate the attack for resolving parties that perform validation.
As part of the response to this incident, the Department of Homeland Security issued Emergency Directive 19-017 requiring federal civilian agencies to address the risks presented by this activity. The order mandated four actions to be taken: 1) Audit DNS records, 2) Change DNS account passwords, 3) Add multi-factor authentication to DNS accounts and 4) Monitor Certificate Transparency logs.
Verisign is engaged with various industry and government entities regarding this incident and has provided technical insights into the DNS ecosystem regarding the complex mechanisms and system-to-system interactions/dependencies involved. To date, there is no evidence that the scope of compromise extends beyond the sets of credentials at various registrars.
Verisign encourages registrants to research their registrar’s security offerings and to take advantage of the tools and services they offer. Techniques such as locking services offered by registrars and registries8, two-factor authentication, password strengthening, and other common security hygiene practices9 are all best practice security recommendations that Verisign encourages and promotes.
Additional security recommendations are available in the following ICANN SSAC reports:
- SAC04010: “Measures to Protect Domain Name Registration Service Against Exploitation or Misuse”
- SAC04411: “A Registrant’s Guide to Protecting Domain Name Registration Accounts”
- SAC07412: “Best Practices for Preserving Security and Stability in the Credential Management Lifecycle”
Currently scheduled for October 11, 2018, the Internet Corporation for Assigned Names and Numbers (ICANN) plans to change the cryptographic key that helps to secure the internet’s Domain Name System (DNS) by performing a Root Zone Domain Name System Security Extensions (DNSSEC) key signing key (KSK) rollover.
The National Telecommunications and Information Administration’s (NTIA) March 14, 2014, announcement proposing the transition of its legacy Internet Assigned Numbers Authority (IANA) stewardship role has presented the Internet Corporation for Assigned Names and Numbers (ICANN) multi-stakeholder community equal amounts of opportunity and responsibility. We have been handed a singular opportunity to define the terms of any stewardship transition and the fundamental responsibility to get it right.
Getting it right means ensuring, through a bottom-up, multi-stakeholder process, the reform of ICANN’s accountability structures to protect the community and the multi-stakeholder model prior to NTIA’s disengagement from its oversight and stewardship role. It also means acting quickly and efficiently so our window of opportunity is not missed.
Verisign posted preliminary public comments on the “Mitigating the Risk of DNS Namespace Collisions” Phase One Report released by ICANN earlier this month. JAS Global Advisors, authors of the report contracted by ICANN, have done solid work putting together a set of recommendations to address the name collisions problem, which is not an easy one, given the uncertainty for how installed systems actually interact with the global DNS. However, there is still much work to be done.
On Dec. 12, 2013, the Internet Engineering Steering Group (IESG) announced the formation of a new working group, Extensible Provisioning Protocol Extensions (eppext). The working group was formed to create an internet Assigned Numbers Authority (IANA) registry of Extensible Provisioning Protocol (EPP) extensions and to review specifications of extensions for inclusion in the registry. EPP is the standard domain name provisioning protocol for generic top-level domain (gTLD) name registries that operate under the auspices of the Internet Corporation for Assigned Names and Numbers (ICANN). It is also used by a number of country code top-level domain (ccTLD) registries.
The “E” in EPP has been both a blessing and a curse. EPP uses features of the Extensible Markup Language (XML) that provide “hooks” for protocol extensions. These hooks make it easy to specify new functionality without having to modify EPP itself. That’s the blessing. The curse has been that easy extensibility has led to multiple independent specifications that describe similar functionality. In a 2010 presentation, Patrick Mevzek (developer of the Net::DRI Perl library that implements EPP) described XML namespaces used in 68 distinct extensions. He further described three different extensions created by different registry operators to provide domain “undelete” functionality. This duplicity of effort makes implementation much more complicated for anyone developing EPP clients.
Some background information will help explain how we got here.
As much as the world has become more connected, so that people across the world can collaborate online at any hour of the day (even in the midst of weather events like Sandy), there’s still an important role for conferences that bring people together in person at a specific time and place.
I’ve been reminded of the value of this technical “networking” as I’ve attended some key events related to my own work in recent weeks.
In mid-October, I spent some time at the ICANN 45 meeting in Toronto, the triannual focal point for industry work on domain names (as well as IP “numbers”, the second “N”). Pat Kane, senior vice president and general manager of Verisign’s Naming Services, describes his experiences at this important series as exemplifying “hard work and collaboration.” Good technical consensus, as I’ve learned through my past years in industry forums in cryptography and security, starts with trust. The many introductions and conversations that I enjoyed throughout my visit built on this value.