ISS Advisory: BIND Inadvertent Local Exposure of HMAC-MD5 (TSIG) Keys

TO UNSUBSCRIBE: email "unsubscribe alert" in the body of your message to
[email protected] Contact [email protected] for help with any problems!

-----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 [email protected]
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
[email protected] 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-----