Anatomy of the Web Application Worm



Disclaimer:

This paper is meant for educational use only and should not be used to create, modify, or
produce anything that may damage, or could assist in damaging a computer or network. This paper
is theoretical and was not written to give people ideas on creating internet worms, but instead
make them aware of the dangers worms produce, along with ways to prevent such a disaster. I will
not be held liable for anything you do with the contents of this paper. If you cannot abide by
the terms above please stop reading this document now.



Introduction:

In today's internet people are plagued by viruses, and internet worms that slow down
production, and make our lives more difficult. Until recently worms had been limited to a few
applications or system daemons. This makes fixing the problem rather easy. Of course making
a person install the latest product patch is an entirely different story.



Problem:

Today's internet worm as mentioned above relies on particular system
daemons to be exploited with either known, or unpublished exploits. Usually a worm
will attack a service such as ftp, your mail daemon, or your webserver (see Code Red and Nimda).
Of course one way of stopping a worm from spreading is patching your application so infection
is not possible. Once your application is patched from the hole in question, you are
considered safe. What if a worm had been created to not only infect applications, but find
new holes in them as well. This would mean that the worm would not depend on a machine running
a specific application, and therefore the worm would be harder to stop. Some people decide not
to check for product updates for months for some or all of their applications in use. This can
lead to spreading of the worm for longer periods of time. If a machine was infected by custom
applications written by either staff at the company, or their consultants ,then it may take
some time for a patch to be written and the spread of the worm to stop. On top of this what
if the same machine had two applications infected at the same time?



How it will work:

This section is called "How it will work". I say how it "will" work because I feel that
within the next two years a worm will be created that will devastate the internet. I believe
it will have more of an impact than if Code Red, Nimda, Lovebug, and the "I love you" virus
infected the net at the same time. This section goes into detail on what exactly makes this
worm different along with its potential for damage. I will not go into details on every way
this problem could occur but instead give you an idea of what could happen.



What makes this worm different:

Web Application security has gotten a lot of attention lately as a often overlooked field.
A lot of larger website hacks are due to custom holes found in an application on the website.
Sometimes sites will use prepackaged scripts, or write their own. Benefits of using a
prepackaged web application include getting issued patches when a vulnerability is found.
If you use a custom script this depends upon the person within your company to make and install
the patches. Sometimes people will use older scripts that are no longer supported by the vendor.
This means that if a vulnerability is found it may go unpatched for many months, or never be
patched at all. This leaves attackers with holes in websites they know will go unpatched. This
is obviously a serious threat and website administrators should choose applications wisely.
Many companies will do whitebox and blackbox testing on web applications to find holes and often
times they will create their own patches. People often pay tens of thousands of dollars for such
auditing, and usually get what they pay for. Web Application security is a large field and not
all of the types of threats have been discovered. Of course people have businesses to run and
need these programs to continue business. Some sites will run between one and a few thousand
scripts. Probably sixty percent of these applications are affected in one way or another by a
hole which could allow server compromise, client information to be leaked, stolen identities,
stolen login information, or other serious issues. Currently worms have continued to use a
familiar format which I've listed below.


Example of Typical Worm:

1. Scan for hosts running infected product.
* Check if port is open
* Check version or even try to infect anyways.

2. Attempt Entry
* Execute exploit

3. Download/infect machine with code which will continue the spread of the worm.
* Once in download tools from third party host, or even download
more copies of itself.

4. Issuing a payload.
* Deleting, modification, backdooring, or other related activity.

5. Scan more hosts repeat process.
* Repeat Step 1.


This formula has worked and will continue to be used by virus and worm
writers. Below is a peek at what a web application worm would look like.


Example of a Web Application Worm:

1. Scan for hosts running a webserver.(AKA Open Port 80 is default)
* Check if port is open. If open Start step B.

2. Crawl the site for web applications/forms.
* Find applications and mentioned variables for probing.

3. Issue a extensive list of attacks against each application, and each variable
in that application found.(Between 1 and 10,000 checks per variable)


Examples:

Application 1
http://host/something.asp?variable=value&variable2=value&variable3=value

Application 2
http://host/something.php?variable=value&so-on=and-so-on

Attack each variable within the application using a prewritten list between one and ten
thousand checks that can help continue the spread of the worm. Scanning a large site will
probably find between one and a few dozen holes.


4. Continue crawl of site for further applications. Once every application is either infected
or found to be safe move onto next host. Repeat step 1.

Just because HostA finds HostB to have 1 application hole doesn't mean it has to stop
issuing further checks. The worm could infect that particular application and continue to
crawl a site. You may be asking, "why bother the host is compromised?" The answer is simple.
If a host is running ten applications and two of them are vulnerable, there's a good chance
one of these applications will have some sort of patch issued within a reasonable amount of
time. While one application is now no longer vulnerable the worm still has another point
of entry. Because the worm doesn't target a particular OS, application, or language flaw, it
will continue to spread for long periods of time; perhaps even years. This would affect
c/c++, Perl, Python, ASP, XML, .NET, TCL, PHP,Cold Fusion, and other languages making
this particularly dangerous. This worm would basically exploit the expertise of the site
administrator or coder.



