Cart2Cart’s Strange Magento Security Announcement

Last October we wrote a post about strong circumstantial evidence pointing to the fact FTP credentials provided to the company Cart2Cart had compromised on their end. In the past few days we became aware of a security announcement they put out that either obliquely notifies their customers of that compromise of FTP credentials or indicates they really have no clue when it comes to security (while feeling it appropriate to be giving out security advice).

They are sending out the following email to customers:

We’re writing to inform you that our security audit has revealed an unpleasant vulnerability of certain Magento stores. Considering the fact that Magento shops are being attacked by hackers more often lately, we strongly recommend you to double-check the security of your e-store.

Please, contact your developer team, so that they could scan your Magento source code in order to ensure that your shop is not under the threat of being abused. Read more info here:
http://www.shopping-cart-migration.com/important-security-announcement-for-magento-store-owners

If you need technical assistance regarding this, reply to this email and we will check your store from our side.

Following the link mentioned there, you get a page that starts out:

After performing an audit, we’ve revealed an unpleasant vulnerability of certain Magento stores that may have a negative impact on the security of your customers’ personal data.

To ensure the finest security of your Magento retailer, we strongly recommend you to contact your developer team and check the source code for the presence of any suspicious customizations.

The link to “an unpleasant vulnerability” discusses not a vulnerability, but the end result of a vulnerability being exploited, code added to one of Magento’s files that sends credit card information entered on the hacked website to a third-party. The distinction is quite important because when a website is hacked, if you don’t find and fix the vulnerability that allowed it to be hacked the website can remain vulnerable to being hacked again.

Cart2Cart’s email and page never mention what the code they are mentioning does, instead saying “First of all, there’s no need to panic. You can eliminate any possible risks simply by revealing and deleting the code, if there’s any.”.

The next thing they say leads us to believe this could be a reference to their being compromised (or it shows they have no idea what they are talking about) as it suggest doing two things if you have the code on your website:

  1. Delete the following code inside and save the changes:
  2. Change your FTP account credentials

Those steps would suggest that the hack happened through compromised FTP credentials, since they want to change those credentials. But the FTP credentials would have to have been compromised somehow, yet they don’t suggest doing anything to stop them from being compromised again. That could be because the compromised happened on their end and has now been fixed, or it could suggest they have no clue what they are talking about.

The last section of the page would certainly lend some credence to them not having much clue when it comes to the security of websites. They provide this list of security tips:

Useful Security Tips

  1. Use up-to-date antivirus software

  2. Don’t store your FTP account passwords in programs like Total Commander, Filezilla, etc.

  3. Change your FTP account password periodically e.g. once a month, especially after granting access to any service providers

  4. Limit the FTP access to specific IP addresses

  5. Change the administration panel login “admin” to a custom one

  6. Hire certified developers, designers or other staff you can trust to only

  7. Use repository for a proper and secure workflow

Notable missing from their list of security tips is keeping the software on your website up to date. Not only is this a basic security measure, but it is particularly relevant with Magento based websites right now, since most of the hacked Magento based websites we are cleaning these days have been hacked due to the software not being kept up to date (or not having the security patches for older versions applied).

If you do find code added /app/code/core/Mage/Payment/Model/Method/cc.php, removing the code and changing the FTP credentials is not enough. You will want to also:

  • review the rest of the websites files for malicious code and remove any found
  • check for Magento extensions added by a hacker
  • check for additional Magento admin users
  • get Magento secured by either upgrading it to the latest version of 1.9, currently 1.9.2.3, or applying the security patches for older versions
  • rename the Magento admin directory to something other than “admin”
  • change the passwords for other logins associated with the website (database, Magento admin, etc), in case they were compromised
  • try to determine how the website was hacked and make sure that is fixed

It Appears That FTP Login Credentials Provided To Cart2Cart Were Compromised

When dealing with hacked websites one of the important parts of the process is to determine how the website was hacked. If that isn’t it done the vulnerability that was exploited is more likely to remain open and be exploited again. Amazingly many companies that do hack cleanups don’t do that (which frequently leads to us being hired to re-clean hacked websites).

