Article #1 admin@cgisecurity.com "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