Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This relates to a hacking incident we had to deal with. The hackers inserted a php file into our system. The directory in question does receive uploads (images) from our cmsadmin. However, all files uploaded through our cmsadmin have the same owner and permissions (owner: theadminsname, permissions: 777). The illegally inserted file, on the other hand, has owner: apache, permissions: 644

My question: Does this difference in owner and permissions give any clue as to how the file was inserted? If they had uploaded the file through our cmsadmin, wouldn't it have the same owner and permissions as other uploaded files? Does the fact that the owner is apache indicate a different route in or did they just change it to that because that is such a common apache owner name?

Another thing. The inserted file was placed in a section of our custom cms. It then provided a form for the hackers to make changes to files in a third party advertising program (amongst other things). It seems odd that they would upload a file into our custom cmsadmin (located in a completely different directory structure from the ad system and with no interoperability between the two) and then use it to manipulate this third party ad program. The cmsadmin and advertising program admin are in different directories and not connected, programmatically, in any way. This all makes me suspect the attack was conducted not through a weakness in our cmsadmin or in the ad system but through a weakness in the webhost.

What do you all think?

share|improve this question

Certainly the file appears to have been uploaded via code running on the webserver. However ensuring that uploaded content is

1) kept separate from the rest of the site

2) stored in a location which is explicitly configured to prevent execution

is a very basic and fundamental security principle: it's your fault you got hacked.

Does the fact that the owner is apache indicate a different route in or did they just change it to that because that is such a common apache owner name?

Probably - what OS is this? You can only chown a file on Unix if you're root - so that implies if they didn't upload it via the webserver then they've got root access - and if they've got root why leave such a messy trail?

The cmsadmin and advertising program admin are in different directories

So what? Unless they are on different servers they can interact (even on separate servers they could).


share|improve this answer
"...The directory in question does receive uploads (images) from our cmsadmin..." So is this logging into an FTP site to upload a file? What about password strength (upper and lower case, numbers, special characters)? How often is the password changed? – jl. Jul 20 '10 at 16:56
Huge red flags: "owner: theadminsname, permissions: 777 " – Dennis Williamson Jul 20 '10 at 17:01
@Dennis - What permissions would you recommend (the owner name was set by the shared host we use... MediaTemple)? – Lothar_Grimpsenbacher Jul 21 '10 at 1:06
@jl - The upload is handled by a file upload form in the admin section of the site. Password strength is average to good (upper and lower case and numbers). It is changed every 6 months. – Lothar_Grimpsenbacher Jul 21 '10 at 1:08
@ symcbean - "it's your fault you got hacked." Yes. I am aware of this and I didn't claim otherwise. The OS is Linux. "If they have root why leave such a messy trail?" Probably because they were operating at script kiddie level and didn't know to clean up? They inserted their Google Adsense code and that is how we were able to ID specifically who was behind this. – Lothar_Grimpsenbacher Jul 21 '10 at 1:17

It is really hard to say anything w/ the info you gave us w/o knowing the setup in detail. There are so many possibilities, that the best we can do is guess.

The best thing you can do is to try to understand what happened. Analyze the log files and see if there is any trace of what happened. As you mentioned, it does not seem to be the job of a pro, but some random script kiddies or even some automatic vulnerability scanner.

Then, after you find out what you want, the best thing is to format the disk and re-install everything.

For the future, well, there are things that you can implement (more or less easily), like intrusion detection systems like AIDE/tripwire, remote syslog, stricter firewall rules (filter inbound AND outbound), better logging/audit trail and alerting, regular manual audit and a review of best practices and use a vulnerability scanner (like Nessus). But if you are paranoid, there is more, much more -- penetration testing, DMZ, segregated networks, network ACLs, RSA security tokens, SELinux/AppArmour,... You get the idea. It is up to you where to stop.

A lot of things, I know. Security is hard.

share|improve this answer

Your Answer


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.