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?

  • Evidently there are. Do you have a more specific question? – Bojangles Nov 19 '11 at 18:12
  • 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 Nov 19 '11 at 18:16
  • Who oened he ditectory the file was in? – Zoredache Nov 19 '11 at 18:39
  • apache owned the file upload directory, where the attacker (temporarily) stored the code. root owned the directory where the changed file was. – anon coward Nov 19 '11 at 18:45
  • possible duplicate of My server's been hacked EMERGENCY – Shane Madden Nov 21 '11 at 6:02

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:

$login = ""; //Login
$pass = "";  //Pass
$md5_pass = ""; //If no pass then hash
// 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.

  • 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 Nov 19 '11 at 18:47
  • [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. – anon coward Nov 19 '11 at 18:48

Just a general tipp on how to avoid this in the future:

Patch your server. CentOS 5.4 is EoL for quite long now. We are currently at CentOS 5.7!

Note that there was an upgrade of PHP as well in CentOS 5.5.

This PHP upgrade contained a lot of security fixes.

For a webserver you should use (at least) three users and one group:

root - Owner of the main process (not neccessary if you use a non priviledged port)

wwwrun - the user that the httpd-sub-processes are run as, group www

wwwadmin - the user who has write-access to the web-servers files (normally htdocs or in your case - the php-base-dir), also group www.

The group www should have read, but not write-access to htdocs.

Pick your own user/group names at will this is just an example.

You can also harden the httpd by disallowing TRACE, TRACK, PUT and DELETE (if your application allows for it). This can be achieved with mod_rewrite.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.