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 188.8.131.52 3326 /home4/[redacted]/public_html/oc_1/bridge2cart/config.php a _ o r [email protected][redacted].com ftp 1 * c
Tue Jun 09 05:46:24 2015 8 184.108.40.206 911360 /home4/[redacted]/public_html/oc_1/download/XLS-BACKUP-01-01-2014_15-32.xls b _ o r [email protected][redacted].com ftp 1 * c
Tue Jun 09 05:46:50 2015 1 220.127.116.11 81817 /home4/[redacted]/public_html/oc_1/sql.php a _ i r [email protected][redacted].com ftp 1 * c
Tue Jun 09 05:52:08 2015 0 18.104.22.168 1296 /home4/[redacted]/public_html/oc_1/config.php a _ o r [email protected][redacted].com ftp 1 * c
Thu Jul 16 11:22:17 2015 2 22.214.171.124 403657 /home4/[redacted]/public_html/oc_1/adm.php b _ i r [email protected][redacted].com ftp 1 * c
Thu Jul 16 11:24:50 2015 0 126.96.36.199 1267 /home4/[redacted]/public_html/oc_1/config.php b _ o r [email protected][redacted].com ftp 1 * c
Thu Jul 16 11:26:35 2015 2 188.8.131.52 403657 /home4/[redacted]/public_html/oc_1/adm.php b _ i r [email protected][redacted].com ftp 1 * c
Thu Jul 16 11:27:22 2015 0 184.108.40.206 7698 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ o r [email protected][redacted].com ftp 1 * c
Thu Jul 16 11:27:27 2015 0 220.127.116.11 7698 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ o r [email protected][redacted].com ftp 1 * c
Thu Jul 16 11:29:59 2015 0 18.104.22.168 9761 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ i r [email protected][redacted].com ftp 1 * c
Thu Jul 16 11:38:00 2015 0 22.214.171.124 1267 /home4/[redacted]/public_html/oc_1/config.php b _ o r [email protected][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, 126.96.36.199, 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 188.8.131.52 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.