by Rik Farrow <rik@spirit.com>
The Domain Name System (DNS) provides a critical service to the Internet--the mapping between names and addresses. DNS also is crucial to the delivery of email. Without DNS, the Internet in its present form might never have existed. And yet, DNS suffers from serious security problems.
The base problem is that DNS, in the form it is currently used, provides no authentication of the name-address mappings it provides. An example of this created a great uproar back in July 1997, when Eugene Kashpureff redirected accesses to Network Solutions' web page to his own site. A solution to this problem had already been under investigation, and RFC 2535 issued in March 1999 to address DNS Security Extensions. When these extensions are properly used, you can trust the information provided by security-aware DNS servers.
Many UNIX systems today are running versions of BIND 8.2, the Berkeley Internet Name Daemon, that support the security extensions. But the extensions are rarely used, as they add unwelcome additional complexity to already obscure DNS records, and require a hierarchy of signing authorities (similar but not that same as a PKI) that does not yet exist. While the security extensions will make the Internet a much safer place for e-commerce, it is in use today.
But the addition of the security extensions has had an unpleasant side-effect. Thousands of UNIX systems are running unpatched BIND 8.2, and include a buffer overflow exploit that can give a remote attacker a root-owned shell. Instead of providing stronger security, a mistake in coding part of the security extensions has turned into one of the most widely exploited holes in UNIX systems today. And, to make matters worse, DNS is often enabled on systems that do not require it, making the existence of this vulnerability even wider spread than it might overwise be. Of course, there are patches for this vulnerability, but, as usual, attackers are more aware of the issue than system administrators.
Bill Manning, of the Information Sciences Institute, has been running quarterly surveys of DNS servers. Using automated software, Manning queries DNS servers for ranges of IP addresses (inverse or in-addr requests), and checks for the correctness of their configuration as well as querying the server type. In the most recent survey, 13% of the DNS servers surveyed were running versions of the BIND software vulnerable to the buffer overflow exploit, numbering in the tens of thousands.
But this is only the tip of the iceberg. Many newer versions of
Linux and UNIX also include the vulnerable version of the BIND
software. When someone installs the operating system, the
default installation often enables named, the BIND server, so that
the server automatically restarts with every reboot. This
server will function to a limited extent, without configuration,
answering queries by
the local system (unless the system includes an /etc/resolv.conf
file that points to another DNS server). And this server, even
though it does not appear as part of the official DNS hierarchy,
can be detected by portscanning for port 53/TCP.
Systems known to be vulnerable to this exploit include versions of Linux, Solaris 7, HP/UX, IBM's AIX. If you are not sure what version of DNS you are running, you can use the 'dig' command, available with most of the listed versions, to request the version and patchlevel of the DNS server. Windows NT servers will not respond to this request, while BIND versions will send back their version number. Versions of BIND before 8.2 and after 8.2 patchlevel 5 (8.2P5) do not have the vulnerability.
The currently exploited vulnerability in BIND is not the first. In 1998, CERT Advisory 14 announced a problem distributed in many releases of Linux with BIND 4.9.6 (the version numbers jump from 4.9.7 to 8.0). Although the same version of BIND appeared in other versions of UNIX, they were not vulnerable because of a difference in the way that BIND was configured by default.
The older vulnerability could be exploited by sending a request to the name server. The request itself included an overly-long name, along with binary code that, if executed, started a new network service connected at the victim's end with a shell running as root. The attacker could then execute commands with the privileges of the root user on the victim's system.
The newer vulnerability takes advantage of buffer overflow in the processing of NXT records, and is often referred to as the NXT record exploit. NXT records are part of the security extensions to DNS, and are pronounced 'next', but stand for 'non-existence' records. The sidebar "Secure DNS" explains a bit more about how NXT records fit in with the other security extensions to DNS.
Your DNS server does not need to have any NXT records to be vulnerable. Instead, the attacker will send you NXT records that include the buffer overflow code that will not only connect the attacker to a root-owned shell, but also break out of a chroot (change root) environment. Paranoid system administrators have taken to running named in a chroot environment, that is, one where the chroot() system call has been used to restrict access to most of the file system (anything above the chroot). But a weakness in the design of chroot permits cleverly written code to escape from this sandbox (the key is finding file descriptors for directories opened before the chroot was executed).
The sample exploit mentioned in the Resources has been modified to make it fail on systems that the attacker does not control. Unmodified, potent, versions of the exploit do exist and are in use today. The proof in this comes from anecdotal evidence, CERT's advisory and summaries, and a mailing list survey that place BIND exploits as the number one vulnerability in use as of June 1, 2000.
CERT's summary goes on to describe what success attackers often do after breaking in using the BIND 8.2 hole. The most common activity is to set up other backdoors that permit easy remote access to the victim as root. This may be done by editing system startup files (found in the /etc/rc.d directories) or by starting a second version of inetd (the Internet daemon) with a configuration file in /tmp. Rootkits, software installations with trojan horses for hiding the attackers presence as well as backdoor code, are often installed as well.
But the most interesting thing that some attackers have done is to patch the vulnerable version of the BIND software. This may, at first glance, appear to be an act of benevolence by a kindly attacker, but do not be fooled. It is done to hide the method of attack, and to make the system inaccessible by other attackers. After all, getting in this way (if you know what you are doing) is so simple, and vulnerable systems so easy to find, that attackers repair the hole so they can exploited systems for themselves, and not have to share them with other, perhaps less skillful, attackers.
There are other problems with version 8.2 BIND, including denial of service attacks that can crash named, or even bring a victim system down by overloading it. For a critical piece of Internet software, this has been a quiet disaster. But with it comes a silver lining, as patches are available.
And the use of firewalls to limit access to known and patched nameservers prevents exploitation of default installations until they can be found, the named disabled, and patched (in case it is ever re-enabled). Both the older and the new buffer overflow exploits rely on the ability to make incoming TCP connections. The BIND exploit uses port 53/TCP for its connections, a port left open by default by some popular firewalls, so just having a firewall is not enough. You must configure it correctly.
You can scan your own networks, using tools like nmap,
and use the dig command
shown in Listing one to identify the version of the DNS
software when you find one listening on port 53.
Commercial scanning tools will also pick up this vulnerability,
as will attack tools written to scan for this specific vulnerability.
Do the Internet community a favor, and patch your systems.
The security extensions to DNS, defined in RFC 2535, add a several new resource records (RRs) to DNS. The SIG RR provides signatures to other named resource records. The signature is done using a private key, and the matching public key can be acquired from a security-aware DNS server by request the KEY RR (short for public key resource record). Individual RRs must be signed, as well as entire or partial zones. The public keys themselves must also be signed by super zones, that is, other DNS servers on the path to the root servers.
The NXT records are used to define exactly which RR's are mapped to a particular name, and are used in answers to requests for non-existent names or record types. For example, if a request for nothing.spirit.com/ was made, and no corresponding entry existed, spirit.com's DNS server should return two NXT records, both signed, that prove that the record for nothing.spirit.com/ does not exist. You can learn more about the DNS security extensions by reading the RFC, or collecting the BIND documentation from the ISC site (see Resources).
The dig command takes the IP address of the target as the first argument; "version.bin chaos txt" requests that the server return its version number. In this example, the version of BIND in use is "4.9.7-REL", an old bu not vulnerable version.
% dig 204.176.22.2 version.bind chaos txt
; <<>> DiG 2.2 <<>> 204.176.22.2 version.bind chaos txt
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; Ques: 1, Ans: 1, Auth: 0, Addit: 0
;; QUESTIONS:
;; version.bind, type = TXT, class = CHAOS
;; ANSWERS:
VERSION.BIND. 0 TXT "4.9.7-REL"
;; Total query time: 2 msec
;; FROM: bear.spirit.com/ to SERVER: default -- 0.0.0.0
;; WHEN: Tue Jan 5 10:04:59 1999
;; MSG SIZE sent: 30 rcvd: 64
Bill Manning's page with the survey of DNS servers: http://www.isi.edu/~bmanning/in-addr-versions.html
Sun's BIND security bulletin for CA-99-14: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=coll&doc=secbull/194&type=0&nav=sec.sba
Patch site for IBM's AIX (4.3 has the vulnerability): http://service.software.ibm.com/support/rs6000
The Internet Software Consortium's page on the security problems with BIND, as well as download links for patched versions: http://www.isc.org/products/BIND/bind-security-19991108.html
Source to an example (defanged) BIND exploit: ftp://ftp.technotronic.com/unix/nameserver-exploits/t666.c
CERT's second quarterly summary placing BIND exploits high on the list of problems reported: http://www.cert.org/summaries/CS-2000-02.html
DNS Security Extensions RFC: http://www.faqs.org/rfcs/rfc2535.html
More information on DNS security extensions: http://www.bovine.net/~jlawson/hmc/dns/security.html