Blog

Web-Attacker Exposed

While reading our previous posts, you may have noticed quite a few references to something called the Web-Attacker toolkit. The reason we have mentioned Web-Attacker so frequently is that nearly one-third of the malicious websites we discover are using it to infect their victims; it is incredibly popular. Take a look at an introduction to Web-Attacker, translated directly from the Russian website that sells the kit:

Dear Friends! We would like to offer you multi-component exploit Web-Attacker, that realizes vulnerabilities in the internet browsers Internet Explorer and Mozilla Firefox. With the help of this exploit you will be able to install any programs on the local disks of visitors of your web pages. In the foundation of work of the exploit Web-Attacker, there are 7 already-known vulnerabilities in the internet browsers.

Objective of the Exploit: Hidden drop of the executable from the deleted source to the local hard drive of the site visitor.

Simply put, Web-Attacker is a Perl CGI script designed to exploit website visitors and execute code on their local computer. The script may be purchased from a Russian group for $300 or upgraded for $25. Once it is purchased and installed, the buyer simply needs to provide some type of malware (keylogger, spyware, and the like). Check out one of our previous alerts for a more complete overview:

http://www.websense.com/securitylabs/alerts/alert.php?AlertID=472

The above information is nothing new; Web-Attacker has been around for well over a year now. But just when we thought we knew practically everything there was to know about the toolkit, we stumbled across something incredibly interesting: its source code. So, guess what our analysis today is going to focus on? But before we jump into the source code, I am going to give a brief overview of the components of Web-Attacker and where the script we discovered fits into the picture.

Web-Attacker Components

go.php

This "begins" the attack. You will typically see this file loaded from within a hidden iframe in a compromised page. It performs some basic checks and then simply forwards to the next step, with the homepage parameter.

ie0609.cgi

This is the heart and soul of Web-Attacker. This is the script for which we recently obtained the source code and is where the majority of Web-Attacker's functionality lies. This particular version is the 2006 (06) September (09) release. The earliest we are aware of is ie0502 -- 2005 (05) February (02).

• Records user statistics (timestamp, OS, browser, country, and so forth).
• Delivers the exploit requested by demo.php
• If the exploit is successful, provides a malicious executable
• Records exploit success/failure statistics
• Displays collected statistics in HTML graph/table format

demo.php

Contains a block of obfuscated JavaScript. This JavaScript performs several browser checks to determine which exploits should be attempted and then redirects back to ie0609.cgi.

*.dat

These dat files contain the actual exploit code to be used. They are accessed by ie0609.cgi and are typically not directly available externally.

Typical Attack Walkthrough

1. User visits a compromised webpage containing a hidden iframe that loads go.php.
2. go.php redirects to ie0609.cgi?homepage, which redirects to demo.php.
3. Obfuscated JavaScript from demo.php determines which exploit should be attempted and redirects to ie0609.cgi?type=<EXPLOIT_TYPE>.
4. Based on the value of the type parameter, ie0609.cgi returns the requested exploit. Each exploit differs but attempts the same action: execute the data downloaded from ie0609.cgi?exploit=<EXPLOIT_TYPE>.
5. With the exploit parameter, ie0609.cgi returns the malicious binary to be executed. The attack is complete.

Note: The above are all default file names. They are often changed.

Now that we all have a basic understanding of how Web-Attacker operates, it is time to dive into the source. The code shown in the screenshots here has not been modified, aside from the blurring in a few sensitive areas. There is a lot of raw code displayed here, so a basic understanding of Perl syntax may be helpful, but not required.

Modules and Globals

Web-Attacker starts off like many other Perl scripts, by loading a few modules and defining global variables. It may not be technically accurate to refer to these variables as globals because the author seems to disapprove of lexical scoping. Everything in this script is a global variable.

This script is made to be portable; there are only four modules required here: DB_File, DBI, Fcntl, and CGI. These are extremely common modules and should be available on nearly every Perl installation.

I have blurred out the value of $Password_correct because it is a plain-text string of the default password used to access the Web-Attacker control panel. Another interesting variable here is $BAN_Time, with a default value of 20 minutes. This determines the amount of time that must pass between exploit attempts, and serves as its built-in DOS protection to keep one client from flooding the Web-Attacker installation. We'll look at it closer later on.

The script uses either DB_File or DBI, but not both. It lets the owner choose if he or she wants to store statistics in a flat database file or in MySQL. This behavior is controlled with the $use_mysql global. Should MySQL be used, another set of variables is required to establish the database connection.

Sniffin' with CGI

Several variables are copied out of the CGI environment. You may notice that my IDE has underlined $UserLanguage and $ScriptURI. This is because these two variables are not referenced anywhere else in the script. For some reason, the author retrieves their value here but never makes use of them.

Using the $UserAgent variable, the author performs very rudimentary user agent sniffing in an attempt to identify the browser being used by the user. This is not foolproof, but it does a good job of flagging the browsers that everyone cares about. This is stored purely for statistical purposes and has no effect on which exploit is attempted.

