Sarah Gordon
Virus Bulletin, August 1998, pp.10-12
ISSN 0956-9979
August 1998
One of the most interesting developments in computing over the last few years has been that of the now-ubiquitous Internet. Twenty five years ago, when the late John Brunner told a tale of a computer program which could crawl through an Internet-like network of computers, the Internet was largely the stuff of science fiction. Shockwave Rider[1] is now ‘required reading’ for any fledgling hacker, cyberpunk wannabe, or serious student of Internet history and culture.
By 1982, ARPANET (the beginnings of the Internet) was being implemented. Real experiments with worm programs for beneficial tasks were being conducted at the Xerox Palo Alto Research Center.[2] The concept of a tapeworm program crawling through networked systems outside the research labs saw a hint of reality when, in 1988, Robert Morris Jr brought parts of the infant Internet to, if not a grinding halt, a slow crawl. He lost control of one of his projects, known ever after as ‘The Morris Worm’ or ‘The Internet Worm’.
The main condition that prevented complete chaos as a by-product of that worm was the non-standardization of Internet-connected machines – the diversity of operating systems and architecture. While ten years ago the idea of one’s desktop machine participating in a worldwide network of computers was just beginning to take flight, today modern operating systems almost invariably possess some form of Internet connectivity. Another interesting trend has been an increase in the homogeneity of the global network. Whereas the Internet once consisted of many different flavours of machines loosely grouped together as ‘Unix’, the Net has grown in such a way that there are now large populations of very similar machines.
While this similarity allows easy creation of software that can be run on a large number of machines, it also allows the homogenization of some attack strategies. That there are so many ‘like-minded’ machines on the Internet allows an attacker to penetrate many machines using the same technique, attack, or program should he find a security hole.
The Morris Worm was designed to spread from machine to machine, utilizing security holes of which most hackers and many administrators were already aware. Due to the large number of machines that were vulnerable to the worm’s penetration technique, it was an overnight sensation. Estimates are that hundreds, or perhaps thousands of machines were compromised within hours of its release[3].
Since then, worms have come and gone without much fuss. There have been some isolated outbreaks, but generally the machine population susceptible to each worm has been sufficiently small and diverse to diffuse the problem. However, the conditions have become increasingly favourable to the creation of a new, viable worm. Enter Admw0rm, a worm capable of spreading from one Linux to another, utilizing a hole in the Berkeley Internet Name Domain server, BIND.
BIND is an implementation of Domain Name Service (DNS), written primarily for Unix Systems. It consists of three parts – client, server and tools. BIND is integral to the Internet, but has had some glitches. There have been vulnerabilities that result in the saving of incorrect (sometimes maliciously selected) data by a remote name server (cache poisoning), giving the possibility of corrupt or compromised information; denial of service attacks; and problems resulting in remote crashing of systems.
While problems in BIND are found and fixed, unpatched versions of the package remain on many machines. It is this fact that makes the discovery of the Admw0rm so unsettling. This program demonstrates yet another BIND vulnerability/compromise. BIND 4.9 versions prior to 4.9.7 and versions 8 prior to 8.1.2 have a vulnerability which, if properly exploited, can result in an intruder gaining access to the computer. (The worm takes this one step further, and does this compromise/access automatically.)
These vulnerable versions of BIND do not carry out proper bounds checking when they respond to an inverse query request. The worm begins its attack by making precisely that request, which, if successful, results in the creation of an SUID (root) shell on the newly compromised machine.
The version of Admw0rm that has been distributed widely amongst the ‘hacker’ community is designed to attack the popular Linux operating system. The worm comes in a tar archive, complete with a README and a copy of the CERT advisory alerting system administrators of the BIND vulnerability, as well as full source code. In fact, the worm package is comprised entirely of C and shell script – all binaries are built by the handy install script included.
The worm starts with the execution of an install script, called, creatively enough, ‘startup’, written in standard Unix Shell command language. It builds several binaries and creates a zipped tar file of them for later use. It then adds itself to the password file of the new machine, creating an account with no password, before launching the main worm script, Admw0rm.
As diddling with the password file requires root access (if not, your system is in so much trouble, this worm will be a drop in the ocean) most users will not be able to launch the worm. It would, however, be relatively easy to bypass this limitation; in many cases, it is also relatively easy to obtain root access on many systems, but that is another topic.
The body of the Admw0rm, apparently the product of the ‘ADM Crew’ (claiming, somewhat optimistically, that the ‘THE CREW WILL NEVER DIE’), is also a simple shell script. This script calls in turn: the previously compiled binary GimmeRAND which creates a random IP address, each octet in the range 1 to 231; Incremental – a simple shell script which, when given a starting IP address, creates a list of IP addresses by incrementing the starting value; and Scanco – a binary which attempts to connect to a remote machine via UDP port 53, on which BIND is normally located.
The result of the preceding contortions is to create a loop, into which IP addresses of machines which appear to be running named [‘name dee’ – the name server daemon. Ed.] are passed. Inside this loop, a test is first made to see if the remote machine is vulnerable to attack. In order to do this, the worm executes another compiled binary which tests whether ‘named’ is running with ‘iquery’ enabled. If it is, the replication routine is called.
When a vulnerable machine is found, the exploit executable is called. This utilizes the aforementioned named buffer overflow problem to perform the initial compromise, and then executes a string of shell commands. These commands create a new user called worm on the target machine, with a null password. Furthermore, /bin/sh (the usual location of the standard Unix shell) is copied to /tmp/.worm, and made SUID root. Finally, any restrictions upon those hosts which are allowed to connect to the machine are lifted by the deletion of the hosts.deny file located in /etc.
With this damage successfully carried out, the worm runs a utility that allows for remote submission of commands to a machine via telnet. This is called with instructions that cause the following operations to be attempted. The named daemon is restarted, as the previously used buffer overflow usually causes it to crash. A file /tmp/.X11x is created, which by default is an html page containing the text ‘The ADM Inet worm is here !’. A directory /tmp/.worm0r is then created. The worm checks if it is already installed on this machine by looking for the existence of the file /tmp./wormishere. If found, the worm deletes all files in /var/log (the default location of the system log files) and the file /tmp/.worm. If the worm is not already installed, it uses the ftp protocol to connect to the source machine, and copies the tgz file (created above) from it.
The tgz file is decompressed in the directory /tmp/.worm0r and the self-infection check file /tmp/wormishere is created. Admw0rm’s main body is executed as a background task while the IP address of the newly compromised machine is emailed using /bin/mail to a definable email address. Finally, all files named index.html are replaced with the same html page described above but there is a trivial error in this routine that prevents this operation from completing.
The good news is that although the Admw0rm is a viable worm for the Linux operating system, it contains a number of assumptions and limitations. The most obvious is that the exploit used to travel from machine to machine is only present in some versions of BIND, and even then, only if the inverse query feature is turned on – it is off by default. The vulnerable versions of BIND have been superseded by ones that are not open to this particular attack. However, as was seen during the time of the Morris Worm, the availability of a patch or upgrade does not necessarily correlate with its being installed on vulnerable systems. The worm also assumes that the source machine has both telnet and ftp services enabled. Although these services are often on by default, many machines do not have them.
These limitations are responsible for restricting potential damage by the worm. Had the problem been manifested in the default configuration of BIND, the situation would most likely have been worse. That said, some administrators are seriously concerned about the number of compromised systems and Admw0rm’s general availability. The fact that so many machines have been compromised using buffer overflow exploits should merit the attention of anyone responsible for the security of systems running BIND.
In fact, the CERT advisory in which this vulnerability and exploit was mentioned stated ‘The CERT Coordination Center has received reports of new kinds of intruder activity indicating that intruders are targeting machines running vulnerable versions of “named” (domain name server software that is part of BIND). Thousands of sites running unpatched, vulnerable versions of “named” are known to have been compromised through exploit methods discussed here and in CS-98.04.’
According to CERT [4] , you can tell if your version of BIND is vulnerable to this particular buffer overflow exploit. For BIND 8, if your fake iquery parameter is set to ‘yes’ (the usual file name where you will find this is /etc/named.conf), you are vulnerable. You should remove that option, or set it to ‘no’. For BIND 4.9, look for the line containing ‘Fake-iquery’ in the /etc/named.boot file. If it is there, you are vulnerable – remove it. Make sure that the line defining INVQ is commented out in your conf/options.h source; otherwise, inverse query support will be added at compile time. (If your nslookup is old, disabling inverse query support may cause it to fail. If this happens, replace nslookup with a more current version.)
These same vulnerable versions of BIND have other problems which are not fixed by the suggestions above. According to CERT [5], the best option is to upgrade to BIND 4.9.7 or BIND 8.1.2 as appropriate.
The bad news is that this is just one of several which have been observed in varying stages of ‘development’. The original warning, issued on 28 May stated ‘While intruders appear to be using tools that exploit this vulnerability on Intel-based machines, it would not be difficult for intruders to adapt existing tools to exploit the vulnerability on other architectures.’.
In fact, we have observed ports of the worm to other operating systems, as well as learning recently of several variations on the general theme. Some of these worms are even capable of performing system trojanization [6], making their presence invisible to the casual user as well as the reasonably experienced administrator.
While I have gone to great lengths to explain why the Admw0rm is not the end of the Internet-As-We-Know-It, it represents a disturbing trend which some have been predicting for a long time. As the number of machines connected to the Internet increases and the software they run becomes more homogenized, the environment becomes less and less hostile to worms. Indeed, should any one platform and operating system (e.g. Windows NT running on an Intel processor) even approach the de facto standard, the conditions become downright favourable should a worm capable of penetrating such a system be developed.
The logic behind this is clear – for a worm to be ‘successful’ it must be able to spread to new hosts faster than its replicating segments are discovered and removed from compromised hosts. To obtain such a foothold requires a reasonable number of machines that can be compromised in a limited time. The simplest way is to take advantage of a huge system of homogeneous networked computers. If any one platform/OS combination began to dominate the network (a position we are rapidly approaching), this task becomes much easier for the prospective worm.
The conditions now are conducive to worm development. If you are not sure, look around. Have you seen any such homogeneous networked systems lately? Ask yourself ‘Am I ready to defend my system from such an attack? Would I even recognize it if it crawled into my network?’ In the case of Admw0rm, you can easily defend against an attack with the methods discussed here.