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 [email protected].


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