How?:

Tools have been written that crawl a website for sql injection and input validation holes.
www.sensepost.com has released a tool to do exactly this, and it can be found at
http://online.securityfocus.com/archive/82/257635. If a tool can be written to do this why can't
a worm do the same thing except include a harmful payload? Simply put it can happen, and will
happen. Lets say a worm starts at 1.x.x.x and for some reason is written to scan the entire
subnet. After it has been scanned it continues in order. After the complete subnet run is done,
the worm restarts from the beginning. The time it would take for this to happen could be months.
People install new web applications on their sites everyday. So there is a good chance on its
second sweep it would run into thousands of new applications to exploit. The impact would be
obvious, a worm that never dies and continues to find new holes. Obviously writing a worm that
randomly tries addresses is preferred since it would be much harder to stop. Even a randomly
scanning worm or worm copy would hit the same host twice. People may install new software to
stop its spread and they may find themselves reinfected even worse.




Types of Host penetration:

A. Standard .. tricks

Typically web application attacks that allow remote command execution, involve .. tricks to
call particular system files to be executed. This would include semicolon, back-tick, and typical
file path execution attempts. (Example: ../../../../bin/ls|)



B. Sql injection

Sql injection attacks are gaining popularity among attackers. This attack type is starting
to show up in everyday website security. A worm could use sql injection to help further spread
itself. Many tools have been written that crawl a website for such holes. If a tool can be
written to do this why can't a worm do the same thing except include a harmful payload? Simply
put it can happen and will. On top of this many different Database products exist such as MYSQL,
DB2, Sybase, etc...


C. Overflows/Format Strings (For a VERY skilled worm writer)

A more advanced programmer 'may' find a way to add a plug in to a worm to find overflows
in remote web applications. Of course this wouldn't be an easy task, keeping in mind the
different operating systems, chipsets, and offsets one would have to chew through. This
probably won't happen anytime soon but definitely "could" happen if one spent enough time.
An immediate problem would be the size of the worm and the speed in which it spreads/tests
applications. A worm like this would probably end up killing more processes/breaking things
then spread and isn't practical but it is worth a mention.



Impact of the worm:

Obvious impact would be halt of commercial services, bandwidth charges, system performance,
time to patch (Time = Money), upgrades, cost of creation of patches, and various other nasties.
Of course security companies would profit from such a incident , and who knows, perhaps some of
these worms are created by security companies to increase production/sales.



Fix Suggestions:


IDS:

A problem with such a complex worm is that no "Lone" signature would exist. Perhaps some sort
of IDS would check for 2 signatures to help cut back on false alarms. If 2 checks are issued then
block offending host.


Application Security Wrappers:

Wrappers are programs that watch the behavior of a program to see if it is trying to do
something that it shouldn't. Popular wrappers in wide scale use are "CGIWRAP", and apaches
"SUexec" option. These programs/options will execute the scripts and if offending behavior is
found, deny it from continuing. This is one excellent solution to the problem.


Router blocks:

Some routers have the ability to deny a packet based on its contents. As mentioned in the
"Fingerprinting Port80 Attacks" series, attacks leave certain fingerprints. By adding these
signatures into your router block you can stop attacks before they even happen. Obviously
false alarms will come into play and this is not recommended for everyone. For those who
do decide to use these blocking methods remember that adding such signatures are production
dependant and need careful study. During the "code red attacks" many people put these types
of blocks into play. A problem with such as worm is choosing the right signature. Also after
detecting such a signature denying all packets from that host. These signatures would depend
on worm structure.



Conclusion:

I didn't write this paper to give people malicious ideas. I wrote this to show a large
gaping hole that exists that will only be dealt with if each person does their small part.
Currently website administrators and programmer behaviors leave such a threat open.
Unfortunately no single fix exists to stop such a problem, so everyone must watch what types
of programs he/she uses along with who the vendor is. Promptly responding to security threats
also cuts down on such possibilities. By stopping the behavior of choosing poor applications
or vendors we can stop such a threat. I wrote this paper on a Sunday afternoon in March and
for the past week have been deciding whether the risks outweigh the benefits. I feel that by
keeping this information limited we will surely become devastated by such a threat in the near
future. This article also may be useful to the people who do care about security, and are
willing to help cut down on such threats. If you have any questions, flames, or suggestions
email me at admin@cgisecurity.com.


References and Links Mentioned Within:


CGIWRAP:
http://cgiwrap.unixtools.org/

SUexec:
http://httpd.apache.org/docs/suexec.html

PHP-cgiwrap:
http://www.phphelp.com/tutorial/using-a-script-wrapper.html

Attack Signature Examples:
Fingerprinting port 80 attacks part 1 and 2
http://www.cgisecurity.com/papers/

Example of SQL Crawling tool:
http://online.securityfocus.com/archive/82/257635


Published to the Public March 2002
Copyright March 2002 Cgisecurity.com

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.


All Comments are Moderated and will be delayed!