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.

1 thought on “It Appears That FTP Login Credentials Provided To Cart2Cart Were Compromised”

  1. My name is Stepan and I’m Cart2Cart Project Manager. Yes, I confirm that IP address 46.72.126.220 doesn’t belong to our service, and we can guarantee there were no access to the store from our side. Moreover, we always highly recommend to remove/close FTP access provided to Cart2Cart and delete a connection bridge after migration http://www.shopping-cart-migration.com/faq/1-general-questions/109-why-cart2cart-may-need-access-to-your-web-shop-or-server . All the migrations are performed on dedicated servers on Amazon’s Elastic Cloud service which ensures the highest level of security. 

     We’ are disappointed about this situation and are committed to do everything we can to make certain it never happens again. 

    Best regards,
    Stepan Fedortsiv

Leave a Reply

Your email address will not be published.