Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

migrated from stackoverflow.com Jan 24 '10 at 5:03

This question came from our site for professional and enthusiast programmers.

3  
WHY do you have a public website with 777 permissions? –  SLaks Jan 24 '10 at 4:28
    
What web host are you using? –  SLaks Jan 24 '10 at 4: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 4: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 4: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? –  coder_ Jan 24 '10 at 4:39
show 3 more comments

2 Answers 2

up vote 6 down vote accepted

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.
share|improve this answer
    
The de-obfuscated code makes much sense. Is there any tool to do this? –  coder_ Jan 24 '10 at 15:32
    
I meant a tool to de-obfuscate code :) –  coder_ Jan 24 '10 at 19:14
    
I used Polystyle (polystyle.com) to format the code property and then manually de-obfuscated some sections. –  Andrew Moore Jan 24 '10 at 23:55
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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