|
|
John Kemp
Senior Security Engineer
kemp@ns.uoregon.edu
In mid-July, yet another new Internet worm made headlines. Known as "Code
Red" (CR), this worm is code that infects one machine and then propagates
over the network attempting to infect others, leveraging a vulnerability in
Microsoft's Internet Information Server (IIS) webserver software.
How CR works. The CR attack takes the form of a buffer overflow against
the IDQ.DLL, which is reached through a script mapping for ".ida"
or ".idq" files, a component of the IIS web indexing services. The
overflow allows attackers to gain system-level privileges on the infected machine.
They can then perform any kind of malicious activity on that machine and continue
to propagate to others.
The initial variant of CR was not intended to be extraordinarily destructive.
It modifies the memory-resident homepage of the webserver, and at a specified
date the code attempts to flood the site www.whitehouse.gov
Hidden hazards. Although the worm can be defeated by patching for the
vulnerability and rebooting, its success gave it an unexpected and damaging
side effect: some networks on which the worm was trying to propagate became
saturated and experienced traffic slowdowns. The worm also revealed a number
of shortcomings in certain types of networking equipment, particularly those
that allow management through a web interface, and some of those devices failed
in the face of the CR buffer overflow.
Worm variants. Since the initial release, a number of variants of the
original CR worm have been crafted. These variants proved to be both more successful
and more malicious than the original. According to CAIDA (the Cooperative Association
for Independent Data Analysis), the first variant of the worm, called "Code-Redv2,"
infected over 350,000 machines in less than one day.
In early August, another variant called "Code-RedII" appeared. This
variant installs a modified version of the file "explorer.exe" on
infected machines, and enables the remote attacker to regain system-level access
to the machine at any time.
The success rate of infection by the CR worm and the incidental damage that
it caused to networks raises some interesting issues about security and the
Internet. Below are some general lessons one might learn from these incidents.
When exceptions are made in security policies, they can have serious consequences.
For example, if an organization designed a complete network security system
and installed a firewall to block incoming connections and filter out known
attacks--but made one exception to allow Internet web queries to reach
an unpatched IIS webserver behind the firewall--the entire security design
would essentially become worthless.
Local estimates at the UO were that if you set up an IIS server on campus during
the height of the attacks, that machine would be hit by the Code-Redv2 worm
in less than an hour. And because of the way the worm chooses targeted IP addresses,
once an internal machine on the network becomes infected, it would take even
less time for a local machine to become infected.
Because of this, when installing a new machine it's best to use another
machine to obtain and store patches to a portable media, such as a CD-ROM. Then
take the media and install the patches on the new machine before you connect
the new machine to the network.
The Internet as a whole is generally considered to be reliable. There are often
multiple network paths between major nodes, and dynamic routing is used to heal
small scale outages. In larger organizations a great deal of effort is expended
to ensure that the equipment is well built and that the power infrastructure
supporting the network is robust.
But it is important to remember that any particular segment of the Internet
may not be bulletproof. "Denial of Service" (DoS) attacks against
specific targets have been successful in a number of cases. And in the case
of CR--because of poorly designed interfaces on some networking gear,
or the large volume of traffic during the attack, or inadequate capacity--some
parts of the Internet were severely impacted.
One notable technique demonstrated by the CR worm is that IIS is a good target.
In the past, buffer overflows have been one of the most common forms of attack
against Unix machines. It is interesting to see that this method is now being
used against Microsoft OS machines as well. Because of current software coding
practices, and because of the size and complexity of large packages (like IIS),
finding a solution for the generalized problem of buffer overflows is not going
to be easy.
Another interesting technique that the CR worm exhibits is that it is a memory
resident program. This means that a machine could fall victim to the CR attack,
but there might be no evidence of changes left in the filesystem of the machine.
One could easily imagine a more cleverly crafted worm that does not leave behind
the other incidental footprints that CR does. Indeed, there are already a number
of backdoor programs targeting other operating systems that subvert normal system
calls in such a way that they become virtually undetectable to the local administrator.
The good news is that the initial variants of CR were for the most part nondestructive.
The bad news is that the next time your machine is compromised you may not even
know it.
While I think UO administrators performed fairly well in the face of the attack,
the most disappointing aspect of the recent CR incidents is the failure of the
system administrator community at large to address the problem in a timely fashion.
Warnings about CR were given through numerous channels, and yet many administrators
failed to apply patches to their systems. It may be possible that many machines
are running with no administration whatsoever. It's also possible that
some administrators are not paying attention to security warnings. Or, worse
yet, it could be that some administrators simply don't feel it is important
to apply patches until the damage to their systems reaches a critical level.
Whatever the case, CR did not show system administrators in a positive light.
For more details on worms and network security, see the following web pages: