2010-08-01
Abstract
Any researcher serious about regularly researching exploit frameworks needs a special lab set-up to work with the PHP, MySQL and web server components commonly found in such kits. Mark Davis documents how to create LAMP and WAMP servers and how to approach the study of such threats in a local lab.
Copyright © 2010 Virus Bulletin
A myriad of exploit frameworks (kits) exist to support drive-by attacks in the wild. Popular kits include Eleonore, Fragus, Liberty and countless others. As identified in previous articles [1], behavioural testing of these kits can be tricky. However, it is possible to obtain select files and/or demonstration kits, allowing for more qualified and in-depth research than remote behavioural testing alone. Any researcher serious about regularly researching such threats needs a special lab set-up to work with the PHP, MySQL and web server components commonly found in such kits. This article documents how to create LAMP and WAMP servers and how to approach the study of such threats in a local lab.
(L/W)AMP is an acronym for the operating system (Linux or Windows), Apache (web server), MySQL (database) and PHP (scripting language). Most kits use these components to install on a remote server. Some do not require MySQL, saving data to a text file instead. However, this method is inherently flawed since the file names can be predicted or found in configuration files or images posted by bad actors, making it easy for individuals to harvest such files remotely. MySQL is commonly used because it is fairly simple to include in a kit. A large number of examples of such implementations can be found in demonstration kits in the wild.
LAMP/WAMP server software is entirely free for both Linux and Windows. This makes such packages widely available with many implementations, lots of online support, and at the right price for financially motivated fraudsters. It is also priced attractively for tight-budgeted security experts performing in-depth research on such threats.
A WAMP server is preferred for the evaluation of drive-by attacks. (A WAMP server set-up that is simple to install on a Windows computer will be revealed in detail later in this article.) Additionally, since it is Windows, you can easily navigate to the local kit (once configured) to trigger an attack on the same system. This enables rapid interaction with the kit and the ability to monitor how payloads and exploits work, and how the database populates once the system is triggered. If a LAMP server is used, a separate NAT’d Windows system must be implemented to perform the same actions. While this is not difficult, it is an additional step that can sometimes be troublesome in virtual environments that don’t always work smoothly with networking protocols and configurations.
WampServer [2] is a pre-compiled package that installs all components required for the server on a standard Windows computer. This is an outstanding resource since not all versions of the various components are compatible with one another. Pre-compiled packages are tested and known to work well together. Because it’s an integrated installation package, the user simply clicks through a few screens to install the server.
If WampServer is not desired, a WAMP server can be configured manually by downloading packages from each respective software site for the various components of the server. Alternative servers can also be used, such as the Abyss web server [3]. Naturally, such installations require more time but also offer increased flexibility for customized lab requirements.
It is important to note that the tutorial below is based on a first-time installation of a WAMP server from WampServer.com. If an older version of a WAMP server exists on the system, data should be backed up, WAMP removed, and the upgrade then installed. WampServer also recommends that the WAMP directory be deleted prior to installation of the new package.
Using a normal high-speed line, WampServer (~16MB) can be downloaded in a couple of minutes or less. The package used in this example (WampServer 2.0i [07/11/09]) includes the following components:
Apache 2.2.11
MySQL 5.1.36
PHP 5.3.0
Click on the opening screen, accept the agreement, go with the default directory installation (c:\wamp), select additional icon options for Quick Launch and Desktop if desired, and click install.
After the installer has run for a while the user selects the default browser to be used with the kit. I prefer to use Firefox since various add-ons are available that can be used in the evaluation of exploit kits locally – these are not available in other browsers.
PHP mail parameters are also configured during installation. SMTP is set to localhost by default, with email at you@yourdomain. This can be configured if desired. A mail server can be configured or scripts utilized to perform local mail honeypot operations when interacting with a kit or payload. However, I generally leave this as a default since testing of email functionality is not usually required for the testing of exploit frameworks.
WampServer doesn’t run automatically on its own – it must be run on demand, or configured to run with Windows startup or scheduled as a task. If using a virtual machine as a dedicated WAMP server, simply drop a shortcut for the WampServer (c:\wamp\wampmanager.exe) into the Startup folder.
Now the WAMP server is installed correctly and running in memory. Congratulations, you have a web server, MySQL data, PHP scripting support, and the ability to install local web scripts and kits for testing in a lab!
Locate the WampServer icon and LEFT-click:
This reveals a complete menu of choices:
Browse Localhost (your local web server space) and phpMyAdmin are the first two options in the WampServer set-up. Either can easily be pulled up using the default browser assigned during set-up.
These first two links are very helpful in a WAMP server testing environment. Localhost points to the www directory on the local machine for the Apache server installed. This is normally located at c:\wamp\www\ and contains index.php. Notice that one of the menu options is for the www directory, which is most handy for a security researcher. Simply left-click on the WampServer, select www directory, drag and drop a kit or script to test into the www space or sub-folder and it’s on the local server.
Once a kit is copied to the www space, installation of the kit begins. This is covered in more detail at the end of this article. It involves configuring the database and users via phpMyAdmin. The rest of the WampServer options for configuring specific components of the installation are not normally required for evaluation of an exploitation framework.
Interested parties should visit the WampServer website for additional support. A forum exists, as well as other resources that are of great value for users having issues with installation or customization of the server.
A WAMP server is very powerful but additional components are often required to fully analyse an exploit kit. The following is a brief outline of suggested tools:
Wireshark – used to sniff local traffic when triggering the server via the local browser. This traffic can help identify obfuscation and string details within packets useful in both behavioural testing and netflow signature development.
Malzilla – a useful tool for working with deobfuscation of scripts. A researcher can also model what a remote website might look like if it hosts an exploit kit being tested locally.
Specialized analysis tools – tools like Trillix for analysing Flash files and djdec39 for analysis of Java files.
Cygwin – brings the best of Linux to Windows, but with the price of a large number of files and disk space required for this unique package. Cygwin is a slick way to get your favourite Linux tools on Windows, such as ‘file’, along with Perl and Python (which always seem to work better in Linux than Windows – let the debate begin!). Such utilities are helpful when looking at embedded payloads and file obfuscation in a kit, using scripts to analyse exploit files (like PDF files for example), plus you have the factor of a dual OS system to help you leap tall buildings and impress others.
Didier Stevens’ PDF analysis tools [4], written in Python, work well within a Cygwin environment on Windows.
OllyDbg is great for debugging and some reverse engineering if a complete analysis is desired, and/or for interaction with payloads.
WAMP servers are not recommended for analysis of a payload. Snapshot tools and others are very time consuming – both within the WampServer and also within a VMware environment – due to the large number of unique files created within such a system. If payload analysis is needed, extract the payload and place into an environment uniquely designed for such analysis. The goal of a WAMP server involving a payload is to capture netflow data and/or interact with a kit to monitor how it populates a database based on how exploits are triggered.
Additional vulnerable packages may also be installed on the WAMP server in order to trigger common vectors of attack if a diverse set of behavioural triggers is desired. This can be very useful when tracking exploits against default numbers often assigned to specific vectors – such as MDAC, which is sometimes referred to within an exploit URI as ‘1’ or some other number. Oldapps.com contains a host of vulnerable packages of which several versions of each may be required to properly trigger specific exploits of interest. Additionally, configurations within the kit or scripts may be required to limit global infection routines to trigger a specific vector of interest. Packages to include, likely as installers on demand with a core set installed in a snapshot, are listed below:
Adobe Reader: http://oldapps.com/adobe_reader.php 8.x, 9.x, 9.2x (default), 10.x
Adobe Flash: http://oldapps.com/flash_player.php 8.x, 9.x (default), 10.x
Java: http://oldapps.com/java.php 6 update 10, 6 update 16 (default), Java 5 update 18
Internet Explorer: http://oldapps.com/internet_explorer.php 8.x, 7.x, 6.x (default)
Firefox: http://oldapps.com/firefox.php 3.6x, 3.0x (default)
WinZip: http://oldapps.com/winzip.php 9.x (default)
(The default recommendations above are selected subjectively for common vectors of testing of current vectors in the wild.)
Select your favourite *nix solution to install the packages needed to build a LAMP server. Ubuntu was used in this instance due to the popularity of the system and ease of use for compatible installations and set-up. The Synaptic package manager and terminal-based solutions were used to perform a LAMP server installation. While slightly more complicated than a WampServer, which includes compatibility checks, LAMP servers can be created in less than an hour by an experienced *nix user.
Synaptic package manager installs:
apache2 – Apache HTTP server metapackage
apache2-doc
php5 – server-side, HTML-embedded scripting language (metapackage)
php5-sqlite
php5-mysql
php5-cgi
phpmyadmin
mysql-server
Sometimes Synaptic package manager installations don’t go as planned. Restarting the system and reinstalling may be required to get it to work. If that fails, try to perform a complete removal, restart, and then reinstall.
Naturally, a host of additional packages may be useful in a *nix environment for testing exploit kits including Python tools like those of Didier Stevens. However, since it is based on *nix instead of Windows, a LAMP server is limited to the exploit files and the framework instead of behavioural testing and payloads on the same system. Thus, a hostile PDF can be analysed but the dropped file must be extracted manually or triggered on a remote Windows system to develop that side of research when working with a LAMP server.
Once a WAMP or LAMP server is set up properly, the following basic procedures are used to install a kit for testing.
Configuring the kit:
Change permissions on the kit directory if necessary to enable access/read/write. (This is not normally required but may be within a LAMP server.)
Locate the configuration file and review for database credentials/set-up required.
Use phpMyAdmin to create a user with admin rights to the database.
It’s a good idea to create a universal login for both the database and the kit control panel, then change the configuration file instead of the phpMyAdmin and MySQL configurations each time. Making changes to a configuration file is trivial using Notepad or Gedit with admin/root rights (e.g. sudo gedit ‘/var/www/kit/config.php’).
Look for install.php or similar files that are used to install the kit.
This file normally works with PHP to automatically create the database and appropriate tables used with the kit. Use phpMyAdmin to validate the creation of a new table once install.php is run.
Once a database is created you’re ready to see if you can log in!
Browse to the kit via pages like admin.php or statistics.php. Authentication is commonly required, so work from what you found or entered into the configuration page. Sometimes this can be a bit tricky if encoding is used, such as the SHA1 value of a password, etc.
Snapshots: Use snapshots within VMware to save loaded kits for faster referencing and update checks. For example, if you finally get a kit working after 50 minutes of work, snapshot it and save it and back up the images on the host. This enables the researcher to quickly load a kit for later update checks or evaluations.
Behavioural analysis of local exploit kits is clearly complex and difficult for some to accomplish. Fortunately, the WAMP server components highlighted in this article provide security researchers with a fairly simple method for properly installing and configuring such a server. Use of the system is much more complicated since so many dynamic analysis components are then available to the researcher. When properly used, WAMP servers have proven to be an excellent environment in which advanced exploit kit framework analysis may be completed. The next part of this series will provide a walk-through of how the set-up can be used to look at an exploit.
