I had a hack on my oscommerce website recently.
I have put in the relevant security patches but I need to check whether the hacker left any code changes in my files.
What is a good file comparison software for linux?
I need it to scan though the current files and folders and compare it the original default oscommerce installation so I can check the code.

fslint can do a byte by byte comperation and will list duplicates. You can do a diff combo inside a loop as well.

If this is CentOS as in your profile, then use rpm -V to verify the integrity of the installed packages. Check out the rpm man page for options that might be useful.

For things not covered by rpm -V, you've got a problem unless you had previously installed something like Samhain, AIDE or OSSEC and had it create a database of file hashes.

By the way, why do you believe you can trust this machine enough to leave it online?

1 members found this post helpful.

It's not the machine, it's a separate web folder stored on a hosting site.
I need to compare the existing files now that it has been patched. I've virus checked all the files and used an add on called sitemon to check for files with eval system or base64decode in them but I need to check for any diffs now.
Also, oscommerce is not a centos or Linux package as far as I know, it's a PHP downloadable template site isn't it?
Furthermore, I need to get the 2.2 rc1 default from somewhere and am not sure where - OSC don't list it on their website anymore. I need to do this before I can upgrade versions.

Sorry, I don't mean to derail this, but I'm not sure your looking at this the right way. If your site was cracked, that means the bad guys has some level of access to the machine itself, not just oscommerce. They may have only gotten Apache level access, but I would be very hesitant to assume that. Has there been any investigation into how the machine was compromised?

If they managed to get out of your oscommerce folder, all of this is pretty useless.

I'm not familiar with oscommerce, although a quick look at the website suggests you are right. Personally, I find that very disturbing since a PHP misconfiguration can cause a lot of security issues.

Which all brings me back to the idea that since you are using this for commerce, you had better be 100% sure that you have detected and contained the entire compromise, not just the symptoms. Do you have any assurances that you have done so?

2 members found this post helpful.

It's on a shared webserver...hosted.

FWIW, I have just used Meld viewer to compare differences in files and it seems no other files were compromised on the server just 1 php file placed into the images folder. All password etc have been changed so will see if it happens again.

That's fine, but has anybody actually investigated how far this compromise went? Or even how it happened in the first place? Does the hosting service know about this? From the reading I've been doing on oscommerce, it has most definitely had its share of security problems.

That seems to be an exceedingly common symptom of trouble on oscommerce. And the question still stands: What does that script do? How did it get there?

And how will you know if something different is happening?

1 members found this post helpful.

The hosting company doesn't care, they just say use a virus checker and change the ftp login - LOL. I then asked them for the logs and they say they don;t send logs to customers so I am left with having to replace the entire folder or identify any file differences, of which there don't seem to be any.
It is likely this was an admin bypass script but I can't be sure.

Here are snippets of the 2 files:
other in pastedump as it is longer: http://www.pastedump.com/paste/1391

Because of the hosting company, I can't tell what was created and where or whether they were just uploaded but not actually accessed.
The files were created with 777 and I can't see any others like that plus I did a file diff check and it seems to be the only folder with changes (images folder).

The eval, gzinflate, str_rot13 is a commonly used tactic to obfuscate code, as indicated by a simple Google search. This code, may have actually been executed on this system, which is a real red-flag cause for alarm. Furthermore, this code sets "auth" to zero, which suggests an attempt to execute with root privilege and sets error_reporting to 0, which suggests that it is an attempt to get it to execute silently.

One of the primary problems I have with this situation is that a file was uploaded to the server, which presumably was protected with sufficient permissions. Apparently the hosting provider is simply assuming that it was a password crack (btw, saying that you chose a weak password and that it is your fault), and running a "virus" scan. Quite frankly, "viruses" should be the least of the concerns.

There is a real possibility that this machine has been compromised well beyond your web page folder. It is entirely possible that a known exploit was used and determining this will require an in-depth investigation including an in-depth review of the logs, the state of the connections, the validity of the OS itself, etc. In other words all of the things that are done on a possibly compromised system.

It is your responsibility to insist that these things be done and to your satisfaction. Since you are simply a 'web folder' customer, you might want to start with a review of your contract with the hosting provider to see what forms of redress you have with them. To me, it looks like they are being supremely negligent in their duty. I would also consider moving your service somewhere else, unless this issue is resolved to your satisfaction.

At a minimum, you indicated that this file had 777 permissions. May I ask, who the owner of the file was and does this in any way indicate a more sever compromise than an ftp password crack?

1 members found this post helpful.

I don't have any ftp accounts with access to the web root so it couldn't have got there by that route. Also, root access is not possible on the webservers unless a hacker got in by some other route through another shared site.
The host has been hacked before but it seems unlikely it was that route seeing as it targeted the images oscommerce folder.
All files on the server are owned by "You" and so was this file, which means it was likely created through the admin bypass options or somehow hacking in through a script.
The host company refuses to look into it so I can't track it - I can't see any other compromises and have carried out as much security blocking, renaming folders, etc, as I can so I'll have to wait and see.

Probably talking above my pay grade, but 1) I'd look into a new hosting company and 2) if you're accepting and storing credit cards, you could be in for a world of hurt if that information is compromised. I don't know about UK law, but in the US there are some pretty stiff regulations that have to be followed.

I don't think this is an FTP crack/guess. From the little digging I've done so far, oscommerce isn't a particularly secure application, and one of the more frequently reported symptoms is uploading strange files to the image directory. I suspect some poor PHP coding practices are leaving oscommerce vulnerable without any additional help.

1 members found this post helpful.

No, I purposely leave all credit card info and security up to the payment card site, it's better that way.

I don't think it is either, but I think it is what the hosting provider is trying to claim at least as their default answer. The benefit of taking this stance is that it makes it the customer's fault. I also second your motion of get a new provider. This thread really raises the importance of reviewing and understanding the govern terms regarding compromises BEFORE signing up with the provider.

1 members found this post helpful.

I agree, it is the lazy way out. What I also don't like about this arrangement is that qwertyjjj probably has no control over global PHP configuration. If the provider is this negligent about following up on intrusions, is there any reason to be even moderately hopeful that PHP is secured? If there are lots of PHP applications running, I bet they set it so it doesn't generate complaints, which probably means turning off a lot of the security.

1 members found this post helpful.

Also by putting this in the images folder, it prevents any php files from being run:
Options -Indexes

<FilesMatch "\.(php([0-9]|s)?|s?p?html|cgi|pl|exe)$">
Order Deny,Allow
Deny from all
</FilesMatch>