__________________________________________________________

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

[******  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