Mitigating Magecart Attacks – Some Thoughts from Graham Cluley
Magecart attacks are becoming increasingly popular and dangerous, causing serious damage and raising critical questions along the way.
To help businesses gain a deeper understanding of what these attacks entail and how they should be handled, we sat down with security and JavaScript expert Graham Cluley, a leading computer analyst with decades of experience in cybersecurity. Cluley shares his insightful views in his award-winning blogs, podcasts, and dozens of media and event appearances. We discussed the nature of Magecart attacks and the solutions that can help companies prevent and mitigate them.
If you’d rather listen to the conversation, you can click here.
What happens during Magecart attacks?
We often hear about Magecart attacks on the news and it’s important to understand what they actually are. Major hacking groups plant JavaScript malware which is typically hosted by a 3rd party, with the intention of skimming credit card data and personal information from innocent internet users as they interact with websites.
Even though websites normally do not store users’ full payment information (such as CVV security code), the malicious script doesn’t need to break into the website’s database but instead watches as the information is being entered by customers who check out.
We’ve seen major companies hacked by Magecart groups, including Vision Direct, Umbro, and others. Hundreds of millions of customers have been affected as a result and the costs are significant.
Who is at risk of being a Magecart attack victim?
In one word: everyone. Nearly all websites – well above 99% – use some form of 3rd party JavaScript code. In many cases, a major part of the website is actually run by external suppliers. This isn’t necessarily bad, as it helps boost the functionality of the website. Google Analytics, for example, is being used by millions of websites for very good reasons. Problems occur when a piece of code becomes vulnerable, which exposes the entire website to hackers. JavaScript code gives hackers many ways of modifying the website, as well as reading and accessing information that is displayed or entered.
This problem has to do with the basic architecture of websites. There’s no hierarchy between different pieces of code and each one has the same “rights” as the next. It only takes one malicious section to affect the entire website, like poisoning the water supply.
This issue grows when you consider websites’ inability to track every change made to every piece of JavaScript code created by 3rd party suppliers. Companies serve code directly to running browsers without really knowing what it consists of, which is dangerous.
Who is responsible for mitigating Magecart attacks?
Just because the vulnerability is caused by external suppliers, it doesn’t remove responsibility from the company who owns and runs the main website. Sometimes the affected code is actually planted within the website itself. But even if this isn’t the case, it is up to the website to handle these attacks; it’s the company’s reputation on the line. Ticketmaster will take the blame in the public eye at the end of the day.
There are a lot of added costs that follow Magecart attacks in terms of customer acquisition. You have to invest resources and work hard to regain your customers’ trust, a process that might take years to complete. There is also a heavy focus on privacy issues at the moment, with GDPR and California’s new regulation, letting companies know what they should be paying attention to.
What does an actual Magecart attack look like?
Visitors interact with an enterprise web server, as we all do on a regular basis. They communicate with the server on the website that collaborates with 3rd party tools, such as Google Analytics, and are asked to provide information at a certain point.
These 3rd parties can make any modification to the website and communicate back and forth between the browser and themselves without any monitoring or oversight. If they were hacked and malicious groups have gained access to the code, they can interfere directly with the browser session, steal information, introduce their own content to gain more information, present content on behalf of the website owners, and much more. From the outside, hackers are able to make this activity seem legitimate and operate for quite some time without raising any suspicion.
What makes Magecart so attractive to hackers?
We’ve heard of over 50,000 online stores that have been compromised, and there are a few main reasons for why these attacks are so attractive to hackers. Magecart attacks offer an impressive level of scalability. You only need to compromise a single piece of code by any 3rd party operating on the site to gain full access to any and every activity and impact many users.
With Magecart attacks, which are also hard to detect and prevent in advance, a small hack brings big results and there’s no need to penetrate the website’s security layers in order to collect payment data and personal information.
Going beyond 3rd party tools
When we discuss Magecart attacks, we focus on 3rd party tools as the enablers of such security breaches, but it’s important to note that the hacking process doesn’t end there. These tools, which collaborate with websites of all types and sizes, also interact with other external suppliers. There are many relationships down the chain and these interactions, once breached, put everyone involved in danger.
This also means that even the most security-driven websites, who audit and test the vulnerability of the 3rd party tools they interact with (which is in itself rare and difficult to follow through), still remain exposed through the 4th and 5th party tools these suppliers interact with. This makes the process of fully protecting websites and their users from Magecart attacks that much more challenging.
What’s at stake?
To understand the impact of Magecart attacks, we have to consider the damage they cause to both the users and companies – websites and suppliers – that are involved in the attack. It’s sometimes difficult to measure the cost of such a breach because it takes years and years for companies to rebuild their reputation, and some never quite manage to recover.
Techrabbit, for example, was attacked 3 times within 3 weeks in 2018. Can we really put a price tag on the PR and reputation-recovery efforts needed to clean up after such a crisis? There are also operational costs and legal ones, especially in areas where privacy regulation is more advanced.
For users, damages include the payment information that was stolen, as well as their private data and how both might be used following the attack. Hackers can use this information for identity theft, phishing and malware attacks against them and others, and more.
Another factor we must consider is the overall time it takes to discover and mitigate the attacks. Since Magecart hacking is so hard to detect, it might take a significant period of time to discover. In fact, research conducted regarding this topic by security expert Willem de Groot revealed that the average Magecart attack on a typical eCommerce website lasts 12.5 days. Even then, there’s a good chance that the same site will be hit again and again, as we’ve seen in the case of Techrabbit. Overall, it’s safe to say that the implications are considerable in terms of cost, for all parties affected.
Leading by example
To better understand how Magecart attacks work, let’s follow a simulated example we’ve conducted on the Plume website.
A visitor on the website meets a request for information. In this case, hackers created a recall information page that visitors might very well consider a legitimate page created by Plume. To supposedly check their recall status, visitors are asked to provide certain information defined by hackers, which is then collected and used maliciously. Some hackers will actually announce to users that they have just been attacked, but definitely not most. Normally, they will just go on to use the data and continue to hurt other visitors.
It’s very easy for hackers who have gained access to the website to ask for any information in the world and make it seem as though this is the website itself asking for legitimate reasons. Visitors don’t even have to be on a payment page, as we’ve seen in this case. Hackers study user behavior patterns and learn how to make these attacks believable enough to convince users.
How Magecart attacks can be mitigated
Because these attacks cause so much damage, companies are always looking for new tech solutions to prevent and stop them. The following are the alternatives currently offered:
- Content Security Policy (CSP): Websites may choose to create a whitelist of the domains allowed to host 3rd party code for the website. This technical solution does not provide any additional layer of security, and attacks might still stem from the domains listed, but if hackers planted code that leads to their own domain it might prevent the attack. In addition, CSP usage limits the website’s agility and prevents collaborations with new 3rd party suppliers in a way that might affect the website’s UX.
- Subresource Integrity: Another traditional approach which asks for the code to be provided in advance and then detects changes and alerts on the website. This is a limited solution, as there are many false alarms surrounding justifiable changes. It also has a negative influence on the website’s relationships with external suppliers and can damage the bottom line due to 4th parties being blocked by default.
- iFrames: Inline frames are pages that allow websites to upload content into a restricted environment. This solution often results in 3rd party content breaking and simply shutting down once suppliers detect that this is an iFrame environment.
- Application Security Testing: This development-oriented solution is more relevant to web applications, testing and alerting of any malicious behavior. One main disadvantage of this solution is that it is not meant for 3rd party tools and remains mostly ineffective when it comes to Magecart attacks.
You’ll find more information about these alternatives on this recent blog post we recently published
Embracing real-time JavaScript Sandboxing
As we can clearly see, while presenting certain advantages, the above-listed approaches still fail to answer the need for total Magecart prevention.
Real-time JavaScript Sandboxing is different. In this case, the web server initially provides users with a virtual page, which manages the connection between the 3rd party and the browser based on policies we’ve put into place. This means that any interaction between the visitor and the website is monitored quickly and seamlessly.
If a 3rd party is compromised, the virtual page will isolate this behavior and refuse to present it to the visitor. This is actual, real-time prevention where we cut out the 3rd party’s ability to interact directly and maliciously with the page. It prevents data leakage of any kind and allows website owners to gain back control over their users’ website experience.
Summary
Magecart attacks pose a very real, very serious threat to website owners everywhere and the visitors who use their services. They turn the web into a minefield and create uncertainty that hurts businesses and individuals. Today’s companies simply cannot afford to ignore this massive threat, and those who unfortunately choose to bury their heads in the sand will wake up to a devastating reality. When a company’s website is compromised, the business itself and everything it represents is compromised. Investing the right resources, in the right solution, at the right time is what must be done.
The post Mitigating Magecart Attacks – Some Thoughts from Graham Cluley appeared first on Source Defense.
*** This is a Security Bloggers Network syndicated blog from Blog – Source Defense authored by [email protected]. Read the original post at: https://sourcedefense.com/resources/blog/mitigating-magecart-attacks-some-thoughts-from-graham-cluley-2/
