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

Good job on catching this exploit so quickly.



We got the email and indeed located the files.



The atos & hsbc php files and associated directories have been deleted as per the instructions leaving only questions, the answers to which may may be of interest to the community should they be answered.




  1. What was the attack vector?

    My working assumption is of course the atos and hsbc payment files we were instructed to delete. If this is correct, what was the behavior of those files that allowed infection?


  2. How can we mitigate a repeat of the same exploit?

    This may well be answered by a clear explanation of the first question, however, it is still a question worth asking pending a detailed description of the methodology used to exploit the attack vector.


  3. To quote the email:

    Summary

    The update fixes a vulnerability that can result in a remote unauthenticated attacker executing arbitrary script in the context of the end-user’s browser session.



    What update is this referring to? I understand it to mean the fix of deleting the files. Is that correct?



    Thanks to who ever has the time to answer,



    Fleety

From what I saw in looking at the resulting malware and the payment methods…


  1. The entry was via an exec() function used in both of those payment methods. 365.php also uses exec() but explicitly calls 'perl' with arguments versus a REQUEST parameter.
  2. The payment environment is the primary area where the cart allows callbacks so it is most vulnerable. However, eliminating exec() (and system and related functions) from the payment scripts will prevent this particular vulnerability from recurring.
  3. The update is the notification to remove the resulting malware files (thumbs.php and test.gif) and to remove the entry points.



    I had a discussion with someone today about this and they felt (and I concur) that the payment scripts should not be installed in a manner where they are all active. Instead, some kind of enabling system should exist to ensure that an admin has consciously installed the providers they want available. I.e. they should be enabled as addons (or something similar).



    Cs-cart has always been excellent about identifying and communicating about how to eliminate security threats and they seem to discover them quickly. However, I doubt (but would love to be wrong) that you will hear a lot of discussion from cs-cart themselves on this topic.

we were also attacked in 3 of our websites.

we were lucky to be immediately informed by our hosting company that someone was trying to upload a script to our server.

for the record we had a similar call from our hosting company about a month ago…



The unanswered question is : how did they know the admin page URL for the cscart installations?

please note that the files to be deleted also exist in the var/updates folder of cscart.

[quote name='pvein' timestamp='1401175225' post='184346']

The unanswered question is : how did they know the admin page URL for the cscart installations?

[/quote]



I guess they just access the atos.php or hsbc.php directly to upload a foreign php file to a writeable directory.



Crappy thing is, it looks like this vulnerability has being in cs-cart since 2.x . For me to really trust it Iooks like a nuke and reinstall from scratch

Hi!



We host about 25 cs-cart installations on our server. About 20 of them were affected and we applied the suggested fix about 20-30 minutes after we received the announcement.



Our server was facing extremely HIGH load during the whole day yestrerday.

We faced the same HIGH LOAD issues on Monday the 12th of May.





On both the above occassions our techs and our datacenter were unable to explain the extremely high load.

Apache was hit hard, opening 300-900 threads, were it normally has 80-120 max, MySQl was heavily overloaded and suspending our most active sites (not cs-cart) did not have any positive effect.



We have never experienced such high load issues in the past.

We are not certain whether this cs-cart problem is related with the high load issue, but we have no other explaination or indication up to now.



Did any of you notice any similar server behaviour?

[quote]I guess they just access the atos.php or hsbc.php directly to upload a foreign php file to a writeable directory.[/quote]



no, they used the admin url.

first the checked the version

and then they run a script calling atos.php or hsbc.php using the admin url



the question remains and it is very serious.

How did they know the admin page url ?

these are custom urls that we all change after the initial installation is over.

We also had some affected sites. The interesting thing is that in the server logs we saw that the attacker knew exactly the admin panel's url, even though it's name is kinda random. The attacker did not need to use the admin url to use the exploit anyway but I would like to know how they found it.



Except for searching for a thumbs.php file, you may want to check all your .htaccess files (especially the ones inside the images and js folders)

[quote name='netmaster' timestamp='1401178012' post='184353']

We have never experienced such high load issues in the past.

We are not certain whether this cs-cart problem is related with the high load issue, but we have no other explaination or indication up to now.



Did any of you notice any similar server behaviour?

[/quote]



First of all,

find and remove all shells from your server:

search for recently changed files like this:
find * -mtime -3 -print > tmp_changed.txt


-3 means changed during last three days

You can also refine your search by searhing only for .php or .jsp or .pl files etc

The attacker may also have changed the “modified” date of the files, meaning that it will be hard to find the changed ones without using an rsync-like utility.



Also check if your server is sending high amounts of email.

This is interesting,my site was not affected(far as I can see) but I had noticed on my hard drive (personal computer), I do have a lot of thumbs files the are generated by itself. I can not open them and I do not know what they are for or where they come from.

Hi Guys,





First of all I would like to apologize for the incident. That is a serious issue, and we do understand how important to respond as quickly as possible.



I would like to describe the current situations.



1) A hacker found out the admin script name for each CS-Cart store that was hacked.

Unfortunately, it is still not clear how he got the admin URL. That is the main question at the moment and we are trying to figure out how this was possible.

I would like to ask for your help in this matter, if you have any ideas of how this could be achieved, please let me know to imakarov@cs-cart.com .

Guys, who have many stores and some of them were not hacked/were hacked - can try to find out the logic of this. e.g., this could have been the Free mode (without License) or only the stores that were created a few days/weeks/months ago were not hacked, maybe some add-ons or features were disabled in the stores that were hacked.



