Lion Internet Worm
AnalysisThree versions, more on the way, and a political
message.Max Vision <vision@whitehats.com>

Abstract

This paper provides an introduction to the Lion (1i0n) Worm author and
a technical analysis of the Lion Internet Worm. Three unique variations of
the Lion Worm have been released on the Internet over the past month. All
three versions of the Lion Worm are unsophisticated unix shellscript
worms. They use exploit scripts to scan and compromise Linux servers
running BIND that have the transaction signatures buffer overflow
vulnerability. The origin, composition, and behavior of each worm is
discussed in detail. Then, instructions for prevention, detection, and
repair of a worm-infected system are offered. The first two strains of the
Lion Worm are now effectively "dead", because each of these relied on a
centralized distribution mechanism that is now shut down. The third strain
of the Lion Worm is essentially a copy of the Ramen worm and, since it
shares Ramen's distribution mechanism, it may still be actively exploiting
systems.

A Chinese cracker named "Lion" authored the Lion Worm. I was able to
locate and conduct a brief interview with the author. Lion founded the
H.U.C. (Honker Union of China at http://www.cnhonker.com/), which is a
Chinese group that supports "the cyber defense of the motherland
sovereignty of China". They consider the word "honker" to be a new term,
roughly meaning "network guard for national security". Apparently, they
have created these worms as a warning against the Japanese because of
controvertial books currently used in Japanese schools. These textbooks
depict the Japanese invasion and occupation of various asian countries,
such as China and Korea, as being beneficial to the occupied countries.
The book claims said the 1937-1938 Nanking massacre in China ''was not a
holocaust'' and that Japan's annexation of the Korean Peninsula in 1910
was ''legitimate''. The statement I received from the H.U.C. is the
following:

"because of the japan's disrepect,
cnhonker had been roused,and the lion worm is just
to tell the japanesechinese is not sheep, they must be
answer forThey must assue the obligation with their
crimeThey must assue their action for the educational
book."

I did not discuss the right or wrong of their actions. However, I did
ask them why they would unleash a worm on the entire internet when they
were just upset with the Japanese education system. Their reply was that
they could not identify the correct IP addresses ranges. Since these are
readily available from jpnic, I question their motives of tying a
political message to their actions and calling it hacktivism. If the Lion
Worm was meant as a political message, then why was no message attached?
In any case, I believe I discovered the actual author, the group, and the
(stated) motive.

Composition

There are three distinct versions of the Lion Worm. Each appears to be
an unoriginal cut-and-paste, script-driven worm. The first version has an
infection routine and includes the t0rn rootkit. The second version is
nearly identical to the first, but does not include the rootkit. And the
third is almost identical to the Ramen worm, except that its exploits are
replaced by the bind exploit.

Each version of the Lion Worm shares the same core components. The worm
is composed of a tcp connect portscanner, the bind exploit, and several
scripts that tie the components together and drive the worm. For the first
two versions of the worm, the worm package (a tgz archive bundle) was
downloaded from a server (a FreeBSD system located in China). The third
version of the worm uses the distributed distribution code from the Ramen
worm and the worm is downloaded from the previously infected system. The
following files are found in all known versions of the Lion Worm:

Linux ELF binary; prints a random
class b address such as "10.23" (very similar to gimmeRAND.c
from the ADMw0rm, though binary analysis shows several
changes).

pscan

unknown

Linux ELF binary; pscan is a portscanner that
scans a given class a, b, or c network range for a single tcp
port. Origin found, but there were no author credits in the
source.

hack.sh

worm author

shell script; reads in targets from
bindname.log (created by scan.sh) and runs bindx.sh
against each target.

bindx.sh

worm author

shell script; launches bind attack against
target.

bind

LSD

Linux ELF binary; remote exploit for the BIND
8.2.x vulnerability, written by LSD, released on their website
February 8th 2001.

This is a typical worm that seems to share much of the same code from
previous worms such as the ADMworm
(1998) , Millenium
Worm (1999), and Ramen Worm
(2001). The evidence shows that this is a modified version of another
worm, such as the hack.sh script which calls bindx.sh to exploit BIND.
This seems redundant, unless you consider that the original hack.sh
actually acted as a driver for several different exploit scripts. The Lion
Worm author only needed one exploit, but left the script structure that
was originally designed for multiple exploits. The other scripts are also
only slightly modified versions of scripts from previous worms.

Lion Worm Infection/Propagation
Cycle

All three versions of the Lion Worm have the same infection and
propagation cycle. Viewed from the perspective of a new victim host, the
first sign of worm network activity is a TCP portscan at port 53. The worm
scans random class B address blocks for potential targets. When it finds a
responsive nameserver, the worm launches the BIND exploit against the
target. When this exploit is successful, the commands run (via the BIND
exploit) cause the new victim to download its own copy of the worm,
extract the worm package, and then execute the startup scripts.

The first step for the worm is a pscan probe of the random class b
address space. In my lab setup I crippled the randb program so that it
always returns 10.0.0. I chose to use the 10.0.0.0/24 class c space only
to reduce clutter in the logs. This still allows for an accurate
simulation of the scan. Pscan sends tcp SYN packets to each address in the
10.0.0 range. However, pscan is actually a full connect() scanner. This
enables it to operate much more quickly, but it is more "noisy" in most
logging systems. The target machine is running a Redhat Linux 6.2 default
server at the 10.0.0.23 address. The source machine simulating the
worm-infected attacker is on a separate subnet. If it is on the same
subnet, a tcp connect() based scanner will not send its probes to hosts
unless they respond to arp requests. A packet trace of this successful
probe follows:

Pscan finds the 10.0.0.23 target system responsive to its probe. This
IP address is added to bindname.log. A hack script that tails the
bindname.log file runs in parallel with the scanner. When the new target
IP address is added, the hack script takes the new target IP address and
passes it to the BIND exploit.

The BIND exploit, written by the Last Stage of Delirium, is nearly
identical in all three worms. LSD actually released their exploit
linx86_bind.c on their website February 8th, the exact version used in
Lion version 1 (Lion.v1). However, the next day LSD updated the code
(without changing the filename), making minor changes to their exploit.
The changes were mostly cosmetic and did not affect the exploit
methodology. One noticeable change in the newer exploit was the different
command line parameters. By matching the command line syntax of the
exploits, I determined that Lion.v1 used the February 8th exploit. Lion.v2
and Lion.v3 used later versions. Each worm executes different commands on
the remote host with the BIND exploit.

My worm testing was greatly complicated by my choice of example target
platform: a default server install of Redhat 6.2. I thought that it was
probably the most popular distribution and version of Linux in use on the
Internet. Thus, it would be the best example of a typical worm target.
Indeed, the BIND exploit specifically listed Redhat 6.2 as the target
platform! However, Redhat does not enable the named service by default.
When it is activated (via linuxconf or ntsysv utilities), named is run as
user named, such as "named -u named". The only way Redhat 6.2 can be
vulnerable to the BIND exploit is when the administrator manually adds
named to the startup scripts, then intentionally runs it as root by
deleting the "-u named" portion of the startup command. After extensive
testing, I determined that this was true for all published BIND exploits
that claim to affect Redhat 6.2. Then I was convinced that I must have
missed something. A very warm thanks goes to Andreas Östling, who
described seeing the very same results I had seen and gave me
encouragement to continue the analysis.

Since each of the three worms use the same BIND exploit, the packet
captures are almost identical except for the commands run on the target
server. The following is an example of an attack from Lion.v1.

Then, a malformed UDP IQUERY is sent to trigger the BIND Infoleak
bug. This information is used by the exploit to determine the base
value of the named process frame stack pointer. This information is
later used for constructing the proper TSIG exploit packet:

Since the target appears to be a vulnerable Linux running BIND 8,
the exploit sends its overflow. The exploit code walks the
descriptor table of the exploited named process in search of the
socket descriptor of the previously established TCP session. The
found descriptor is duplicated on stdin, stdout, stderr, and /bin/sh
is spawned:

The key difference in the way each worm propagates is that the first
two versions use lynx to download the worm archive from a hardcoded
website address. The website hosted in China has since been removed,
effectively killing those strains of the worm. The third version uses the
asp webserver code from the Ramen worm. In fact, the same binary was
simply copied over, and even uses the same name for the file:
/tmp/ramen.tgz. This method causes the new victim to connect back to the
attacker at port 27374 to download a copy of the worm. This port is used
by the asp webserver program because it is started from inetd.conf using
the service name "asp". In Redhat 6.2, /etc/services correlates to port
27374.

When a remote system is exploited by the worm and the worm has run the
exploit commands, the worm archive is downloaded, extracted, and launched
on the new victim host. The following process flowchart shows how the
scripts of the worm package interact and effectively spread the worm to
other systems. With each repeat of this cycle, each new infected system
immediately starts scanning and attacking other random systems.

Lion Process Flowchart (all Lion versions
follow this model)

Prevention

Since the Lion Worm can only spread through the BIND TSIG
vulnerability, closing this security hole prevents infection. Security
patches have been available from vendors since January 2001. Vulnerable
Linux distributions have released update RPMs that effectively close the
hole. Various remote exploits for this vulnerability have been widely
published in public forums and web sites. Despite the availability of
patches and widespread exploitation of vulnerable services, a very large
number of Linux servers remain vulnerable.

Attempts to obscure the BIND version or server operating system are not
effective in preventing infection, since the worm attempts to exploit all
BIND servers that it finds. The exploit, written by LSD, intelligently
uses the BIND Infoleak vulnerability to determine if the remote system can
be exploited before attempting to compromise the server.

Caldera, Conectiva, Debian, Immunix, Mandrake, Redhat, Slackware, SuSE,
and TurboLinux have released patches or upgrades to address the
vulnerability. Please visit your vendor's security or errata webpage for
more detailed prevention and upgrading information. The following direct
links are provided:

The scanning and BIND exploit attacks do not leave logs in a default
install of Redhat Linux. Other platforms may vary. Although
/var/log/maillog is truncated or deleted in all three variations of the
worm, the use of a proxy mail gateway or proxy firewall will leave traces
of the destination email addresses as the worms send data back to the
attacker. Addresses used by the worms are shown in the following
table.

Email addresses used by
the Lion Worm

Lion.v1

1i0nip@china.com1i0nsniffer@china.com

Lion.v2

1i0nip@china.com1i0nkit@china.com

Lion.v3

huckit@china.com

The following filesystem irregularities are attributable to the Lion
worm. Note the redundant index.html replacement in Lion.v3.

The outgoing emails can be detected as well. However, the added
detection ability may not be worth the performance impact on the IDS. The
worm cannot replicate without triggering the signatures shown above.

Incident Recovery

If you have been infected by the Lion Worm, then you have suffered a
critical breach of security. Killing the worm processess, deleting the
files, and removing the backdoors will only clean the known part of this
attack. The unfortunate issue is that your system has been compromised at
the root level, and your IP address and password information have been
sent to an attacker. This may have allowed them to log in through the
backdoors and make other changes to the system. Further, since the worm
does not repair the original security issue, any other attacker can still
compromise your system. A good starting point for your path to recovery is
CERT's "Steps
for Recovering from a UNIX Root Compromise".

Incident Reporting

Most likely, the source address that is attacking your network is
another victim in the propagation of the worm. Therefore, it is much
better to report the information to your CERT, and let them do their job
of coordinating the attack trend information, rather than trying to
contact the owner of the machine that attacked you. This is a judgment
call that you or your corporate security policy may dictate, but please
remain calm and courteous when dealing with other admin involved in an
attack. They may not yet be aware that their system was compromised.