Malicious Codes in Depth
{LANG_NAVORIGIN} Malicious Code
Mohammad Heidari
11/29/2004
Propagation Carriers and Distribution Mechanism
The means by which propagation occurs can also affect the speed and stealth of a worm. A
worm can either actively spread itself from machine to machine, or it can be carried
along as part of normal communication.
Self-Carried: A self-carried worm actively transmits itself as part of the
infection process. This mechanism is commonly employed in self-activating scanning or
topological worms, as the act of transmitting the worm is part of the infection process.
Some passive worms, such as CRClean, also use self-carried propagation.
Second Channel: Some worms, such as Blaster, require a secondary communication
channel to complete the infection. Although the exploit uses RPC, the victim machine
connects back to the infecting machine using TFTP to download the worm body, completing
the infection process.
Embedded: An embedded worm sends itself along as part of a normal communication
channel, either appending to or replacing normal messages. As a result, the propagation
does not appear as anomalous when viewed as a pattern of communication. The contagion
strategy is an example of a passive worm that uses embedded propagation. An embedded
strategy, although relatively stealthy, only makes sense when the target selection
strategy is also stealthy. Otherwise, the worm will give itself away by its target
selection traffic, and reaps little benefit from the stealth that embedded propagation
provides. Thus a scanning worm is unlikely to use an embedded distribution strategy,
while passive worms can benefit considerably by ensuring that distribution is as stealthy
as target selection.
The speed at which embedded worms spread is highly dependent on how the application is
used, as is how far from the natural patterns of communication such a worm could deviate
in order to hasten it’s propagation without compromising its stealth ness.
Figure 8 Worm Highlights
In the rest of this section I try to introduce you with the popular worms.
The Internet Worm (November 3rd, 1988)
The Internet Worm is believed to be the first computer worm ever created. It
was released in November 1988 when World Wide Web even did not exist. The worm had taken
advantage of lapses in security on systems that were running 4.2 or 4.3 BSD UNIX or
derivatives like SunOS. Since the IP address space was too sparse to be scanned at that
time the worm retrieved addresses of possible victims from files like /etc/hosts.equiv,
/.rhosts, .forward, and .rhosts. Worm could penetrate a remote system by any of three
ways: exploit a bug in the finger server that allowed it to download code in place of a
finger request and trick the server into executing it, the worm could use a sendmail SMTP
mail service, exercising a bug in the debugging code that allowed it to execute a command
interpreter and download code across a mail connection. The worm could guess a password
for user accounts. In any case the worm arranged to run a remote shell that it could use
to copy, compile, and execute the 99-line bootstrap. The bootstrap set up its own network
connection with the local worm and copied over the rest of the files it needed. The worm
built itself from these files and the infection procedure started over again. The worm
itself has a bug that made it create many copies of itself on
machines it infected, which quickly used up all available processor time on those
systems. Nevertheless, the Internet worm was sophistically designed. For example its
crypt function was executed 9 times faster than the native UNIX crypt routine, it removed
all its files from the disk and prevented core dumps to complicate its disassembling. The
worm quickly distributed itself to over 6000 computers and has started the era of
Internet worms. Since several different propagation methods were used the first worm was
the first multi-vector worm at the same time.
Code Red I (July 13th, 2001)
Initial version of the Code Red worm was first seen in the wild on July 13th, 2001
the worm spread by compromising Microsoft IIS web servers using the .ida
Vulnerability discovered almost a month before that. Once it infected a host, Code-Red
spread by launching 99 threads that generated random IP addresses, and then tried to
compromise those IP addresses using the same vulnerability. However, the first version of
the worm had an apparent bug. The random number generator was initialized with a fixed
seed, so that all copies of the worm in a particular thread, on all hosts, generated and
attempted to compromise exactly the same sequence of IP addresses. Thus, first version of
Code Red worm had a linear spread and never compromised many machines. On July 19th,
2001, a second version of the worm began to spread. This version is known as Code Red I.
Code Red I. has the same code base as its first version in almost all respects. The only
differences were fixing the bug in the random number generator and a DDoS payload
targeting the IP address of www.whitehouse.gov. Theoretical analysis of the spread based
on the random IP range scanning is presented later in the text.
Code Red II (August 4th, 2001)
The Code Red II worm was released on Saturday August 4th, 2001 and spread rapidly.
Despite a comment string “Code Red II,” found in the worm body it is a differently coded
worm. It uses the same vulnerability, however. When successful, the payload installed a
root backdoor allowing unrestricted remote access to the infected host. The worm was also
a randomly scanning worm that chose IP addresses and tried to infect the corresponding
host. The innovation was that it used a localized scanning strategy. In particular the
worm attempted to infect hosts with addresses closer to the scanning host with higher
probability. It chose randomly from its own class A (/8 network) with probability 1/2,
with probability 3/8 it chose from the class B network (/16 network), and with
probability 1/8 it would choose a random address from the whole Internet. This strategy
appeared quite successful because the infection often proceeds faster since hosts with
similar IP addresses are often close in the network topology and thus have better
connectivity. In addition, this strategy allows the worm effectively infect hosts behind
a firewall once it manages to get into the local network.
Nimda (September 18th, 2001)
Nimda is another example of a multi-vector worm. Nimda started to spread
On September 18th, 2001 and remained active for months after it started. Nimda spread
extensively behind firewalls because it is believed to have used at least five different
methods to spread itself:
- by infecting Web servers from infected client machines via active probing for a
Microsoft IIS vulnerability
- by bulk emailing of itself as an attachment based on email addresses determined
from the infected machine
- by copying itself across open network shares
- by scanning for the backdoors left behind by Code Red II and also the
“sadmind” worm,
- by adding malicious code to the web pages on compromised machines.
Onset of Nimda was quite rapid, rising in just half an hour from essentially no probing
to a sustained rate of nearly 100 probes/sec. The worm’s multi-vector nature helped it to
effectively propagate behind firewalls. For example, most
firewalls allow mail to pass inside, relying on the mail servers to remove pathogens. Yet
since many mail servers remove pathogens based on signatures, they aren’t effective
during the first few minutes to hours of an outbreak.
Benjamin (May 18th, 2002)
Benjamin is a typical P2P worm that offers itself for download with different
file names, file types, and file lengths through the KaZaA network. In particular, the
worm had more than 2000 different file names to use and padded the files with garbage
bytes. In a departure from many other viruses and worms, 'Benjamin' may have had a
commercial motivation. The worm opens a Web page named "benjamin.xww.de" which contained
advertisements.
Slapper (September 13th, 2002)
Slapper spread on Linux machines by using a flaw discovered in OpenSSL libraries in
August 2002. The worm was found in Eastern Europe late on Friday
September 13th 2002. The worm scanned for potentially vulnerable systems on 80/tcp using
an invalid HTTP GET request. When a potentially vulnerable Apache system was detected,
the worm attempted to connect to the SSL service in order to install the exploit code.
Once infected, the victim server started scanning for additional hosts to continue the
worm's propagation. The worm constructed a distributed P2P network. In particular, newly
infected hosts were instructed to maintain connection via a set of UDP ports. The network
could act as a platform for Distributed Denial of Service (DDoS) attacks against other
sites. Infected hosts shared information on other infected systems as well as attack
instructions.
Thus, an attacker could control a distributed network of subverted hosts by connecting to
any of the participating nodes.
SQLslammer/Sapphire (January 25th, 2003)
The SQL slammer (a.k.a. Sapphire) worm was the fastest computer worm ever. The number of
infected hosts doubled every 8.5 seconds. The worm infected more than 90 percent of
vulnerable hosts within 10 minutes. The worm exploited buffer overflow vulnerability in
computers running Microsoft's SQL Server or MSDE 2000. The weakness in an underlying
indexing service was discovered almost a year before the worm outbreak and Microsoft
released patch for the vulnerability. The worm infected at least 75,000 hosts, perhaps
considerably more, and caused network outages worldwide. Sapphire spread was nearly two
orders of magnitude faster than the spread of Code Red. Both worms used the same basic
strategy of random scanning to find vulnerable machines and then transferring the
exploitive payload; they differed in their scanning constraints. The Code Red was latency
limited; SQLslammer was bandwidth-limited and was sending infection probes at the maximum
speed possible with the available network connectivity.
SQLslammer’s size was 376 bytes - so small, that even with all the packet headers,
the payload was only a single 404-byte UDP packet. This can be contrasted with the 4kb
size of Code Red, or the 60kb size of Nimda. Previous scanning worms spread via many
threads, each invoking connect () to probe random addresses. Therefore, each thread's
scanning rate was limited by network latency. In particular, the time required
transmitting a TCP SYN packet and waiting for a response or timeout. Worms can compensate
this latency by invoking many threads. However, context switch overhead is significant
and there are insufficient resources to create enough threads to counteract the network
delays. As a result the worm becomes latency dependent again. In contrast, SQlslammer's
scanner was limited by each compromised machine's bandwidth to the Internet. Since the
SQL Server vulnerability was exploitable using a single packet sent to UDP port 1434; the
worm was able to send these scans without requiring a response from the potential victim.
Fortunately, SQLslammer worm had a bug in its random number generator that left
considerable portion of the Internet hosts not scanned.
Blaster (a.k.a. Lovesan) worm (August 11th, 2003)
The worm exploits the buffer overflow vulnerability in the Distributed Component Object
Model (DCOM) Remote Procedure Calls (RPC) interface that allows arbitrary code to be
executed on most of the Windows NT, Windows 2000, and Windows XP platforms. Fortunately,
the worm is designed very poorly. Firstly, its scanning rate is very small and the worm
itself is latency-limited. Therefore, every machine was probed only once in a half an
hour on average during the peak of the epidemics. Secondly, the worm has a bug that
forced many of the machines to endlessly reboot thus reducing the number of the scanning
hosts. The worm has a payload to create a SYN DDoS attack against Windows update sites.
The Blaster worm showed that the auto update functionality provided by Microsoft is quite
successful. Despite the fact that at the time the bug was discovered almost all of the
PCs were vulnerable just three weeks later when the worm started to spread only half a
million of the machines were subverted.
Another important lesson from the Blaster worm epidemics is that even the
machines that are not patched by the worm outbreak time are soon patched and only one or
at most two worms that share the same vulnerability have a chance for widespread.
Welchia worm (August 19th, 2003)
Welchia worm raise a question whether an Internet worm can be good. The worm exploits the
same Microsoft DCOM RPC vulnerability as the Blaster worm in
addition to the MS03-007 vulnerability in the Microsoft IIS by randomly scanning
the IP address space. Surprisingly, the payload of the worm cleans the system from the
Blaster worm, downloads the patch for the DCOM RPC bug and patches the system. The worm
contains a code to remove itself from the host PC in January 2004. Despite the fact that
the worm itself is believed not to contain any malicious code and on contrary cures the
infected systems security experts worldwide still treat it as a malicious worm because it
installs itself without permission form the user and resides in memory until 2004 in
addition to overloading the networks with the probing and patch downloading traffic.
Nevertheless, it seems likely that Welchia will cure all the systems infected with the
Blaster worm within several days.
Top 2004 Worms
MyDoom
spreads by e-mail to Windows PCs, searches for e-mail addresses in various files, opens
backdoor for remote access.
Netsky
spreads by e-mail, exploits Internet Explorer to automatically execute e-mail
attachments, and removes MyDoom and Bagle from PCs.
Bagle
spreads by e-mail, tries to remove Netsky from PCs, and opens backdoor for remote access,
downloads code updates from Web, disables antivirus
and firewall software.
Spywares
A definition of Spyware provided by Steve Gibson states "Spyware is ANY SOFTWARE which employs a user's Internet connection in the background (the so-called "back channel" connection MUST BE PRECEDED by a complete and truthful disclosure of proposed back channel usage, followed by the receipt of explicit, informed, consent for such use.
Any Software communicating across the Internet absent these elements is guilty of information theft and is properly and rightfully termed: "Spyware". The term Spyware, in most cases, is synonymous with Adware, and is potentially a Trojan horse program. Spywares can collect the sensitive data (such as the version of Operating System you are running, Browser type, is scripting enabled, what version of Java you are running, Screen size, Available plug-ins, DNS information from your current domain, Run a trace route back to you to find out where you live on the net.) by two varieties of ways:
- By cookies
- By install itself and then execute
By Cookies
Cookies are small files that are placed in your system by web servers when you visit, and can track and record your internet usage. Each time you visit a site, the site checks to see if you have a cookie for that site, if you do then they retrieve your personal settings for the site, if not they deliver a cookie to your machine. Cookies come in a couple different flavors.
Persistent cookies, which are configured to stay on your system for many years using an expiration date, or
"session cookies" that are removed when the session is closed.
By install itself and then execute
Spyware typically is an independent program that runs in the background. Programmers working for Spyware distributing companies can write a routine that can run with system privileges and retrieve information from your computer. If they want to retrieve Word documents from their targets, then they write code that looks for word documents and sends them back to the proper place on the internet.
Conclusion
Malicious Code "Study in Depth" provides a layered approach to securing information and resources, as well as maintaining confidentiality, integrity, and availability of these resources. Viruses / Worms are consistently among most common attacks. In this paper I explain
Malicious Codes, including Trap doors, Trojan horses, and Logic bombs, Zombie, Viruses, Worms and Spywares.
Acknowledgement
I am grateful to my brother “Vahid” for his efforts in editing this paper.
References
D. Moore, V. Paxson, S. Savage, C. Shannon, S. Staniford, and N.Weaver. Inside the
Slammer Worm.
IEEE Security and Privacy, July 2003.
C.C. Zou, L. GAO, W. Gong, and D. Towsley. Monitoring and Early Warning for Internet
Worms. In
10th ACM Symposium on Computer and
Communication Security, Washington DC, 2003.
CERT, “Code Red: Worm Exploiting buffer Overflow in IIS Indexing Service
DLL,” Incident Note IN-2001-8, July 19, 2001
CERT, “Code Red II: Another Worm Exploiting buffer Overflow In IIS Indexing
Service DLL,” Incident Note IN-2001-9, August 6, 2001
Siliconvalley, “'Benjamin' Worm Plagues KaZaA,”
http://siliconvalley.internet.com/news/article.php/3531_1141841
CERT, “Apache/mod_ssl Worm”, Advisory CA-2002-27, Sep 14, 2002
US Department of Homeland Security, “Potential for Significant Impact on Internet
Operations Due To Vulnerability in Microsoft Operating Systems,” Advisory, July 30, 2003,
http://all.net
Symantec. W32.Benjamin.Worm
http://securityresponse.symantec.com/avcenter/venc/data/w32.benjamin.worm.htm
Arce, Ivan and Elias Levy. “An Analysis of the Slapper Worm.”
http://www.coresecurity.com/files/files/12/AttackTrends.pdf
E-Mail Link
Your IP address will be sent with this e-mail