With a continuation of the user agent sniffing, the script now attempts to identify the operating system being used. Again, this is for statistical purposes only.

Next, a timestamp is created and a UserID is generated. As we'll see later on, this UserID is used to enforce ban time and identify unique visitors to the site. Take a closer look at how the $UserID value is generated, because this value is extremely important. Can you spot a problem?

The script generates the ID by calculating the CRC32 value of the string "IP + User Agent / OS + Day + Hour". This effectively means that each user will generate a new ID every hour. This could reduce the accuracy of the statistics generated, because a single user has the potential to be "infected" 24 times per day, provided that the user visits the compromised site every hour. Additionally, this breaks enforcement of the ban timer and allows someone to force generation of a new ID by manually altering his or her user agent.

Small segue here: Take a look at the two functions used to generate the CRC32. This doesn't look anything like the rest of this author's code, does it?

I thought it would be fun to track down where the code came from. It appears that it was lifted right out of the Digest::CRC32 module. Directly including the functions helps the author avoid a module dependency, at the expense of a minor copyright violation. ;-)

Features galore! Country lookups are performed with the help of either the Geo::IP (commercial) or Geo::IPfree (free) modules. These modules are used later to determine which country a victim originated from.

Default Action

That is it for the global stuff. At this point, you must give the script a CGI parameter if you expect it to do anything useful. The first parameter provided is stripped off and stored in the $Action variable. A second parameter, $UserParam, is set but never used. Let's take a look at each of the available actions.

First, the default action, if no parameter (or an invalid parameter) is provided, is to print a basic logon page. Enter a password, get some stats!

In a browser, it looks something like this:

Homepage Action

We saw this parameter earlier, in step ii of our walkthrough, and all it seemed to do was redirect to demo.php. Let's take a closer look now and see what else was really happening.

The homepage action begins by performing a country lookup. Immediately afterwards, it checks its database (either MySQL or the flat DB file) to determine if this UserID is new (keep in mind, a new UserID is generated every hour). If the UserID exists in the database, the database timestamp is compared to the current timestamp and checked against the value of $BAN_time.

If this is a new ID, or the ban time has expired, the script prints a redirect header to demo.php. Otherwise, a blank HTML page is returned.

The same code we see here is used in several other locations to check if an action should be performed for the given UserID.

Type Action

As I mentioned in the beginning, demo.php contains JavaScript that redirects the user back to this script with a type parameter. Closer inspection of the code behind this action reveals that here is where the really nasty stuff happens. The script checks the value of type to determine which exploit should be delivered. The valid parameters for this particular version of Web-Attacker are:

• MS03-011 -- Microsoft JVM Vulnerability
• MS06-014 -- MDAC Vulnerability
• MS06-055 -- VML Vulnerability
• MFSA2005-50 -- Firefox InstallVersion Vulnerability
• MS06-006 -- Firefox Windows Media Player Plug-in Vulnerability

A value of MS03-011 causes a JVM exploit to be delivered, while a value of MFSA2005-50 delivers a Firefox exploit, and so forth. Each of these exploits contains specially-crafted shellcode that will re-invoke this script with the exploit parameter.

There is a more recent version of Web-Attacker in the wild, known to exploit MS06-057. This section of Web-Attacker is constantly updated as new vulnerabilities are detected and older vulnerabilities decrease in their effectiveness.

Exploit Action

It's time for the payload! If the exploit delivered above was successful, the script is invoked a third time with this action in order to retrieve the malicious binary that should be installed. This action does double duty by also making an entry in the database to record which exploit was successful.

Password Action

The password action provides access to the control panel. This action calls the function parse_uid_statistic on each UserID in the database to generate statistics. Once it is complete, the following statistics are displayed in the browser:

• Individual exploit infection rate (percentage per exploit)
• Operating System infection rate (percentage per OS)
• Browser infection rate (percentage per browser)
• Geographical infection rate (breakdown by country)

Notice the top-notch authentication. If $Password equals $Password_correct, you're good to go!

Note: If you happen to be developing a web application that requires authentication, this is a good example of how it should NOT be done! ;-)

DATADILE? How did that slip past the QA department?

Here is a short excerpt of what this looks like on a live Web-Attacker site:

Administrative Actions

Finally, there are three actions that are used for administration. All three implement the same authentication method used by the password action. These actions would typically be used only by the person installing the Web-Attacker toolkit.

Install: This action creates the MySQL database schema, where statistics are later stored. We catch a glimpse of the table design here, giving us a quick overview of exactly which statistics are stored.

Dismount: The opposite of install, this action drops the current database.

Clear: Wipe out all of the stored statistics for a fresh start.

I hope you enjoyed this behind-the-scenes look at one of the most popular exploit kits on the web. The code certainly is not what you would call "elegant," and it honestly is not incredibly advanced. However, it is amazingly easy to use, has plenty of features, is frequently updated, and just gets the job done. Apparently those four things are the recipe for a wildly successful exploit toolkit.

Researcher: Alex Rice, Websense Security Labs