Apache/PHP root exploit

Question

Because of insecure handling of uploaded files, an attacker was able to run php code on my server (CentOS 5.4) That issue has been fixed, but while he was connected he appears to have modified a file which was owned by root (file perms 644), replacing it with one owned by the apache user. Are there apache or php exploits out there which could have enabled this?

In response to the first comments which request more information - it would have been bad enough for the attacker to be able to upload files to my server and perhaps send users to malicious content on my domain. However, he/she was also able to edit files. The result of this was that my website was modified in such a way as to email all info from new user registrations to a gmail address.

I am not sure where to start looking, and am requesting help in this. Other than the obvious directory permissions (do not permit file upload to directories where php code may be executed; do not execute php code in users' upload directories) I don't know what to change to ensure this cannot happen again. It was my understanding that if a file was owned by root, no other user could change it. Obviously this was not true.

If it was your server, where would you look?

Solution

It was my understanding that if a file was owned by root, no other user could change it. Obviously this was not true.

If the permissions for this file are writable by "group" or "other", than anyone in that group (like if it was "apache") or any user (in the case of "other") can overwrite it and/or change the ownership.

The other thing I'd look for, since this is a file injection, is php files that aren't supposed to be there, or files that you didn't create. They could be named something relatively benign like "index.php" or "help.php", but if you look at the code, you'll see large globs of base64 encoded data (to obsfucate what it is actually doing). Look also for "wsh.php".

Sometimes these files are "web shells" written in php that give a shell-like access to the filesystem, using the permissions of the php/apache process. They'll be able to edit/delete/upload/copy/move files around including ones that have been owned by root but with bad permissions (see first paragraph).

These files could look like this:

<?PHP
             //Authentication
$login = ""; //Login
$pass = "";  //Pass
$md5_pass = ""; //If no pass then hash
eval(gzinflate(base64_decode('7b17f9vG0TD6d/v75TusEaYmE5KiZOcmWXJkSY59alt+JLlpXtmH
// etc etc 

Maybe you can do something like:

find www_root -name '*.php' -exec grep -l 'eval' {} \;

And look at those files and make sure they're legit.

Comments

[Bojangles]

Evidently there are. Do you have a more specific question?

[Admin]

sorry... I guess it's obvious that I am new here. Please advise on how I would be able to move the question elsewhere? I'll add more to the main description as well.

[anon coward]

apache owned the file upload directory, where the attacker (temporarily) stored the code. root owned the directory where the changed file was.

[ravi yarlagadda]

possible duplicate of My server's been hacked EMERGENCY

[anon coward]

As I mentioned in my original post the permissions were 644. This is only readable by "group" and "other", and is required for apache to be able to read the file for serving up to the web. I've already done a search similar to what you suggest, and I found the "web shell" you mention. However, I tried to use it to edit a file owned by root and no changes were saved.

[anon coward]

[apologies for the double post here - enter key doesn't give me a paragraph break] The access logs on the web server show that other php files were present and served up with a 200 response. So my assumption is that the attacker uploaded some root exploit, executed it, and deleted it.