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?
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.
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?
So what? Unless they are on different servers they can interact (even on separate servers they could).
C.
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.