2) We suppose that all the actions were done by a bot, and no sensitive data was stolen or malicious actions were taken.

My thoughts are as follows, each time after the bot uploaded the script to a CS-Cart site, it performed another POST request and got the same response of 36 bytes. So no sensitive information can fit in 36 bytes.





P.S. Tony, you are the first who gives answers as always, thank you!

The hacker who ran the bot may have had a list of cs-cart sites that he had gathered over the years using google etc.

So it wouldn't surprise me if new cs-cart sites were not infected.

He may also have gathered the admin urls from a long time ago.

is it worth changing the admin URL - or is this pointless until you know how they are actually gaining the info in the first place?

I don't know if this is relevant or not but I have a lot of bots attacking my testimonial page. I experienced the same as what netmaster reported above. A few weeks ago the bots were accessing my testimonial page so much that it brought my server to its knees. I ended up disabling the testimonials but still to this day the bots still try to access it. Here is a recent log entry:


192.187.122.122





/index.php?dispatch=discussion.view&thread_id=5779%20Result%3A%20chosen%20nickname%20%5C%5C%5C%22Slotofsso
Http Code: chosen Date: May 27 07:45:58 Http Version: Result: Size in Bytes: nickname
Referer: \zsbcstpx49\;
Agent: success (from first page); HTTP/1.0 404 7277 [url="http://www.domain.net/index.php?dispatch=discussion.view&thread_id=5779%20Result%3A%20chosen%20nickname%20%5C%5C%5C%22Slotofssori%5C%5C%5C%22%3B%20success%20%28from%20first%20page%29%3B"]http://www.domain...st%20page%29%3B[/url] Result: chosen nickname \zsbcstpx49\; success (from first page); Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36








/
Http Code: 200 Date: May 27 07:45:58 Http Version: HTTP/1.0 Size in Bytes: 80100
Referer: [url="http://www.domain.net/"]http://www.domain.net/[/url]
Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36








/index.php?dispatch=discussion.view&thread_id=5779
Http Code: 404 Date: May 27 07:45:59 Http Version: HTTP/1.0 Size in Bytes: 7277
Referer: [url="http://www.domain.net/index.php?dispatch=discussion.view&thread_id=5779"]http://www.domain...&thread_id=5779[/url]
Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36




The actual URL of “Referer: \zsbcstpx49;” is https://server.domai…Czsbcstpx49%5C; which is disturbing because it is my server URL but it just returns a 404 page.

Still looking into ourselves too (had about 20 sites hacked, 3 non hacked).



Of course sites still in development (ie not public) were not hacked even though they are web-accessible, so it would suggest a google search for dispatch urls could have built the bot list.



Regarding the admin urls, could it have anything to do with the compromise of Twigmo recently where you advised we change our admin url?



Two of the three non-hacked sites were compromised by Twigmo and therefore we had changed the admin url.



The third non hacked site was a really early v2 cs cart site, maybe the version did not have the atos/hsbc files…

Is this still being confined to release 4.1.2 and below, and later versions are ok.



Just asking because cscarts response above of it not knowing how the site was attacked leans me to say how do they know 4.14 is ok?

Here's how they likely obtained the location of all of our cart installations.



(I don't think they needed the admin url, all they needed was domain.com/payments/hsbc.php)



But first, here's why it's highly unlikely that our cart installations were obtained via a spider.


  1. Every single cart installation that we have that is registered was exploited (unlikely a spider could do that) .


  2. Even installations where the store front is disabled were exploited (again very unlikely a spider could do that)


  3. All Admin panel names were changed from the default “admin.php” to a custom name (so it's extremely unlikely that they were found via a spider.)


  4. The single cart installation that we have setup (for testing) that is not registered was not exploited. (if we're dealing with a super awesome spider that did not miss a single installation then it should have found the unregistered installation as well)



    Conclusion



    Our installations were obtained in an organized fashion.



    How?



    Rather simple, all licenses are purchased from the vendor using the vendors purchasing platform guess what platform the vendor uses to sell the software… yup, CS-Cart.



    Once the vulnerability was discovered they likely targeted the vender's own cart installation.



    Once they had thumbs.php in place within the venders cart installation they were easily able to access any cart information including order information which has all of our urls.



    What do you think?

    Likely?

Hi Guys,



I haven't yet received this email, could I get it sent to me please?



James

Not sure why people believe the intrusion came from the admin side… The common theme between the two payment methods was the exec() function without a literal string as the parameter. Hence they could read config.local.php or anything else on your site including your database credentials. Also from the client side, one could do $admin_url = Registry::get('config.admin_index'); Not too difficult to acquire once you're in the site.



I believe this was caught soon enough before any real action was taken. If you change the name of the test.gif to test.txt and then look at it you'll see it contains '123456789'. If it contains anything more than that, then data has been collected. However, those of you just getting to it today (rather than yesterday when we were notified) are definitely more vulnerable than those who removed the files yesterday.



We worked the whole day yesterday (holiday here) to clean up our contract clients and to add file monitoring capability to our EZ Admin Helper addon. The addon is now available for all versions above V2.2.1. You can now monitor file changes (new, changed, removed) on your site on a daily basis.

[quote name='James C' timestamp='1401216923' post='184390']

Hi Guys,



I haven't yet received this email, could I get it sent to me please?



James

[/quote]

Dear James,



The notification was sent to all active CS-Cart users, i.e. everyone who have active CS-Cart, Multi-Vendor or CS-Cart Community license.

If you use CS-Cart in Free mode , please email me your domain where CS-Cart is installed, and I will send you the email with actions that should be taken.