|
Recent events[1],[2] have shown the threat of domain hijacking is very real; however, it is also largely preventable. As Verisign previously noted[3], 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 reports[1],[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 entity[1],[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 trust[4] 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 TLDs[5] 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 DNSSEC[6] 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-01[7] 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 registries[8], two-factor authentication, password strengthening, and other common security hygiene practices[9] are all best practice security recommendations that Verisign encourages and promotes.
Additional security recommendations are available in the following ICANN SSAC reports:
[1] https://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijacking…
[2] https://www.crowdstrike.com/blog/widespread-dns-hijacking…
[3] http://www.circleid.com/posts/20130722_how_registrants…
[4] https://www.usenix.org/legacy/events/imc05/tec…
[5] https://www.internic.net/domain/root.zone
[6] https://www.verisign.com/en_US/domain-names/dnssec/how-dnssec-works/index.xhtml
[7] https://cyber.dhs.gov/ed/19-01/
[8] https://www.verisign.com/en_US/channel-resources/...
[9] https://www.markmonitor.com/download/checklist/...
[10] https://www.icann.org/en/system/files/files/sac-040-en.pdf
[11] https://www.icann.org/en/system/files/files/sac-044-en.pdf
[12] https://www.icann.org/en/system/files/files/sac-074-en.pdf
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byRadix
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byCSC
Thanks for the reminder on security, Matt.
There’d be much greater adoption of the registry lock solution for .com if Verisign revamped its pricing, as I pointed out in 2013.
In particular, instead of an annual fee per domain name per year (I believe it’s $80+ wholesale cost per year per domain for registrars, who then mark it up for registrants), how about a complete overhaul? In particular, there should be a low one-time fee to enroll a domain in registry lock, but no annual fees to maintain a domain in its locked status. The only costs that would be incurred would be when a domain name is unlocked, as that’s when human involvement for the out-of-band verification is required. Furthermore, that cost for the “unlock” event could be shared by multiple domain names that are unlocked in batches, to further reduce the effective cost per domain name for unlocking (e.g. if the fixed cost for the unlocking event is $20, but 100 domains are unlocked all at once in a single batch by the registrar, perhaps for multiple clients, the cost would still be $20, and not $2000).