Disclosure of root zone TSIG keys

[Wessels, Duane]

Dear DNS operations community,

Last week Verisign determined that the transaction signature (TSIG) keys used to authenticate and secure root zone transfers from our zone distribution servers to root server operators were exposed to one or more unauthorized parties. For the explanation behind the disclosure, please refer to Appendix A below.

We believe that the risks to the root zone from this disclosure were low. Zone transfers from Verisign's distribution servers are first protected by whitelist access control lists (ACLs) provided by each operator, and the root zone content is not sensitive.

Nonetheless, upon learning of the disclosure, we notified ICANN and then worked quickly with the root server operators to roll to a new active TSIG key. That work was completed by May 26 and all root operators were confirmed to be using the new key. The urgency for rolling the key across a series of systems and a diverse set of root operators in just a few days rather than weeks / months was in part motivated by a recent BIND TSIG bug, which was seen as heightening the risk of the disclosure, albeit only slightly. More background on the TSIG vulnerability is included in Appendix B below.

If you have questions regarding this disclosure please don’t hesitate to contact us at info at verisign-grs.com

---------------

Appendix A: Background information on recent root TSIG disclosure

On May 20, 2020 security tools alerted Verisign security teams that two internal servers were publicly accessible via a file copy service. Upon investigation our teams identified two additional servers that were also accessible. Altogether, these four servers were used for testing and/or staging functions. We have determined that a failure of network access controls was the root cause and that the scope of exposure involves read-only access to a constrained set of directories via the file copy service on these four servers.

The DNSSEC keying materials for any Verisign managed zones were not impacted by this incident as the impact was limited to testing and staging environments. Verisign signing servers and related infrastructure are operated in accordance with published DNSSEC practice statements and DNSSEC keys are held in FIPs 140-2 level 3+ validated Hardware Security Modules (HSMs) as well as offline cryptographic systems to ensure the integrity of the signed zones operated by Verisign. No Verisign operated TLDs (e.g., COM, NET, etc.), registry operations, or other services were impacted by this incident.

Information contained on the servers did include transaction signature (TSIG) keys used for distribution of the root zone from Verisign’s servers to the root server operators, as well as TSIG keys used by Verisign to retrieve 103 in-addr.arpa child domains from ARIN. Facts related to the incident include:

	• We have concluded the exposure was introduced on August 21, 2019

	• Our analysis has determined that files in the read-only directories, to include the root zone TSIG keys, as well as TSIG keys for in-addr.arpa child zones fetched from ARIN, were accessed by unauthorized parties

	• The accessible service had been legitimately enabled on these servers for use by Verisign teams; the service should not have been internet-accessible

	• The files were legitimately placed on the four servers for testing and/or staging purposes

	• The directories accessible to the service were read-only

	• The operational security stack for the environment was properly functioning and the four servers were properly logging to local and remote facilities at the time of the investigation

	• High frequency internal and external vulnerability scanners were properly identifying the services and archiving the condition but not properly alerting on them; a supplementary security tool alerted internal teams to the issue

	• The systems in these environments are continuously patched and are frequently wiped and rebuilt

	• No personal information was stored on the servers

	• The keys used to fetch the ARIN zones were changed on May 22, and the keys used for root zone distribution were changed over a ~3-day period and completed May 26.

Identified control deficiencies have been corrected to prevent further unauthorized access, alerting has been enhanced and new capabilities have been developed to prevent and/or more quickly detect and alert on any similar incidents going forward.

Current information suggests with a high confidence that no broader internal exposure resulted from the incident (e.g., there were no indications of unauthorized activity beyond access to the read-only directories, there were no indications of system-level compromise, lateral movement, or other subsequent related activities).

There are multiple controls around distribution of the root zone file to root operators and the contents of the root zone file are not sensitive (i.e., are publicly available).

---------------

Appendix B: Background on TSIG’s role in zone distribution

One function of DNS software is to transfer zone data between primary and secondary name servers. This is how the root zone is delivered from Verisign (as Root Zone Maintainer) to the other Root Server Operators. The protocol allows transfers to be protected by a "TSIG key," which is essentially a pre-shared secret. We use ISC's BIND software and TSIG keys for root zone distribution. We also use IP address whitelists to restrict the sources that can communicate with the root zone distribution servers.

On May 19, 2020 ISC disclosed CVE-2020-8617, which describes a bug in how the BIND named software processes TSIG keys. Due to a logic error, a remote attacker can crash the software if the attacker knows, or can guess, the name of a configured TSIG key. 

The risk of CVE-2020-8617 to root zone distribution is low. Our first line of defense is the whitelist access control lists (ACLs). The whitelist entries are limited to small network prefixes assigned to the operators. Packets from any source address not in the whitelist are dropped by a router prior to reaching a distribution server.

Even if an attacker were able to source packets from a whitelisted network, or otherwise bypass the ACLs, the bug from CVE-2020-8617 only causes the name server process to exit, after which it will be restarted automatically by the operating system. It does not allow the attacker to gain access to the system, or to change any content being served.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4695 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200528/affc51b4/attachment.bin>