by Rik Farrow <rik@spirit.com>
An old problem that surfaced around the New Year has been responsible for invading Linux systems. An automated worm-based attack that propagates itself using network exploits became the topic of a CERT Coordination Center Incident Report March 30, after surges of similar attacks in December 2000 and February 2001. The CERT report mentions that as many as 10,000 systems had been affected.
Worms are nothing new. The Internet Worm, launched on November 2, 1988, took down over 10% of the systems on the Internet, essentially making the Internet unusable for over a day. The Internet Worm exploited only Sun Microsystems machines, although it did include an exploit for the Digital Equipment VMS operating system. More recently, we have seen worms that exploit weaknesses in Microsoft's Outlook mail tool, with names like Melissa, ILOVEYOU, and AnnaKournikova.
Do these new Linux worms represent a new level of danger in the war between attackers and system administrators? Or, is this nothing to worry about if you have nothing but Windows servers (or some version of UNIX other than Linux)? In this column we'll examine the Lion worm, and assess the potential threat it represents to various types of networks.
First, it's important to make the distinction between worms and viruses. Viruses require the interaction of a user to get installed, and then further interaction for the virus to spread. Worms, on the other hand, actively spread themselves over the network. Once a worm has been installed, it immediately begins executing, searching for more systems to exploit. Compared to viruses, worms are voracious and active.
The first well known worm, the Internet Worm of 1988, disabled the Internet by infecting key systems multiple times. The Internet Worm did not destroy target systems, and was actually intended to slowly and subtly infect thousands of servers. But a flaw in the code caused it to rampage through these systems, so that so many copies of the Worm would be running on each system that no other work could be done. And, because the Worm disabled key servers, no information about blocking it could be disseminated across the Internet.
More recent worms infected Microsoft-based systems with Office installed. These worms relied on a feature of Outlook to email themselves to other people in the victims' address books. Melissa, ILOVEYOU, and AnnaKournikova all relied on some assistance from their victims, that is, the victims needed to open the email or click to activate an attachment. Because so many people use Office, and share email with each other, although these worms did nothing but spread themselves, they all caused havoc as they overloaded mail servers with their useless messages.
Late in 2000, a poorly functioning Linux worm named Ramen appeared. Because of the bugs it contained, this worm did not spread very widely. The Lion worm has done much better, if infecting large numbers of Linux systems can be called better.
The Lion worm uses a bug in BIND (see the August 2000 column for other BIND problems) to infect Linux systems. Although this bug could be used on other systems that run unpatched versions of the BIND DNS software (any version before 8.2.3), the Lion worm focuses strictly on Linux, and only Linux systems running on Intel processors. The exploit itself involves a buffer overflow while processing a transaction signature (TSIG), and because [code]named[/code] runs as root on most Linux systems, the exploit results in root access of the targeted system.
Finding a vulnerable version of BIND is an important part of the success of an automated attack like the Lion worm. The Internet Worm used information found on an invaded system to pick its next victim. The various Outlook worms have all used the victim's address book to choose the next set of victims. The Lion worm does something completely different.
The Lion worm uses an assembly line-style method to search for new victims. First, a random number, constrained to being within the range of legal Internet addresses, is calculated. Then that number is used as the first 16 bits of a 32 bit network address, and passed to a program that generates the last 16 bits, trying each of the 65534 possible legal addresses. Each of these addresses is port scanned, but only for an open port 53/TCP that indicates that a nameserver is running. Addresses where nameservers are running are then passed to an exploit tool, which checks the version of BIND, and then sends the exploit code if it has a chance of succeeding. In this manner, a single worm can canvas thousands of systems each hour.
Of course, if the Lion worm happens to scan a network protected by a firewall, it can only probe port 53 when the firewall permits access to that port on an internal system. Fortunately for the worm, that is not uncommon, as DNS servers are often exposed to the Internet. If you are permitting access to an internal DNS server through your firewall, please reconsider it. It is safer to host a DNS server externally that contains enough information for people to locate your public servers. You would also be wise to get third parties, like your ISP, to host a secondary server, so that you don't fall prey to what took Microsoft "off the Internet" in January of 2001 when someone flooded the only subnet where Microsoft had placed their four DNS servers. Microsoft now has at least one external DNS server, hosted by Akamai.
As soon as the Lion worm exploits a system, it downloads and installs t0rn, a rootkit (see Resources). In general, rootkits are designed to be easy to install, to hide their own presence, to install backdoors, and to sniff for passwords. T0rn is especially easy to install--imagine a self-extracting archive that replaces the original versions of commands that might detect it with trojanned versions. That's t0rn. T0rn also installs backdoors, server programs that provide remote root access to the system to anyone who connects to the port used. By default, t0rn listens to port 47017/TCP. But CERT reports that the version used by the Lion worm listens at 27374/TCP, the same port that is used by the popular SubSeven trojan for Windows systems.
Next, the Lion worm sends off some information to a server in the china.com domain. And yes, the address really does belong to a network in the Asia Pacific region. The information sent includes the /etc/passwd and /etc/shadow files, as well as the IP address of the victim. The worm then deletes /etc/hosts.deny, used by TCP Wrappers to provide access control to Internet services based on source IP address. The worm also kills the system logging daemon (syslogd), so logging ends for many services (some programs do not use syslogd, like the login program).
The Lion worm adds its own backdoors. Ports 60008/TCP and 33567/TCP get a backdoor root shell by having new entries added to /etc/inetd.conf, a very common method for providing a root-owned shell to a UNIX system. The nscd program, a caching-only name server, gets replaced with a trojaned version of sshd that listens at port 33568/TCP. The login program also gets replaced by a trojanned version.
At this point, the victim has been thoroughly "instrumented", with original versions of system administration programs like ps, netstat, and ifconfig, as well as more commonly used programs like find, ls and du, replaced by trojanned versions that hide file and directory names, processes, and network connections. The configuration files for these trojanned versions vary, with one common location being filenames beginning with /dev/pty. The CERT Incident Note mentions the use of /dev/hdbb for a configuration file.
The many backdoors provide remote root access--presuming that the victim is not behind a firewall that is blocking all inbound access except to port 53/TCP, the port used by the initial exploit.
If ps is hiding the worm's processes, and netstat is hiding the worms and rootkit's network connections, how can you detect the presence of t0rn or the Lion worm? The t0rn rootkit sets up many new services, and you can find these services by using the lsof (List Open Files) program that comes with Linux (and some other UNIX versions) and has not (yet) had a trojanned version created. The command pipeline lsof|grep LISTEN will display all processes that have opened a network socket, and the backdoors in inetd.conf, as well as the port used by the trojanned ncsd, should show up here.
Both the CERT Incident Report and a SANS (System Administration, Networking and Security) Institute report on this issue mention that the final action of the Lion worm is to install a DDoS agent. CERT mentions trinoo, which is an unreliable UDP flooding tool that requires an entry in the crontable (similar to NT's task scheduler) to restart it often. The SANS report mentions TribeFloodNet (tfn), a much more sophisticated and reliable DDoS agent. However, it's difficult to understand why a hacker would choose either of these agents, because later variants have better control features, more types of attacks, and the ability to be remotely upgraded.
Note that the Lion worm has done many of the same things done manually by the attacker who compromised the Linux system discussed in last month's column. (In that column, we examined an incident in which a group of security professionals attempting to learn more about scanning-based attacks set up a Linux server, an endeavor called the Honeynet Project. The server was successfully hacked and valuable data was gained via the project.)
In the Honeynet Project, the attacker put backdoors in inetd.conf, deleted /etc/hosts.deny, killed syslogd, and installed a trojanned version of the login program. The attacker also installed a Secure Shell Daemon (sshd), although that version listened at the assigned port, 22/TCP. Although the Honeynet Project Linux system was automatically attacked, everything else was done "manually", with the attacker logged in either through the backdoor, telnet, or via SSH (Secure Shell).
The Honeynet Project attacker also left five different exploits, all designed to work via automated scanning, on the victim system. The Lion worm, on the other hand, appears to be more of a one trick pony, using only the BIND TSIG vulnerability to exploit systems. And while the Lion worm leaves behind DDoS agents, the Honeynet Project attacker seemed primarily interested in IRC.
In a sense, both the Lion worm, and the sets of automated exploit tools found on the Honeynet Project Linux system, present a new model for exploiting systems--that of automated exploits. Automated scanning tools, like mscan and sscan, have been around for years. What's new is the addition of automatically exploiting the systems found through scanning massive numbers of Internet addresses.
For most network administrators, automated scanning should not be a problem. Properly configured firewalls will block most of the scanning, unless you have punched holes in your firewalls that provide direct access to internal servers. Most firewall products make this easy to do, which can give people the impression that such a system is somehow "secure." But allowing inbound connections to any service on your internal, protected network is never a good idea, and should be done cautiously if at all. At the very least, make certain that the service involved is kept upgraded with any security-related patches, and consider taking that service offline in the event that an exploit gets published or CERT puts out an advisory.
If you have one or more Linux servers installed, and not protected by firewalls (including IP chains, the native Linux firewall), you should expect these systems to have already been compromised. Unless you have installed BIND 8.2.3, or 9.1, or disabled all Internet services (just to be safe), you may be at significant risk, as the number of systems automatically scanning the Internet for vulnerable Linux systems appears large. The Honeynet Project Linux server was up for only 2.5 days before it was attacked.
And even if you don't think you have any Linux systems on your network, think again. Linux takes less time to install than any Windows system, and its low cost and large number of free applications make it almost irresistable. And not only to your authorized users.
CERT Advisory with links to vendor patches (note other Linux versions are vulnerable): http://www.cert.org/advisories/CA-2001-02.html
SANS note about the Lion worm, with a complete list of links for Linux vendor advisories and patches: http://www.sans.org/y2k/lion.htm
CERT Incident note that discusses the Lion worm: http://www.cert.org/incident_notes/IN-2001-03.html
Gene Spafford's report on the Internet Worm of 1988: www.cerias.purdue.edu/homes/spaf/tech-reps/933.pdf
Information about the t0rn rootkit:
http://www.securityfocus.com/focus/ids/articles/t0rn.html
The whitehats.com site had a great description of all three versions of the Lion worm. You can find a copy of these descriptions here (scroll past the Italian in the beginning of this post).