4

I woke up to find that all the folders in my shared-web-host with 777 permission had two new php file. The code inside the file could not be read - here is the decoded version: http://pastie.org/779226 (what the...?) That code was injected even inside some PHP files.

I am at a loss as to HOW someone would do this? I know having 777 permission is not the smartest thing, but how did they get into my folder system in the first place.

I'm just a client side programmer, would be great if I had some advice on how to keep this from happening in the future.

Cheers.

coder_
  • 203
  • 3
  • 6
  • 3
    **WHY do you have a _public_ website with `777` permissions?** – SLaks Jan 24 '10 at 04:28
  • What web host are you using? – SLaks Jan 24 '10 at 04:31
  • This can hardly have happened from outside. 777 permissions apply to the server's internal file system only. Either some other security hole was used, or it came from the inside. – Pekka Jan 24 '10 at 04:34
  • Um, sure it could have Pekka. If a file or directory is writable by the process running PHP (apache usually), then it can most certainly be written to by "the outside". – hobodave Jan 24 '10 at 04:38
  • @SLaks: That's another story. I am having to use that permission cause some of my php scripts produce .jpeg images and they are saved inside this folder. I'm not sure how to achieve this without 777 permission, cause as soon as the write permission is revoked on the folder, the php file cant write the jpeg image into this. What am I doing wrong here? –  Jan 24 '10 at 04:39
  • You should store the JPEGs in a separate subfolder and deny it execute. – SLaks Jan 24 '10 at 04:41
  • Denying execution won't prevent the webserver from running scripts. I however +1 on the fact you should write them to a different folder with special (writable) permissions, and have everything you can under read-only permissions for your webserver. –  Jan 24 '10 at 04:45

2 Answers2

8

Here is the de-obfuscated version of the script: http://pastie.org/private/iobgt7aetg8mezoepucsg

The code seems to include external PHP code from another website and collects information about your visitors while doing so.

One way this could of occurred is that you are allowing file uploads on a directory accessible from the outside. Doing so without proper validation is dangerous as a malicious user can upload a PHP file (using your image upload) with malicious code. If the web-server is not configured properly, the code will run when requested.

In order to avoid such problems, make sure that:

  • PHP processes are run by a limited user.
  • Files which do not need to be edited are set to be writable only by the owner (0644 or 0744 depending if you require the execute bit or not).
  • Only set the upload directory to writable.
  • Try to use an upload directory that is outside your webroot. Then use readfile() to serve the file.
  • Validate the files. If you want your form only to allow images, validate the magic bits and make sure that the image is valid. This is a hugely overlooked step. Same applies to any other format. Do not rely on the file extension or the mimetype sent by the client. Check the actual file content.
Andrew Moore
  • 562
  • 1
  • 5
  • 15
2

There are at least 2 possibilities I can think of:

  1. They found your FTP password
  2. They found a flaw in your PHP software

To prevent them from happening:

  1. Use a complex password (minimum 9 characters, mixed case, digits and special characters)
  2. Run from 777 as if it was the number of the beast; try to give the webserver no more than read permissions on your scripts, and give special permissions to the (hopefully rare) folders/files where it has to write.

If you have access to some logs (the access logs from Apache and the FTP logs from whatever FTP server your website runs), that could prove helpful to see what happened.

It's doubtful that they managed to do so many changes with a simple flaw in your scripts, unless it's a really wide-open flaw (like you have an unprotected script only wrapping fopen() over whatever the user likes), so I'd check the FTP log in priority.

zneak
  • 328
  • 2
  • 14