If you own an online store that runs on the Magento eCommerce platform, your website may be vulnerable to the Shoplift Bug, a?remote code execution exploit that involves someone coming in, rewriting a Magento Core file and using it to gather Credit Card information. First thing first, to check if your website is vulnerable visit this website www.shoplift.byte.nl. If you have a custom Magento admin URL enter that URL the second box where it says admin.
This exploit takes advantage of the Magento core file, /app/code/Core/Mage/Payment/Model/Method/Cc.php.
Simply put, the function prepareSave() is edited with extra code added to it, to take post data on the checkout page and sending it back to the hacker. It’s a general Magento rule to avoid editing the Core files — if you notice your code looks different from a fresh/default copy of Magento’s core, especially if you see code relating back to PHP functions like ‘curl’, your store might have been compromised.
Here is how the clean code should look:
Example of Bad Code:
What are you supposed to do after you’ve been hacked? How do you recover?
As of today merchants using Magento Community will start seeing a notification when first logging in to the admin, advising them to download the patch from the Magento website here. Merchants who use the Enterprise version of Magento have to login to their Magento Support Portal?and check the downloads to find the SUPEE-5344 patch.
There are several things to consider if your server has been compromised.
The first is that the attacker likely has access to your database. Customer accounts and “encrypted” passwords are likely in the hands of the attacker. Letting your customer know that there has been a breach of security is probably a safe bet – especially if some of them use the same passwords for multiple accounts. As soon as those password hashes are cracked, the attacker will attempt to login to the associated email account and gain further access to the customer information. It’s also important to keep in mind that the attacker will have access to all sorts of personal information for customers. On a side note, Magento Community uses a relatively weak encryption method by default, as one can create an MD5 hash. As a rule of thumb: faster hash generation time = faster hash cracking time. Custom encryption methods can be created, or used, instead.
The second thing to consider is that the attacker likely left a backdoor some place on the server. Depending on who you are hosting with, how your user accounts are set up, and what sort of access the attacker would have had, this can be anywhere from a file system level backdoor to one within Magento itself… it could even be both! Careful consideration must be given that sometimes it might be better creating a fresh install of everything on a new server, and transferring over customizations one at a time – after ensuring that the files are safe. A slight alternative to this is using “diff” on your server to compare the files between a known good copy and the current version. This will be critical to revealing any malicious code. For a file system level backdoor (read, server) you are definitely better off re-installing the server, or using a backup of the file system.
Disable the checkout. There’s no point in continuing to accept payments when you are going to put more people at risk and further expose yourself to liability.
Virus scan your personal computer. This may seem unrelated to the security of your Magento store, but there is always the possibility that your computer was infected with a “key-logger” that transmitted the information that the attackers used.
Realize that there often isn’t much you can tell from a log file. Trusting a log file on a compromised system might only reveal some information depending on the intentions of the attacker.
In the event that you are considering going to law enforcement, it is important to note that you’re probably going to have to leave all malicious code untouched as forensic evidence. It really depends on the extent of damage, but you may have to notify your customers and disable checkout on your website in general. You might be able to just disable the affected parts of the site, but keep in mind that the safety of your customers comes first.
So, what are some extra steps you can take to prevent something like this from happening?
For a Magento installation, be sure to:
- Create unique databases for Magento, along with a unique user who has a unique password. Also, keep in mind that the user does not need all privileges granted for that database – in fact, some privileges are very dangerous.
- Use a secure admin path such as https://www.yourstore.com/admin_for_your_store_2015
- Avoid installing modules through MagentoConnect. If you can’t see the code that you are installing, you could be unknowingly putting malicious code on your server. Alternatively, only install modules from developers that you know are legitimate.
- Choose secure and unique passwords for all accounts. This includes FTP, Magento’s admin, the Control Panel for your server, any Database Users, SSH users, e-mail. The best type of password is a long password, comprised of several words together that are somewhat easy to remember as opposed to random characters that are hard to remember. Hackers typically use scripts or bots to generate passwords, so a short, random character password can be cracked much faster than a password like ‘StrongKiteCitizenSedan’.
- Monitor who you share your passwords with. When letting outside developers have access, it’s best to give them their own accounts which you can disable or delete after they finish. It’s even better to give them accounts with restricted access. There’s usually no reason to give them access to the control panel or anything outside of the folder that Magento is stored in. You can even utilize Magento’s users and roles to restrict what parts of the admin dashboard they can access.
When considering security of any Magento store, it’s important to keep in mind that the security of the web server is no more important than that of the store itself. Attackers will find the weakest link in the chain and exploit it.
Some of the biggest changes you can make involve the way you access your server. This includes:
- SSH Keys / Public Key Authentication – this is undoubtedly the best route to go in terms of authentication when logging into your server. Essentially, when you enable this, you put a “padlock” (public key) on your server and only you will have the “master key” (private key) that will unlock it. Additionally, they can be created so that they also require a passphrase when logging in. This is an extra layer of security in the off-chance that an attacker obtained a copy of your “master key”, they would still need to know the passphrase. The best part is that the “padlock” can be put on as many servers as you wish. Last, if you have any SSH accounts enabled on your server, make sure that SSH access is restricted by IP only. Logically this will be your own IP or your agency’s/developer’s IP.
- Using SFTP – The difference between regular FTP and SFTP is that SFTP encrypts the information sent between server and client which prevents Man In the Middle Attacks (packet sniffing). Packet sniffing relies on the fact that information is sent in plain text (unencrypted) vs. encrypted.
- Separation of privileges – Almost all servers in general should have root login disabled. There is almost no need for the root user account to be able to login from a remote location. Additionally, one should be careful to only give read and write access on most files to only certain users. Remember that PHP is a scripting language, and PHP script is parsed – not executed – therefore PHP files do not require execute privileges.
- Backdoors – If an attacker gains access and someone notices, changing passwords and patching the vulnerability will remove an attackers access to the server – this is why attackers will purposefully add in ways that they can still control the server – these are called “Backdoors”. A good thing to consider in an attempt to avoid a backdoor’d site. When you are finally ready to launch your webstore, create a backup that will never be accessible to anyone but yourself. Regularly create backups in addition to this. The dangerous aspect about software that has a backdoor is that the code can oftentimes just be a few lines, and it could even be spread out across different files. With a e-Commerce platform like Magento it’s difficult, if not impossible, to audit each line of code. Remember to back up both the files and the database!
- Disable dangerous PHP functions. Although, there may be other vulnerabilities that exist in terms of code execution, there is almost no need for certain PHP functions to be enabled:
- Ask your webhost about this as it requires modifying php.ini
- Optional: Ask your webhost if they allow PHP-FPM. This allows PHP to run as it’s own unique user (essentially). The security comes from what is called a PHP-FPM chroot (or “change root”). This does two things:
- If I had two completely different websites on one server I could have PHP running as (essentially) two different users – user1 and user2. User1 will not have access to user2’s files. So, if someone compromised user1’s account and uploaded a malicious PHP script to copy or modify user2’s files it wouldn’t have permissions.
- The user running PHP won’t have access to sensitive documents like /etc/passwd.
- Watch any resources you use outside of Magento – If you’re using Magmi to import, be sure to change the name of the folder it’s in, and block off any access to intruders with an .htaccess files. Magmi is a great and popular tool but it is also a vulnerability, especially since it directly writes to your database. Hosts like Nexcess actually pre-emptively disable access to folders named ‘Magmi’ because of this. Nexcess will actually help you set up those blocks if you seem to be having trouble as well.
In conclusion, there is a lot that goes into maintaining the security of your website. With careful monitoring, making sure your passwords are secure, and many of the precautionary steps listed above, you can greatly minimize your risk of intruders gaining access. However, there is always a possibility that someone can get through, and no website is 100% secure. Sometimes the best you can hope for is to catch the hack as quickly as possible and execute damage control from there.