How to Battle a Hacked Checkout

Summer had come to an end and our Batman support team returned from Scandiweb Summer Office. Everyone worked on their usual tickets and were awaiting upcoming holidays. There were no signs of trouble until a blocker came — the ticket that described an emergency, the live site was broken.

The only thing specified in ticket description was that client’s website security had been breached, customers reported that their cards have been used fraudulently after using their website.

First thing that was identified — malicious code within their database table “core_config_data” under “Checkout Description” field.

How we were frustrated at the moment that the client was using Community Edition and admin activity wasn’t visible. But after some time spent on checking access logs, we were pretty sure — some user was hacked. The information was presented to the client, they changed passwords and checked all users immediately.

Lesson #1- Please don’t use simple passwords for your accounts.

But that was not all and not the biggest issue on their website.

The first thing that we need to do when the website is hacked — collect evidence. We made a copy of all logs, including Magento log files. We checked .git and found a lot of malicious files.

The files were hackers special “admin panel” of the current website. He could change file permissions, execute scripts, insert queries to the database, crack md5 passwords and, of course, take data from customer credit cards. Practically do EVERYTHING. After deleting the files from the server, the hardest part of our work started — finding reasons why and how they had been added to the server and how the website was exposed to risk.

We started to check access.log file. Didn’t find any problems there, so we wrote to the client’s hosting provider to give us backups. After hours of checking access.log files in backups, we found the hacker. He accessed the live website, added his files and … TESTED CHECKOUT. Everything was done from a single IP. :))))

We checked this IP and found that this is a French hosting provider, wrote them our story and now we are waiting for the response. (to be updated)

Then we tried to analyze code, that is not under .git — in /media folder and etc. Voila! We have found a file there that helped hacker to do his job. With this file, we managed to hack ourselves locally, as the hacker did it on live. This file was present on the live website since 2015, by using Magento vulnerabilities.

Now it’s covered by patches, but exactly this back-door was used to access server.

Lesson №2- Please, do not save and keep unused files in your project folder.

To sum up all steps in this fight against a website security breach

PERFORMED ACTIONS:

1. Access log investigation.
2. Code analysis, review of files that normally are not included under GIT.
3. Database inspection.
4. Magento and server log inspection.
5. Magento / server users revision.

MALWARE FOUND:

1. Malicious file under /media folder.
2. Malicious entry in Database that requested JS code from a 3rd party.

File under media was added to the server on 2015. The initial file was a back-door, without harming logic (that would download something from the server), but we found that this back-door was used to access server this year.

Potentially, initial back-door was inserted by an automated crawler that used Magento vulnerabilities that were present in 2015. Then this backdoor was used by the same or different hacker now.

Entry in Database mostly duplicated logic of files under /media and appeared also in 2016. But it was left there by another hacker, who had direct access in Magento back-end (login and password). In most cases such being acquired through key-loggers on user PCs.

MEASURES PERFORMED:

1. Evidence collected
2. Media / DB files and entries sanitized.
3. Whitelist — Made by hosting provider.
4. Password change — Made by the client.

At the end, we want to say, that no one is safe from hacker attacks. But you always can do as much as you can. So please, keep your passwords strong, file permissions wise and project clean. Scan your Magento shop and, of course, patch your website and check vulnerabilities at Magereport.com.

The end.

Author: Anna Guseva, Support developer

Looking for more about the legendary Scandiweb Support? Check out our Support services page here.

Share on: