--- Begin Message ---
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 i...@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.
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
