The CERT Coordination Center publishes incident notes to provide
information about incidents to the Internet community.
<h2>Exploitation of BIND Vulnerabilities</h2>
Date: Friday, March 30, 2001<p>
On January 29, 2001 the CERT/CC published <a href="/advisories/CA-2001-02.html">CERT Advisory CA-2001-02</a>
detailing multiple vulnerabilities in multiple versions of ISC BIND
nameserver software. Two of the vulnerabilities described in the
advisory are now actively being exploited by the intruder community
to compromise systems. In particular, these vulnerabilities are
being exploited:
<p>
<dl>
<dd><a href="http://www.kb.cert.org/vuls/id/325431">VU#325431</a> -
Queries to ISC BIND servers may disclose environment variables</dd>
<dd><a href="http://www.kb.cert.org/vuls/id/196945">VU#196945</a> -
ISC BIND 8 contains buffer overflow in transaction signature (TSIG) handling code</dd>
</dl>
<p>
Multiple exploits exist for multiple operating system platforms, and we
have seen several versions of packaged kits containing exploits used
by intruders to automate the process of scanning for and compromising
vulnerable systems. At least one known toolkit employs worm-like
techniques designed to cause the attack cycle to self-initiate on a
compromised host, which can result in the attack propagating across
multiple hosts and networks without intruder interaction. To date,
reports to the CERT/CC indicate that successful exploitation has
involved hosts running Linux.
<p>
<h3>Attack Profile</h3>
<p>
In exploitations seen by the CERT/CC, the two vulnerabilities in ISC
BIND are used in conjunction with each other during a single attack to
compromise a target host.
<p>
The exploits we have seen have the following traffic pattern:
<pre>
attacker:port -> victim:53 TCP SYN
victim:53 -> attacker:port TCP SYN ACK
attacker:port -> victim:53 TCP ACK (TCP session established)
attacker:port -> victim:53 UDP DNS inverse query request
</pre>
<p>
The exploit opens a TCP connection to port 53 on the victim host and
then sends a specially formed DNS inverse query packet to the target
via UDP. The inverse query packet is an exploit of the BIND
information leak vulnerability (
<a href="http://www.kb.cert.org/vuls/id/325431">VU#325431</a>)
described in
<a href="/advisories/CA-2001-02.html">CERT Advisory CA-2001-02</a>.
The nameserver response may vary depending on the configuration of the
nameserver and the influence of access control mechanisms. In most cases, we
have seen a response in a single UDP packet back to the source
indicating a format error in the inverse query.
<p>
<pre>
victim:53 -> attacker:port UDP DNS inverse query format error
</pre>
<p>
The goal of exploiting the information leak vulnerability is to gain
information to enable an exploit attempt against the BIND TSIG
vulnerability (
<a href="http://www.kb.cert.org/vuls/id/196945">VU#196945</a>)
described in
<a href="/advisories/CA-2001-02.html">CERT Advisory CA-2001-02</a>.
<p>
If the information returned in the inverse query response packet
indicates that the target DNS server is not vulnerable to the TSIG
exploit, the exploit process closes the TCP connection and exits.
However, if the information yielded from the information leak exploit
indicates a vulnerable BIND, the exploit process proceeds with the
TSIG exploit. The traffic pattern looks like this:
<p>
<pre>
attacker:port -> victim:53 UDP (shellcode)
victim:53 -> attacker:port UDP DNS format error
attacker:port -> victim:53 TCP (payload)
</pre>
In exploits we have seen, the shellcode is sent by the exploit using
UDP, causing /bin/sh to be attached to the existing socket connection
on port 53/tcp. Then, the exploit sends shell commands on 53/tcp for
execution on the compromised host as the user running the nameserver
process.
<p>
Examples of two specific toolkits employing this type of exploit are
discussed below. Note, intruder toolkits often change over time, so
exact composition and attack sequences may vary from these
descriptions.
<p>
<h3>'erkms' toolkit</h3>
<p>
A small number of incidents reported to the CERT/CC since mid February
of 2001 have involved the use of a toolkit called 'erkms'. However,
the incidents have in total involved more than 10,000 hosts.
<p>
The attack portion of 'erkms' uses the following tools:
<p>
<font face="Courier">
<pre>
MD5 checksum Filename Filesize
-------------------------------------------------------
5899fa53c027aa2813c6adcaaf096a25 l 17203
ccccd7adba38b2f3ed777a398624097e m.c 234
40323dbe7d19e41303088f49ce6a4edd m.o 5535
7df70d9e426aaaeeadfb24c066d5445f rscan 39621
3c856a7f1cfd6d22cbc32a8ccf0a796a r 75
</pre>
</font>
<ul>
<li>'r' is a shell script that calls 'rscan' to scan a /8 network
block for TCP port 53. For a victim host listening on TCP port 53
with no influence from packet filtering, the traffic pattern is:
<pre>
attacker:port -> victim:53 TCP SYN
victim:53 -> attacker:port TCP SYN ACK
attacker:port -> victim:53 TCP RST
</pre>
<li>For hosts responding on 53/tcp, 'rscan' executes 'm.o', which
in turn executes the exploit code 'l' against the victim host
(see "Attack Profile" above).
</li></li></ul>
The payload of the exploit code uses the rcp(1) program to retrieve
additional tools from a remote distribution point. The additional
tools are installed on the compromised host. The tools installed
and used include:
<p>
<font face="Courier">
<pre>
MD5 checksum Filename Filesize
-------------------------------------------------------
ffe6f1055d4bca4fb56a1124bf293c95 a 448
4a2149387c8b538d5b0ff65f85e08dcc net4 337920
60959ee2254105bfc55a2740dc1bdaab bj 212244
0f81ae0bcb1111f586d673a5818a8ce0 btm.c 7513
007c4e98ad2ec4c26d30247e5399360a btm.h 2258
fcc8ae5a47dcb55e27a7ca37fe7745ef fix 17653
f227d09f1697ebb268d36e83f54db55a go 1024
f2f8b75aafb1b6314b93b7a0a18fac2a ls 36952
662c04f1e5af11fc38a82b736644b591 named 579660
a8a65bd376f38ce3f99bed64956bdf09 netstat 32800
6dcd03966a893e2d38e833727cbcc35a tcpd 14224
</pre>
</font>
<ul>
<li>'net4' is a trinoo distributed denial of service agent,
which is discussed in
<a href="/incident_notes/IN-99-07.html">CERT Incident Note IN-99-07</a>.
It is installed and executed as '/usr/sbin/init' and a crontab
entry is added to restart the process.
<li>The following system files are replaced with intruder supplied
versions:
<ul>
<li>/bin/login (from 'bj') - allows backdoor connections
<li>/usr/sbin/in.telnetd (via 'btm') - allows backdoor connections
<li>/usr/sbin/in.ftpd (via 'btm') - allows backdoor connections
<li>/bin/ls (from 'ls')
<li>/usr/sbin/tcpd (from 'tcpd')
<li>/bin/netstat (from 'netstat')
<li>/usr/sbin/named (from 'named')
<li>/usr/sbin/in.smb (from '/usr/sbin/in.telnetd')
<li>/etc/inetd.conf and /etc/services are both modified to cause
inetd to spawn /usr/bin/in.smb for connections to TCP port 54321.
The bogus service name used is 'smbd2'.
</li></li></li></li></li></li></li></li></li></ul>
<li>Trojan horse configuration information is written to '/dev/hdbb'
and '/dev/ptyq'.
</li></li></li></ul>
<p>
<h3>'1i0n' worm</h3>
<p>
A growing number of incidents reported to the CERT/CC since mid
February of 2001 have involved the use of a toolkit called '1i0n', or
'lion'. Multiple versions of '1i0n' are known to exist, but in all
versions we have seen the same attack profile described above used
to exploit vulnerabilities in victim hosts.
<p>
All known versions of '1i0n' seem to perform the following similar
actions via automated scripts to locate and attack victim hosts.
<p>
<ul>
<li>A program named 'randb' is executed to select a random
/16 network block.
<li>'pscan' is executed to scan for TCP port 53 across the random
network block. The traffic pattern of the scan differs from that
of the 'rscan' tool from 'erkms' in that a full 3-way TCP
handshake is completed and the connection is properly
terminated. For a victim host listening on TCP port 53 with no
influence from packet filtering, the traffic pattern is:
<pre>
attacker:port -> victim:53 TCP SYN
victim:53 -> attacker:port TCP SYN ACK
attacker:port -> victim:53 TCP ACK
attacker:port -> victim:53 TCP FIN ACK
victim:53 -> attacker:port TCP ACK
victim:53 -> attacker:port TCP FIN ACK
attacker:port -> victim:53 TCP ACK
</pre>
<li>For each host responding on 53/tcp, the exploit code 'bind' is
executed against the victim host (see "Attack Profile" above).
</li></li></li></ul>
<p>
The attack cycle continues through the entire /16 network block, at
which point a new /16 network block is randomly selected and the
attack cycle begins again.
<p>
The payload of the exploit code retrieves a copy of the '1i0n' toolkit
and installs it on the compromised victim host. At that point, a new
attack cycle is initiated on the victim host without any intruder
intervention. The source of the '1i0n' toolkit installed on a
compromised host and the composition of that toolkit may vary
significantly between versions. Some examples of what we have seen
include:
<p>
<ul>
<li>sensitive system information, including copies of the /etc/passwd
and /etc/shadow files, sent via email to a remote address
<li>system binaries replaced with intruder supplied versions to hide
intruder processes and network connections, and to provide backdoor
privileged access
<li>system configuration files altered
<li>system logging facilities may be disabled and log files may
be destroyed
<li>installation of distributed denial of service tools such as
Tribe Flood Network (e.g., tfn)
</li></li></li></li></li></ul>
<p>
More information about '1i0n' has been published by The SANS Institute.
<p>
<dl>
<dd><a href="http://www.sans.org/y2k/lion.htm">
http://www.sans.org/y2k/lion.htm</a></dd>
</dl>
<p>
<h1>Impact</h1>
<p>
Intruders are using automated and self-replicating toolkits to exploit
known vulnerabilities in ISC BIND. Exploit code is in wide public
circulation.
<p>
Systems running vulnerable versions of ISC BIND are at risk for being
compromised on a widespread basis. Compromised hosts are at high risk
for being used to attack other Internet sites, having system binaries
and configuration files altered, and having sensitive information
exposed to external parties.
<p>
<h1>Solution</h1>
<p>
The CERT/CC encourages all Internet sites to review
<a href="/advisories/CA-2001-02.html">CERT Advisory CA-2001-02</a>
and insure workarounds or patches have been applied on all affected
hosts on your network.
<p>
As a good security practice, access to nameservers on TCP port 53
should be restricted to trusted sources only using nameserver
configuration options, host-based access control lists, and/or
network-based access control through packet filtering.
<p>
If you believe a host under your control has been compromised,
you may wish to refer to
<dl>
<dd><a href="/tech_tips/root_compromise.html">
Steps for Recovering From a Root Compromise</a></dd>
</dl>
<p>
<b>Author(s)</b>: Kevin Houle, George Weaver, Ian Finlay<br/>
<!--#include virtual="/include/footer_nocopyright.html" -->
<p>Copyright 2001 Carnegie Mellon University.</p>
</p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p> |