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.. . .
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.

 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:  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.