Are you planning to shut down your online store? Sorry to hear that. However, your domain name could be a valuable tool to trap hackers. Please consider donating your online presence to the good cause: fighting online fraud.
As e-commerce crime becomes more sophisticated, it becomes harder to track new attack methods. Currently, new techniques are discovered like this:
Consumer sees unauthorized payment, calls bank
Bank gets lots of complaints, identifies common denominator, calls the likely compromised merchant
Merchant asks agency or ISP to launch security investigation
Technician sifts through millions of log entries
Technician curses, finds hack entry point and identifies new attack method
Doesn’t sound very efficient, right?
Getting ahead of fraud
Holy grail: identify new attacks before they can do any damage. This would be a whole lot easier if we could filter out legitimate traffic.
One approach is to set up a new (fake) store that doesn’t have any real customers (aka a honeypot). However, apart from the work involved with creating a realistic looking store, it has a major disadvantage: it lacks credibility. It is not included in any search engine result or in any list that circulates among fraudsters. And criminals browsing the site will quickly see that it is fake. So the chances of actual hack attempts are slim.
The best approach would be to use a real store without real customers. One that has been around for a while but has gone out of business. This store likely sees hack attempts on a daily basis and is included in lists of target e-commerce sites that are sold on the dark web. Apart from search engine traffic, any other traffic is likely suspect. This would tremendously reduce the analysis effort.
How does it work
We would copy your template (just the looks, not any code. history or data!) and point your domain name to a special equipped server.
Then, all the requests to authorized endpoints (such as the backend panel) will be logged. As these endpoints are not in use anymore, any traffic to them is highly suspicious and will be investigated. If a source IP sends requests beyond a certain threshold, it will get added to a list of known hack networks. Other stores can use this list to block access to their stores. And when new attack methods are discovered, they will be published and proper protection can be made.
If you plan to let your store domain name expire, please donate it instead. With your help, we can:
The pattern was discovered by Jeroen Boersma (excellent detective job!). He found the following database trigger (edited for readability):
The trigger is executed every time a new order is made. The query checks for the existence of the malware in the header, footer, copyright and every CMS block. If absent, it will re-add itself.
This discovery shows we have entered a new phase of malware evolution. Just scanning files is not enough anymore, malware detection methods should now include database analysis.
Check your own database
Do you have persistent malware hidden in your database?
echo'SHOW TRIGGERS' | n98-magerun db:console
NB. Magento Enterprise and some community extensions contain legitimate triggers. So if you find triggers, look for suspicious SQL code, such as anything containing admin, .js, script or < (html tags).
If you find a malicious trigger, you can delete it like this:
TL;DR: Find weak passwords on your Magento stores before the bad guys do. If you spend some serious money ($1) on high-performance computing power, you can find easily guessable passwords. Here’s - step by step - how you can check your stores for vulnerable admin accounts.
A password guessing attack (aka “brute force”) has become the most successful attack vector recently. Hackers try zillions of passwords on authenticated pages (/admin, /downloader, /rss) until they hit the jackpot.
Now, you (the admin) can easily find weak passwords, because you have a major advantage over remote attackers: speed. Potential hackers test passwords over HTTP, which is relatively slow. With a botnet and fast servers, at best (worst) they can try a few hundred passwords per second per store. You, on the other hand, have direct database access. With the proper setup (read on!) you can test 4 billion passwords per second.
What they actually mean is that they stored a hash of your password. Hashing is a one-way algorithm to translate some data (your password) into a unique code. Say, you have password qwerty123. The MD5 hash for this password is 3fc0a7acf087f549ac2b266baf94b8b1. It is not possible to revert this. However, nothing stops you from hashing random passwords and see if they match 3fc0a7acf087f549ac2b266baf94b8b1. You would only have to try enough combinations, starting with aaaaaaaa, then all the way to ZZZZZZZZ (and beyond).
The MD5 method is not a very safe hash, because it is unbelievably fast. A 5-year old PC can compute about 70 megahashes (MH) per second. And a juicy videocard can do 4500 MH per second.
Get the machinery in place
Magento 1 CE uses the fast MD5 hash to store admin passwords. To find weak ones, you need:
A cloud server optimized for machine learning, such as Amazon’s P2
A list of hashed Magento passwords
Amazon released their P2 GPU servers recently, to jump on the machine learning money wagon. P2 servers happen to be also really good at hashing. Equipped with Nvidia’s Tesla K80 cards, those servers are nothing but hash grinding beasts. The smallest P2 server is still pricey, but for $1, you may tame it for a whole hour.
Boot a p2.xlarge with Amazon EC2. Root disk 8GB is ok. Pick Ubuntu 16.04 AMI. Download keyfile (pem). Run these commands in terminal.
Extract hashes from your Magento stores
Almost ready to start cracking: you just need the password hashes. If you have magerun, you can do this (run on your Magento server):
n98-magerun db:query "select concat(username,':',password) from admin_user where is_active=1" | tail -n +3 | tee maghashes.txt
Now, maghashes.txt contains lines with username:hash:salt like this:
Copy this file to your hash grinder and start the magic:
scp maghashes.txt ubuntu@<AWS-IP>:/data
# back to your AWS terminal
./hc -m20 --username -r rules/best64.rule ../maghashes.txt ../phpbb.txt
The One Dollar Challenge
Show all the guessed passwords:
./hc --show --username -m20 ../maghashes.txt
In practice, 10-15% of the admin passwords appears easily guesseable. This is more than I expected. Notable cases are test/test123 and admin/123. Magento 2 forces strong passwords by default, but for anyone still running M1, it’s a good idea to give your admin passwords a boost.
Update 15:40: Magento 2 uses the somewhat safer SHA-256 hash, but it is still not as good as PHP’s native password_hash(). Tobias Zander proposed to change it in January 2015 but it hasn’t happened. The illustrious Daniel Sloof has made a Magento 2 module to use more secure hashing while retaining backwards compatibility.
It would be absolutely awesome if sombody could make a magerun plugin to check for the most common weak passwords (test123, welcome01, etc), so that testing takes 1 minute instead of 1 hour.
If you find it scary that password cracking is so easy: say bye bye to MD5! There are several ready to use replacements, made by Classylama and Fabian Blechschmidt, that implement safer algorithms. Why Magento1 still uses MD5 is beyond me. To demonstrate the speed difference, here is the benchmark for the Amazon P2 grinding rig running MD5 and PHP’s password_hash() (bcrypt/c10):
If you want to grind hashes for more than an hour, you need bigger wordlists and/or rulesets. An extensive wordlist is rockyou (60MB) and a good ruleset is -r rules/rockyou-30000.rule. This could take multiple weeks to complete (at $150 per week).
Visbot does what you would expect from any self-respecting malware: steal customer data and credit cards (aka skimming). And it is not even new: the first case was documented as early as March 2015. But getting out of the shadows did not stop it from spreading. Today I found active Visbot skimming on 6691 online stores.
How’s that possible? Contrary to other skimming malware, Visbot nestles itself in code running on the server. This makes it harder to detect from the outside, as the malware operates completely invisible for anyone but the store owner. And many store owners are not equipped to detect these security breaches.
Visbot injects itself into existing site code. It stays dormant until it detects that data was entered by store visitors (an order or a password). Submitted data is then encrypted and saved to a fake image file. This “image” is then later retrieved by the perpetrator and - presumably - sold on the black market.
Stores usually have a gazillion images, so fetching an odd one is hardly suspicious.
Encryption ensures competing thieves cannot use the valuable payload.
I hear you ask, “how can you be sure that Visbot exists on all these stores? If it is so well hidden?” Here comes the crux: the Visbot author added a feature so s/he could detect whether the money machine is still running. If you send a specific code (a “password”) to an infected store, it will say:
If you know how to use a terminal, try it right now:
Ecommerce people have been making long hours, as more stores were hacked in 2016. Magento saw a rise of Shoplift and brute force attacks. Stores that follow best practices should not worry. But a majority of stores do not keep up with patches and strong passwords, and get hacked sooner or later. These negligent merchants become reverse brand ambassadors. Which is ultimately a bad thing for everybody but.. Demandware.
The bottomline is: how to secure thousands of badly maintained stores? Nobody has found a really good solution yet, and - interestingly - there has been little public debate so far. Here are 10 ideas to get the conversation started!
Crawl all 300K contact forms of vulnerable stores to reach the beneficial owner. So far, Magento has been contacting people who entered an email on the download page (ie, technicians). The response rate has been “very low”. Academic research claims only 5.8% of actual website owners can be reached in case of a vulnerability issue. Now, I think we have an edge with Magento because of the standardized contact form implementation (easy to scrape). Second, the recipient of the contact form has likely a larger interest in fixing the site than the tech who did the initial install but is no longer on the project.
Encourage hosting companies (HSPs) to enforce secure installations. Magento Inc could promote HSPs that actively engage in protecting their merchants’ security. All of Magento’s official hosting partners are “committed to security” but few actively block the latest threats. HSPs can leverage intrusion prevention systems (IPS), and assist their customers with patching and incident response. Hacked, abandoned stores should be locked-down pro-actively to stop them spreading malware.
Publish a nematode: a friendly, autonomous worm that crawls the Internet and fixes vulnerable stores. Slightly unconventional, but nevertheless proven valuable in the past. A well written nematode would fix all Shoplift-susceptible stores globally within 30 minutes. In fact, this is slowly happening right now, but by the bad guys: hacker groups are already closing the Shoplift hole after they got in, to keep competing hackers out.
Government could tighten incident disclosure laws, so that hacked stores would actually notify their customers upon data theft. At the moment, this is certainly not the case, and merchants get away with sloppy maintenance. (Proof: I have placed canary orders at stores that I knew were hacked, and I was never notified afterwards. Were you ever?) This would be a great incentive for merchants to spend money on maintenance. Current laws are lobbied down to be very vague, and where the law actually dicates disclosure, enforcement agencies are seriously understaffed (eg in Holland).
Set up a malware signature collection, and empower system administrators to easily detect security breaches (and submit new signatures). So far, two HSPs have shared their malware rules: NBS and Byte. The effectivity of these rules would get a boost if more HSPs joined. Both Magemojo and Lexiconn have already pledged to contribute.
Set up a searchable archive of ecosystem vulnerabilities, similar to wpvulndb for Wordpress. At the moment, only Magento Inc and a few vendors have processes to disclose vulnerability information. And this information is not standardized or even accessible from a single place. Most vendors fix security bugs but write a small note deep in their release notes (if at all). Standardizing and vetting security announcements is quite a lot of work, but let’s start with a low-effort centralized repository of statements. Once we have that, somebody will publish a n98-magerun plugin the same day.
Implement and enforce an immutable document root in Magento (and offload somewhat volatile data such as media to a CDN). This would prohibit attackers to hide malware on the server. The required technical changes are no deal breaker for the Magento core, but several 3rd party modules assume a writeable document root. Supporters include Max Pronko, Ivan Cherpurnyi and Fabrizio Branco.
Magento could encourage Google to block compromised sites in Chrome. At the moment, Google’s Safe Browsing team has about 10% of compromised stores in its filter. Blocking is a rude measure, but without it, the hijacking of private data continues and total damage increases.
Magento Inc could hire more vulnerability researchers to find bugs before they get released. Magento has many top of the bill engineers already, but hunting security flaws is a specialized art. To identify the best Magento bug hunters globally, one would simply have a look at the credits in the latest patch releases. I posit that if Magento Inc paid the best bug hunter $200k per year and s/he would find just a single RCE exploit in unreleased code, it would be an absolute bargain.
Organize a dedicated MageStackDay to increase patch rates globally. Or, as Anna Völkl called it, a MagePatchDay! Enthusiastic volunteers would teach merchants why and how to get their security on par. Especially the “why”.
Give small time merchants a discount for Shopify. The long tail of Magento installations are people who chose Magento just because it is a “free download”, but have only 3 SKUs. They will not pay an agency $20k for proper maintenance and will certainly not pay Magento Inc for an Enterprise license. So it would be good for everybody if these stores converted to a SaaS solution with zero maintenance.
Yes, more than ten, the ideas just kept coming! I must still have missed a couple though. Are you a concerned professional? What works and what doesn’t?