Actually, no it doesn't. All I have to do is use an extension that isn't in that list (or don't use one at all), make the file executable and run it. You might stop the skiddies with that, but to stop anyone with skill, you would need to remove execution privileges from the directories. For a lot of PHP applications, that actually causes trouble.

1 members found this post helpful.

they can 't run it through a url using that though?
Nothing can be run on the server due to security permissions if correct apart from apache.
safe mode is on also.

However, according to your statement on 4-23 at 03:34pm: If the file had 777 permission, anybody, including the Apache user, could execute the file. If this was really the case, it is a safe bet that the perpetrator actually ran code on this system. Remember, the file was written in a classic manner to obfuscate and decode stuff for execution.

Normally, if the permissions are set properly, no they can't execute code. There was a recent discussion, where I believe the conclusion was to have the files owned by root with read permissions was the best option. Unfortunately, this won't work in a hosted system, or where there are multiple developers and other techniques must be used. This assumes, of course, that the PHP and Apache have been properly patched and are sufficiently current versions, which as Hangdog pointed out is subject to question given their apparent attitude. If these applications have not been patched, they really could be in for a world of trouble.

As an example, there are techniques that will cause Apache + PHP to retrieve a file from a remote hostile host and then inject that code into itself and begin executing it. This doesn't even require skill, as the tools are nearly fully automated. Once they get to this point, they can execute code, watch process, etc. In Linux, it thankfully becomes more difficult to gain access beyond the limited privileges of web user that is used.

1 members found this post helpful.

That may slow them down from running via a url, but if they have gained access via other weaknesses, this could be a moot point. And as Noway2 points out, a lot of this stuff is now pre-packaged for the convenience of all those l33t h4X0rs out there.

Initially they may only be able to run as apache, but if they are truly after the machine, one of their first tasks will be to look for vulnerabilities that allow them to escalate to root privileges. That is why I find the "meh" response from your hosting service so disturbing. Responsible hosting services take intrusions seriously.

1 members found this post helpful.

But that's what I'm getting it, the user cannot run the file through a URL due to the htaccess file unless it is changed or deleted of course which could be run through code.
I suspect this was an automated hack (the site is being continually scanned for hacks as I can see when code injections are trying to be run) as files were placed into the images folder.

I did have one experience with this hosting company before where someone got in through a forum hack B2B or something like that where they managed to change a few thousand sites and put up a picture of the Iranian president but that was all patched. So, it's not out of the realm that they haven't patched things as much as they can but I think they do a pretty good job. If you have a hosting company that runs thousands of sites, I'm not sure how they can control it more than to lock down permissions to the apache user and also use safe mode preventing system commands from being run.

At this point, I would have to ask where you want to go with this investigation, if anywhere at all?

To summarize what we have so far:
1 - files have been uploaded to your portion of a hosted server
2 - the files had 777 permissions
3 - The file contained code that was deliberately obfuscated. It is currently unknown whether or not they have broken the web user jail and gained further compromise into the system.*
4 - The general impression is that this was not a password crack of your FTP capability, as the provider suggested, but there has been no evidence to this effect
5 - The provider ran a "virus" check and found nothing. In my opinion, this is pathetic in terms of response and is woefully negligent on the part of the hosting provider in that it leaves many customers potentially vulnerable and unaware.
* - note if they did NOT crack your password, they must have been able to get some code to execute on the system in order to upload the files. As previously mentioned, there are tools to do this provided you expose the proper vulnerabilities. The question becomes: did they break the web user jail. Evidence is lacking here.

Aside from the above, I don't see that we have much of anything to work with. For starters, we are lacking logs. Second, the system has undoubtedly been operational since the event and either the intruder is successfully entrenched or they feel they got "caught" and moved on, or they are waiting to try again. This means what evidence did exist, may have been destroyed by now.

In either case, the opportunity to properly investigate this situation has probably been lost at this point, largely through both inaction and inappropriate action on the part of the hosting provider.

My thought is that determining whether or not the system has been compromised beyond your web folder should be the top priority. Given the structure under which you are operating, the responsibility for this belongs to the hosting provider. I think the only thing left for you to decide is whether or not you believe that they handled the situation adequately, and if you wish to continue to do business with them as a result of their handling.

2 members found this post helpful.

Well I don't know PHP. However, I did the common eval to print trick used to decode javascript and the first thing I decoded was for sending email to the attacker's address. The variables with obfuscated content use a function for the same kind of decoding.

$port_bind_bd_c = A simple backdoor written in C. "Welcome to b374k shell && /bin/bash -i"
$port_bind_bd_pl = As you might guess another simple backdoor written in Perl.
$back_connect & $back_connect_c = Simple Perl and C programs for back connections. The Perl one (first) automatically runs the standard uname -a; id.
img.jpg = An IRC bot written in Perl.

As you can see from the PHP script, it also attempts to compile/execute those backdoors.

1 members found this post helpful.

Well, I have no control over the port bind and other things or whether the attacker got into the servers, that's up to the host company.
I'm most concerned about whether they changed any of my files and it seems not so it's more than likely they got in through the oscommerce security flaw, which has now been fixed...if the file was in fact executed at all.
I can only wait it to see if any more files get uploaded as there is nothing the host company will do apart from to say wipe out the folder and reload from your backup.

So I have to know. What hosting company is this? I want to make sure I stay away from them...

It's up to both of you. A proper security model requires that all parties be concerned.

Good that you know what went wrong. Bad that you don't even know if the file was accessed. Let me put it to you this way - if you don't have access to your traffic logs, drop that company. If you look at the logs, it will likely have been accessed, but we can't know for sure without access. If the script was accessed, probability of being trojaned is pretty high.

I'd say wipe your contract with that company. That's a pretty irresponsible stance to take.

I don't know what is more disturbing. The big provider not caring about all of their customers, or the OP not caring about his provider, server and his own customers.

I care about the customers but like I said there is no problem in the PHP files and I don't store any sensitive info on my site or db.
To hack the machine the guy would have to have root privileges, which isn't possible through the architecture of hacking via a PHP script on apache.

Seriously? Hack web app, get system access as Apache user, use local privilege escalation to get root...

Using a certain freely obtainable Linux distribution known for penetration testing, it is easy for even a script kiddie to analyze your system and if sufficiently un-patched cause your web server to upload attack code and begin executing it. At this point, they would have shell prompt access to this system and can easily move around amongst the different processes and perform tasks as an unprivileged user.

From what you have posted it looks like you are assuming that it was a security flaw in OsCommerce that has now been patched. I state this because I have not seen any evidence posted regarding how you have reached this conclusion. So far, this thread has been a lot of supposition, not facts. Unless there are facts and details for us to analyze, which so far you have been unable to obtain, there is little to be gained from this thread.

Whether or not to continue to operate with this provider is your choice.

2 members found this post helpful.

I think Noway2's summary pretty fairly wraps up where this is now. Without the cooperation of the hosting company, there simply is no way to tell if the uploaded file was ever run or not. It is pretty clear from qwertyjjj's postings, that information simply will never be available. It is probably also impossible to give qwertyjjj any sensible advice on securing the site from here out. There are just too many unknowns that can't be investigated without the help of the hosting company.

@qwertyjjj

I know you came in here with a simple request, and from your standpoint it might look like this spiraled out of control. What I would say is that from the standpoint of many of us, you were asking for a band-aid to cover a cut whilst ignoring a pretty major hemorrhage. You seem to have some pre-conceived notions about what crackers can, and cannot, do that simply don't jibe with the experience of a lot of us. Between that and the irresponsible behavior of your hosting company, a number of us are hearing very loud alarm bells. That is why this thread has gone this direction.

2 members found this post helpful.