__________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Center ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ INFORMATION BULLETIN BIND Inadvertent Local Exposure of HMAC-MD5 (TSIG) Keys [Unix/Linux Systems] June 12, 2001 17:00 GMT Number L-094 ______________________________________________________________________________ PROBLEM: Keys generated by the dnskeygen utility and the dnssec-keygen utility have an access control vulnerability in one of two files. This vulnerability only exists for systems performing dynamic updates using HMAC-MD5 keys. PLATFORM: All versions of BIND with dnskeygen, up to and including BIND 8.2.4. All versions of BIND with dnssec-keygen, up to and including BIND 9.1.2. This flaw only affects sites that use Dynamic DNS updates with HMAC-MD5 keys and does not affect any sites that only use static zone files (the majority of BIND installations). Sites that perform dynamic DNS updates from otherwise secured systems (such as a dedicated DHCP server having no common users) are not affected by this flaw. DAMAGE: A malicious party accessing the vulnerable key file may cause unintended updates to a DNS server. The keying material for DNS updates is also vulnerable to retrieval. The integrity of the DNS server is placed at risk. SOLUTION: Review the advisory and perform necessary upgrading and file checking, as specified. ______________________________________________________________________________ VULNERABILITY The risk is LOW. There have been no reported exploits of this ASSESSMENT: vulnerability. This vulnerability does not exist for those sites using static zone files, or sites that perform dynamic updates from other secured servers. ______________________________________________________________________________ [****** Begin ISS Bulletin ******] Internet Security Systems Security Advisory June 11, 2001 BIND Inadvertent Local Exposure of HMAC-MD5 (TSIG) Keys Synopsis: A flaw exists in the dnskeygen utility under BIND version 8 and the dnssec-keygen utility included with BIND version 9. The keys generated by these utilities are stored in two files. In the case of HMAC-MD5 shared secret keys that are used for dynamic updates to DNS servers, the same secret keying material is present in both files. Only one of the files is configured by default with strong access control. The resulting exposure may allow unauthorized local users to obtain the keying information. This may allow attackers to update DNS servers that support dynamic DNS updates. Description: Keys for DNS Transactional Signatures (TSIG) are generated by the dnskeygen utility under BIND version 8 or the dnssec-keygen utility under BIND version 9. The keys generated are stored in two files based on the key name and key type. These keys are "shared secret" keys for the HMAC-MD5 algorithm and are sensitive keying material that must be kept confidential. Sensitive keying information generated for TSIG and Dynamic DNS is stored in both key files, as well as all keying information necessary to make dynamic updates to the DNS server. Versions affected: All versions of BIND with dnskeygen, up to and including BIND 8.2.4. All versions of BIND with dnssec-keygen, up to and including BIND 9.1.2. This flaw only affects sites that use Dynamic DNS updates with HMAC-MD5 keys and does not affect any sites that only use static zone files (the majority of BIND installations). Sites that perform dynamic DNS updates from otherwise secured systems (such as a dedicated DHCP server having no common users) are not affected by this flaw. Recommendations: BIND 9 users should upgrade to BIND 9.1.3rc1 or higher. BIND 8.3 is scheduled to be available sometime in the July 2001 timeframe. Until BIND 8.3 is released, BIND 8 users should refer to the workarounds described below. BIND administrators should inspect all keys for correct file permissions after upgrading BIND. If a system is permitted to issue dynamic DNS updates to a master DNS server and access is authenticated using HMAC-MD5 signed TSIG signatures, check permissions on all "*.key" and "*.private" files used for TSIG purposes. If unauthorized users can access these files, the potential for compromise of the keying material and unauthorized updates to the DNS servers exists. The following two commands will reveal relevant key files that may contain sensitive keying data. find / -name 'K*.+157+[0-9][0-9][0-9][0-9][0-9].key' -perm +066 find / -name 'K*.+157+[0-9][0-9][0-9][0-9][0-9].private' -perm +066 If run as "root" or another superuser account, these commands may reveal files that are otherwise protected by directory, path, or ACL permissions. Change permissions on all existing dnssec .key files and .private files to mode 600 or stronger. Create dnssec keys only in directories that have permissions and ownership configured to deny unauthorized access to the keying material. Set umask to 066 before running dnssec-keygen or dnskeygen. Files will then be created with permission 600 or stronger. If there is any chance that keys have already been exposed or compromised, generate new keys with stronger storage permissions. Additional Information: Note: References to the ARM are to the BIND Version 9 Administrators Reference Manual (Bv9ARM) and pages numbers related to the pdf formatted version of the document available from Nominum at . When used for TSIG purposes, HMAC-MD5 keys are often used to control authorization in dynamic DNS zone updates. - From the ARM section 7.3 p78: "...we strongly recommend that updates be cryptographically authenticated by means of transaction signatures (TSIG). That is, the allow-update option should list only TSIG key names, not IP addresses or network prefixes." Following the procedures described in section 4.4.1 "Generate Shared Keys for Each Pair of Hosts" in the ARM results in two key files, "K${name}.+aaa+iiii.key" and "K${name}.+aaa+iiii.private" where "${name}" is the specified key "name", aaa is a numerical indicator of the key type (157 for HMAC-MD5) and iiiii is a five digit number identifying the key. The ".private" file of the pair has ownership mode 600 (Owner - r/w, Group - none, Other - none) while the .key file of the pair has ownership mode 664 (Owner - r/w, Group - r/w, Other r/o). In the case of HMAC-MD5 keys, the "private" information in the .private file is also present in the .key file, making sensitive keying material readable by any user on the system, if not protected by directory permissions or other access controls. The "*.private" file contains the HMAC-MD5 key stream, which is normally copied, in a secure manner, to the DNS server and acts as the shared secret by which message integrity and authorization is determined. It is recommended that any file, on the destination server, containing this key be non-world readable. - From ARM section 4.4.3, "Informing the Servers of the Key's Existence" p20: "Since this is a secret, it is recommended that either named.conf be non-world readable, or the key directive be added to a non-world readable file that is included by named.conf." The "*.key" file, which has weaker file permissions, also contains the sensitive keying material which is contained in the "*.private" file. In fact, there is no information in the "*.private" file that is not contained in the "*.key" file. This possibly exposes the sensitive keying material to any user on the system. That user will then be able to use that key to perform nsupdates from that, or other, systems. - From the man page on "nsupdate": "nsupdate uses the -y or -k option to provide the shared secret needed to generate a TSIG record for authenticating Dynamic DNS update requests. These options are mutually exclusive. With the -k option, nsupdate reads the shared secret from the file keyfile, whose name is of the form K{name}.+157.+{random}.private. For historical reasons, the file K{name}.+157.+{random}.key must also be present." The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2001-0497 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. Summary: If HMAC-MD5 keys are used to control access to dynamic DNS updates, the potential exists for sensitive keying information to be read by unauthorized users. Once exposed, these users then have the ability to update DNS information in the servers, leading to further compromise. If HMAC-MD5 keys are only relied on for message integrity on the wire or are only stored on systems that are not accessed by users who would be restricted from access to such keying material (such as an autonomous DHCP server), this problem may not be serious. If HMAC-MD5 keys are used to control authentication from servers and those servers have users who are not intended to be granted authorization to perform dynamic DNS updates, this problem can be serious. Unauthorized dynamic DNS updates may result in DNS poisoning or corruption, which can lead to further compromise of related systems. TSIG and HMAC-MD5 keys are used for more than Dynamic DNS. All uses of TSIG and HMAC-MD5 keys may be compromised by this exposure. Credits: ISS X-Force would like to thank Paul Vixie of ISC and Brian Wellington of Nominum. This advisory was primarily researched by Michael H. Warfield of the ISS X-Force. ______ About Internet Security Systems (ISS) Internet Security Systems is the leading global provider of security management solutions for the Internet, protecting digital assets and ensuring safe and uninterrupted e-business. With its industry-leading intrusion detection and vulnerability assessment, remote managed security services, and strategic consulting and education offerings, ISS is a trusted security provider to more than 8,000 customers worldwide including 21 of the 25 largest U.S. commercial banks and the top 10 U.S. telecommunications companies. Founded in 1994, ISS is headquartered in Atlanta, GA, with additional offices throughout North America and international operations in Asia, Australia, Europe, Latin America and the Middle East. For more information, visit the Internet Security Systems web site at www.iss.net or call 888-901-7477. Copyright (c) 2001 Internet Security Systems, Inc. Permission is hereby granted for the redistribution of this Alert electronically. It is not to be edited in any way without express consent of the X-Force. If you wish to reprint the whole or any part of this Alert in any other medium excluding electronic medium, please e-mail xforce@iss.net for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. X-Force PGP Key available at: http://xforce.iss.net/sensitive.php as well as on MIT's PGP key server and PGP.com's key server. Please send suggestions, updates, and comments to: X-Force xforce@iss.net of Internet Security Systems, Inc. [****** End ISS Bulletin ******] _______________________________________________________________________________ CIAC wishes to acknowledge the contributions of Internet Security Systems, Inc. for the information contained in this bulletin. _______________________________________________________________________________ CIAC, the Computer Incident Advisory Center, is the computer security incident response team for the U.S. Department of Energy (DOE) and the emergency backup response team for the National Institutes of Health (NIH). CIAC is located at the Lawrence Livermore National Laboratory in Livermore, California. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. CIAC services are available to DOE, DOE contractors, and the NIH. CIAC can be contacted at: Voice: +1 925-422-8193 (7x24) FAX: +1 925-423-8002 STU-III: +1 925-423-2604 E-mail: ciac@ciac.org Previous CIAC notices, anti-virus software, and other information are available from the CIAC Computer Security Archive. World Wide Web: http://www.ciac.org/ Anonymous FTP: ftp.ciac.org PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained via WWW at http://www.first.org/. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC) L-084: Red Hat Samba Package /tmp Race Condition L-085: Cisco Content Service Switch FTP Vulnerability L-086: Cisco Multiple Vulnerabilities in CBOS L-087: Microsoft Internet Explorer Flaws in Certificate Validation L-088: Cisco IOS Reload after Scanning Vulnerability L-089: Windows Unchecked Buffer in Media Player .ASX Processor L-090: Cisco 11000 Series Switch, Web Management Vulnerability L-091: Microsoft Exchange Server Outlook Web Access Flaw L-092: Microsoft Predictable Name Pipes In Telnet L-093: HP-UX kmmodreg Vulnerability