[quote name='imac' timestamp='1401218903' post='184397']
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.
[/quote]
[color=#000000][size=3]Hi [font=arial, verdana, tahoma, sans-serif]Ilya,[/font][/size][/color]
[color=#000000][size=3][font=arial, verdana, tahoma, sans-serif]Thank you for your reply.[/font][/size][/color]
[color=#000000][font=arial, verdana, tahoma, sans-serif][size=3]I have sent the email as requested to your email address.[/size][/font][/color]
[color=#000000][font=arial, verdana, tahoma, sans-serif][size=3]James[/size][/font][/color]
I too suffered from this exploit whereby a the files where uploaded to the server yesterday. I removed the files as per the email and now for some unknown reason delivery prices are not working as they should.
I have setting where postage is free when over a set amount however since yesterday the free postage is no longer being appled(ticket submitted).
Given this has always been fine and delivery charges have always been correct, it seems more than coincidence that orders after yesterday now do not apply the free delivery.
Add: Also, yesterday, a number of orders paid for via PayPal went to Pending status and NOT the normal received status.Is it not a callback that does this?
Doubt there is any relationship between the removal of the infected files and the entry points and the problems you are experiencing.
I cannot convey how serious this vulnerability is. It is CRITICAL that everyone remove the offending thumbs.php and test.gif files along with the 2 payment methods.
My assumption is simply based on the fact it is fine on all orders placed prior to the upload of the files. I also note by looking at some orders yesterday that one order was incorrectly charged delivery AFTER the files where uploaded but BEFORE the payment method files where deleted. That does in itself shows that the deleting of the file did not cause it, but it does leave me wondering if the uploading of the files where the only change made.
I have not updated shipping rates/countries/locations since the site was installed years ago, and suddenly the same day this exploit comes up this occurs. It may be coincidence however it is a weird glitch to just suddenly start.
So far we have not figured out any pattern, but out of 13 sites 7 of them had at least the “test.gif” on them. One of the sites actually had the “thumbs.php” in both the images and js folder so we deleted both.
In regards to strange activity we have had EXTENSIVE visits from .ru websites, many of them adult. We just can't figure out why they would be “referring” sites to our website. They have only been sending traffic since February and it has grown. I have now started blocking the ip addresses one at a time. So far they do not seem to be linking to any images, but in the past month we have seen our “pages viewed” on a dedicated server grow 10 times what it has ever been. This is more page views that we even see during the holiday season. Instead of the normal 30,000 page views our server is showing over 300,000. The sad part is we ended up turning off many of our ads because there seemed to be some type of problem with the site and we couldn't and still cannot figure out what it is. So we are getting loads of traffic and not marketing for it on the same level at all. We did find the test.gif on this sight but have deleted it and other explained files. The “page views” started ramping up for us in February and pretty much doubled each month. So far our host has not figured out anything either. Our bandwidth averages about 20gb during the holidays but this month it is already above 32gb…and again, that is with advertising at places like Google turned off!
[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]
Email was in spam (gmail)
Did someone say that any changes could be disguised so that they wouldn't show up
in a search for altered or added files?
I ran a search via my ftp program looking for amendments over the last 7 days.
The search showed that no files had been altered or added.
[quote name='imac' timestamp='1401192761' post='184370']
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.
[/quote]
Please do not allow anyone to think that no sensitive information could have been gathered.
e.g. : “dbuser_123 + dbname_123 + dbpass_123” = 36 bytes
It's enough sensitive information to dump everything in the database.
The log files we've been analyzing also show POST requests that resulted in more than 36 bytes.
173.236.23.161 - - [24/May/2014:22:46:20 -0500] "POST /js/thumbs.php HTTP/1.1" 200 4811 "-" "Mozilla/1.1 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/13.9.413.1066 Safari/537.11"
173.236.23.161 - - [27/May/2014:10:50:49 -0500] "POST /js/thumbs.php HTTP/1.1" 200 383873 "-" "Mozilla/7.5 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/26.1.672.501 Safari/537.11"
173.236.23.161 - - [25/May/2014:01:17:29 -0500] "POST /js/thumbs.php HTTP/1.1" 200 196 "-" "Mozilla/1.7 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/11.3.642.191 Safari/537.11"
173.236.23.161 - - [27/May/2014:11:18:26 -0500] "POST /js/thumbs.php HTTP/1.1" 200 4006 "-" "Mozilla/4.5 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/17.1.65.416 Safari/537.11"
173.236.23.161 - - [24/May/2014:10:15:28 -0500] "POST /js/thumbs.php HTTP/1.1" 200 5992 "-" "Mozilla/2.7 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/16.0.687.231 Safari/537.11"
173.236.23.161 - - [27/May/2014:08:04:26 -0500] "POST /js/thumbs.php HTTP/1.1" 200 14813 "-" "Mozilla/9.3 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/19.2.625.390 Safari/537.11"
173.236.23.161 - - [25/May/2014:05:26:43 -0500] "POST /js/thumbs.php HTTP/1.1" 200 4803 "-" "Mozilla/4.3 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/26.0.200.1471 Safari/537.11"
173.236.23.161 - - [27/May/2014:10:59:18 -0500] "POST /js/thumbs.php HTTP/1.1" 200 47745 "-" "Mozilla/7.2 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/40.6.68.1239 Safari/537.11"
173.236.23.161 - - [24/May/2014:11:37:26 -0500] "POST /js/thumbs.php HTTP/1.1" 200 4827 "-" "Mozilla/1.1 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/37.5.231.701 Safari/537.11"
173.236.23.161 - - [27/May/2014:08:18:51 -0500] "POST /js/thumbs.php HTTP/1.1" 200 33407 "-" "Mozilla/1.1 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.7.236.340 Safari/537.11"
In addition the thumbs.php file allows the attacker to execute any php code they wish, including executing server commands, and writing information to files on the server. Assume everything has been compromised.
The same ip 173.236.23.161 also attacked my sites. Luckily we removed them fast enough and the only posts he made on thumbs.php received only the mentioned 36 bytes.
Unfortunately in your case, the attacker had access for four whole days: 24-27 May. You should make a good search on your server for malicious scripts/shells.
This ip address points to a web-hosting company. Maybe we should formally tell them that their server is seriously hacked and is hacking others too?
Also:
There are cases where the .htaccess of the js and images folder does not allow him to execute php files inside them. So then he changes the contents of the .htaccess file too.
My guess is they are preparing for a massive attack, so they are collecting zombies (maybe for a DDOS). That's why they haven't massively defaced the sites yet or sent amounts of email.
@termalert - your ftp compare only uses modification time which can easily be set by the intrusion software. So it is not a reliable means to identify new files.
I have not heard any mention of an api.php script with a modification date of April 3, 2014 (same as other malicious files). Although the source is obfuscated, it is clearly designed as part of the malicious payload. Its purpose is unclear (it would likely be relatively easy to decode), but obviously is something you want off your server. It also means that unless you have a known clean copy, you may have difficulty tracking down other malicious scripts. The non-obfuscated files utilize the file_put_contents command, which can be used as a search query to make sure you got all the versions of image.php.
I don't see any indication that core CS-Cart files were modified (as would be common if attacker were attempting to collect CC numbers), but without knowing the content of api.php, there's no guarantee that script wasn't used to grab CC numbers stored in the DB (if you employ this risky practice). As a general protocol, you shouldn't remove anything from your web server before you've either captured a snapshot of it or performed a thorough analysis to understand the full extent of the breach. It is fortunate this does not appear to have been used to capture CC data. It is disconcerting this has been an issue across such a broad swath of the CS-Cart releases. Any further details into the nature of any data collected would benefit the larger community.
That's great…not.
There doesn't appear to be a solution apart from a complete re-install
which isn't much fun if you have a very active site.
@termalert - first off, just follow the instructions in the email that was sent. It will prevent any future intrusion by this attacker.
Then, review your access logs looking for any access to “thumbs.php”. If there have been any POSTs to that file and the response is more than 36 bytes then you may have problems (and you may have to re-install). It is still unclear at this point what the 36 bytes are that are returned. It could just be a confirmation of the file “./images/test.gif” showing that the attacker can write to your files/directories. But again, this is not really confirmed and is an opinion at this point.
For the future, you could use a file comparison program that will tell you what's new, modified or removed from your site each day like our EZ Admin Helper addon will now do. Nothing you can do now will prevent what's already occurred. All you can do is protect yourself and plan for the future.
My testsite also had som traffic from 173.236.23.161 although my domainname is NOT registered anywhere.
173.236.23.161 - - [25/May/2014:14:41:08 +0200] "GET /admin2.php?version HTTP/1.1" 200 385 "-" "Mozilla/1.5 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/27.4.685.1377 Safari/537.11"
173.236.23.161 - - [25/May/2014:14:41:09 +0200] "GET /admin2.php?version HTTP/1.1" 200 385 "-" "Mozilla/5.5 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/25.2.157.1485 Safari/537.11"
173.236.23.161 - - [25/May/2014:14:41:10 +0200] "POST /admin2.php?dispatch=payment_notification.results&payment=atos HTTP/1.1" 302 608 "-" "Mozilla/5.8 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/28.6.389.786 Safari/537.11"
173.236.23.161 - - [25/May/2014:14:41:10 +0200] "GET /admin.php?dispatch=auth.login_form HTTP/1.1" 200 8347 "-" "Mozilla/5.8 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/28.6.389.786 Safari/537.11"
173.236.23.161 - - [25/May/2014:14:41:11 +0200] "GET /images/test.gif HTTP/1.1" 404 46058 "-" "Mozilla/6.6 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/24.8.571.280 Safari/537.11"
173.236.23.161 - - [25/May/2014:14:41:13 +0200] "POST /admin2.php?dispatch=payment_notification.results&payment=atos HTTP/1.1" 302 608 "-" "Mozilla/8.3 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/38.8.199.649 Safari/537.11"
173.236.23.161 - - [25/May/2014:14:41:13 +0200] "GET /admin2.php?dispatch=auth.login_form HTTP/1.1" 200 8347 "-" "Mozilla/8.3 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/38.8.199.649 Safari/537.11"
173.236.23.161 - - [25/May/2014:14:41:14 +0200] "GET /images/test.gif HTTP/1.1" 404 46058 "-" "Mozilla/8.3 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/37.4.522.1293 Safari/537.11"
So from my perspective, there are only two ways to find my domain, through Google (or other bot) or hacked cs “upgrade_center” who collects url(s) (even admin-url) after license check…
Can I simply use ftp to transfer a copy of my current installation and scan it for malware ?
Hopefully the scanner would pick up any malware while it was downloading.
Here's an update from our extensive investigation.
We are seeing the exploit being used multiple times on the a single target, the earliest being Apr 04 2014.
Once the malicious files are loaded via the exploit the data (user contact and login info along with any valid cc's) is usually collected within seconds.
After an exploit the attacker sometimes cleans up by removing the shell scripts and sometimes even sanitizing the server logs while other times leaves the shell scripts and logs in place.
We are seeing a variety of exploit scripts being loaded onto the exploited server ranging from simple to complex.
Sometimes the attacker plants backup versions of the shell scripts which they then use as a source for a later attack.
The intense shell scripts may also be used by the hacker as a point to attack other servers.
We are also seeing file time-stamp manipulation which makes the malicious files fit in better with their surroundings.
This is a list of file names that we've identified thus far.
We've seen the files stashed in a variety of locations including root, js, images and payments
test.gif (retrieval point)
thumbs.php (simple shell script)
default.js.php (complex shell script)
slide.js (simple shell script - likely to be used as a source in a future exploit)
proxypay3_hook.php (complex shell script)
default.thumb.php (complex shell script)
Here is a list of IP's that have been used. (if you see your server's IP here… well… your server is most certainly being used to carry out attacks)
83.150.87.81
173.236.23.161
83.169.18.234
131.175.69.14
202.153.65.76
195.245.194
102,77.87.195
106,217.78.4.109
72.167.37.182
That's it for now.
Now this may sound silly but will renaming my current admin file from it's current xxxxxxxx.php
to something else help ?
[quote name='termalert' timestamp='1401354322' post='184522']
Now this may sound silly but will renaming my current admin file from it's current xxxxxxxx.php
to something else help ?
[/quote]
Couldn't hurt.
No it won't.
It is obvious from the logs that the attackers knew how to find the admin file prior to using the “atos” exploit. Renaming it might temporarily help but they will find it again the next time they want to.
…for exploits such as this one - if the actual credit card details are 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) - does this mean that in this situation, at least the actual credit card details would be safe…?