Published:
11 June 2001
Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE----- =========================================================================== AUSCERT External Security Bulletin Redistribution ESB-2001.229 -- ISS Security Advisory BIND Inadvertent Local Exposure of HMAC-MD5 (TSIG) Keys 12 June 2001 =========================================================================== AusCERT Security Bulletin Summary --------------------------------- Product: BIND Vendor: ISC Impact: Access Confidential Data Access Required: Local - --------------------------BEGIN INCLUDED TEXT-------------------- - -----BEGIN PGP SIGNED MESSAGE----- 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 <http://www.nominum.com>. 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. - -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv iQCVAwUBOyUd9zRfJiV99eG9AQGJtQP/XC2etFBQMhQT5T9jGfbWyVhsQYl2admO jP64nUwOCoCKgT98N/sskS9sXeSd3bytecO6cpSOtc2Zddj/vsness9gaNw0go2y Q0rOCxgqOJk+hUr1FD7guvX/V+lTgiMaEZVjt78XlvjcOsypRvmt/bflawv6gOkC tp7Rm1UlkA8= =eW5a - -----END PGP SIGNATURE----- - --------------------------END INCLUDED TEXT-------------------- You have received this e-mail bulletin as a result of your organisation's registration with AusCERT. The mailing list you are subscribed to is maintained within your organisation, so if you do not wish to continue receiving these bulletins you should contact your local IT manager. If you do not know who that is, please send an email to auscert@auscert.org.au and we will forward your request to the appropriate person. This security bulletin is provided as a service to AusCERT's members. As AusCERT did not write the document quoted above, AusCERT has had no control over its content. The decision to use any or all of this information is the responsibility of each user or organisation, and should be done so in accordance with site policies and procedures. NOTE: This is only the original release of the security bulletin. It may not be updated when updates to the original are made. If downloading at a later date, it is recommended that the bulletin is retrieved directly from the original authors to ensure that the information is still current. Contact information for the authors of the original document is included in the Security Bulletin above. If you have any questions or need further information, please contact them directly. Previous advisories and external security bulletins can be retrieved from: http://www.auscert.org.au/Information/advisories.html If you believe that your system has been compromised, contact AusCERT or your representative in FIRST (Forum of Incident Response and Security Teams). Internet Email: auscert@auscert.org.au Facsimile: (07) 3365 7031 Telephone: (07) 3365 4417 (International: +61 7 3365 4417) AusCERT personnel answer during Queensland business hours which are GMT+10:00 (AEST). On call after hours for emergencies. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key iQCVAwUBOyYpACh9+71yA2DNAQH6BQP/Smj1wjRcYb6mjZKn3ZzhrNgIWpj9ZRPo +9XV5Kwptx89a0Nfvh0f9Rz0LUBriAfRhVOe+gDEBDb1UAZlMJa9l0Hs759j1oyN 8OYx5XBZbfJL7TCU9DaY7c/4u12ifnmRhje4+Jvn1ms/lQbJY3/mVZEWkLccCiIs VME8B9y9bXQ= =N1AN -----END PGP SIGNATURE-----