While dealing with one such case recently we came across evidence that company Cart2Cart was compromised at some point leading to a hacker gaining access to FTP login credentials for websites that were provided to Cart2Cart.

The hacking case we were dealing with was rather serious, as the breach first lead to thousands of dollars of decline fees with a payment processor and then later after that issue was resolved the breach lead to the compromise of credit card credentials used on the website (which is a good reminder of why figuring how the website was hacked and closing the vulnerability in the beginning is so important).

One of the places that is checked when working to determine the source of the hack is the log of FTP activity. For this particular website one of the things we first noticed while looking over that was that there had been access from IP addresses in the Netherlands

Tue Jun 09 05:45:57 2015 0 37.48.80.118 3326 /home4/[redacted]/public_html/oc_1/bridge2cart/config.php a _ o r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:46:24 2015 8 37.48.80.118 911360 /home4/[redacted]/public_html/oc_1/download/XLS-BACKUP-01-01-2014_15-32.xls b _ o r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:46:50 2015 1 37.48.80.118 81817 /home4/[redacted]/public_html/oc_1/sql.php a _ i r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:52:08 2015 0 37.48.80.118 1296 /home4/[redacted]/public_html/oc_1/config.php a _ o r c2c@[redacted].com ftp 1 * c

and Russia

Thu Jul 16 11:22:17 2015 2 46.72.126.220 403657 /home4/[redacted]/public_html/oc_1/adm.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:24:50 2015 0 46.72.126.220 1267 /home4/[redacted]/public_html/oc_1/config.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:26:35 2015 2 46.72.126.220 403657 /home4/[redacted]/public_html/oc_1/adm.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:27:22 2015 0 46.72.126.220 7698 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:27:27 2015 0 46.72.126.220 7698 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:29:59 2015 0 46.72.126.220 9761 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:38:00 2015 0 46.72.126.220 1267 /home4/[redacted]/public_html/oc_1/config.php b _ o r c2c@[redacted].com ftp 1 * c

during the summer. Since the website is US based that is usually a strong indication that the FTP login credentials have been compromised. Though it can sometimes be due to someone traveling or use of a foreign service provider. In this case we thought at first it might be the latter because the FTP account was one that looked to have been created especially for the service provided Cart2Cart. Checking with the client we found that it was indeed set up for them, but that their use of Cart2Cart ended more than a year ago.

At this point we had a pretty good idea based on what was in the FTP log that a FTP account had been compromised, but without knowing how it got compromised we couldn’t be sure how to prevent that from happening again or if other logins were also compromised as well. So what was the source of the compromise?

When we did a search on the Russian IP address, 46.72.126.220, we came across a forum thread from January that described a very similar situation. In that case a FTP account that was “created expressly for [Cart2Cart], no other reason” was making unauthorized changes to the website’s payment module when Cart2Cart should no longer have been accessing it. The only major difference between the two cases is that we were dealing with an OpenCart based website while in the other case it was a PrestaShop based website.

In the thread someone from Cart2Cart responded:

As far as I can see from your screenshots, IP address 46.72.126.220 doesn’t belong to Cart2Cart.

The chances that two FTP accounts created especially for use by Cart2Cart were compromised with malicious access coming from the same IP address and the source of the compromise of these logins not being on Cart2Cart’s end seem to be incredibly small. Since they seem to be a legitimate service provided we don’t believe that they were involved in the hacking themselves, so that leaves us to believe that they must have been compromised at some point.

Their lack of concern in that thread that they might have been compromised doesn’t really jibe with the claim on their website that:

We have taken every precaution to ensure that our systems which store access information is highly secure.

It is also worth noting that the first malicious FTP access to the website we were dealing with, as shown in the FTP log, was two months after the time that forum thread was active.

If you have used Cart2Cart in the past, now would be a good time to make sure you have changed any password you provided them and probably make additional checks of your logs and files to make sure you have not been compromised as well.