Lion Internet Worm Analysis
Three 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.

Contents

• Origin
• Composition
• Infection/Propagation Cycle
• Prevention
• Detection on a Local Host
• Detection on a Network
• Incident Recovery
• Incident Reporting
• References

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:

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.

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:

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.

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.

The following table illustrates the commands used in the BIND exploit by each version of the worm.

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)

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:

Caldera: http://www.caldera.com/support/security/advisories/CSSA-2001-008.1.txt
Conectiva: http://distro.conectiva.com/atualizacoes/?id=a&anuncio=000377
Debian: http://www.debian.org/security/2001/dsa-026
Immunix: http://download.immunix.org/ImmunixOS/7.0-beta/updates/IMNX-2001-70-001-01
Mandrake: http://www.linux-mandrake.com/en/security/2001/MDKSA-2001-017.php3
Redhat: http://www.redhat.com/support/errata/RHSA-2001-007.html
Slackware: http://www.linuxsecurity.com/advisories/slackware_advisory-1121.html
SuSE: http://www.suse.com/de/support/security/2001_003_bind8_%20txt.txt
TurboLinux: http://www.turbolinux.com/pipermail/tl-security-announce/2001-February/000034.html

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.

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

The following network bindings appear as a result of backdoors by the Lion worm. Notice the excessive number of backdoors present in the first version of the worm.

Detection on a Network

The following arachNIDS rules can be used with Snort to detect this worm on your network.

Pscan probes are detected using the portscan plugin in Snort, it can be enabled with:
preprocessor portscan: $INTERNAL 3 5 /var/log/snort/portscan

The BIND Infoleak probe can be detected using the arachNIDS ruleset: http://whitehats.com/info/IDS482
alert UDP $EXTERNAL any -> $INTERNAL 53 (msg: "IDS482/named-exploit-infoleak-lsd"; content: "|AB CD 09 80 00 00 00 01 00 00 00 00 00 00 01 00 01 20 20 20 20 02 61|"; reference:arachnids,482;)

The BIND TSIG overflow be detected using the arachNIDS ruleset: http://whitehats.com/info/IDS489
alert UDP $EXTERNAL any -> $INTERNAL 53 (msg: "IDS489/named-exploit-tsig-lsd"; content: "|3F 909090 EB3B 31DB 5F 83EF7C 8D7710 897704 8D4F20|"; reference:arachnids,489;)

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.

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

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.

"ISC Bind 8 Transaction Signatures Buffer Overflow Vulnerability", http://www.securityfocus.com/bid/2302

"ISC BIND Internal Memory Disclosure Vulnerability", http://www.securityfocus.com/bid/2321

"linx86_bind.c" exploit by Last Stage of Delirium, http://lsd-pl.net/files/get?LINUX/linx86_bind

GIAC Lion Worm Information, http://www.sans.org/y2k/lion.htm

Local links, provided for educational use only:
lion1.tgz / lion2.tgz / lion3.tgz / pscan.c / linx86_bind.c