Tala Security Protects against Magecart Group Attacks


tala2-header-768

It has been a little over a year since we conducted an interview with Tala Security CEO, Aanand Krishnan . Since then, "Magecart" attacks which steal personal financial information directly from web browsers have effected millions of Internet users. Tala Security has risen to the challenge and is currently helping many large e-commerce and financial sites protect their web users from these types of attacks. In this interview, I ask Aanand about client-side attacks, why RASP and WAFs are not the right tools to to secure web clients and what the PCI council may be doing about this.
Q1 - Since we last did an interview, web based client-side data skimming attacks have become a reality thanks to the Magecart group. How is the malicious javascript being inserted into rendered web pages to steal credit card and PII data? 

Historically it wasn’t so easy for an attacker to get malicious javascript to execute on the browser. They had to either find an XSS vulnerability in the code, or find a way to be on the user device. Today, inserting malicious javascript has become a lot easier and it’s mainly due to the sprawling set of third-party services running on web sites and web applications. These third-party services include ad networks, chat agents, CDNs, performance monitoring tools, user tracking tools and so on. The way the web works, third-party code has the same privilege as first-party code, which means that an ad network sending code to the browser can access all the information stored within the browser. 

Magecart has largely targeted such third-parties. An average website has something like 50 third-parties involved and security orgs typically have no oversight of what third-parties are added and no ability to monitor compromised third-parties. 

More recently, we have seen Magecart going after vulnerable Amazon S3 buckets to host malicious code. We have also seen them use automation to be able to compromise thousands of websites in one fell swoop. We have also seen their skimmer code being sold in the dark web.

Recent research quantifies that nearly 5000 websites are successfully attacked per month and that 20% of victimized websites are re-infected within days. 

Q2 - This sounds like something a WAF or RASP should be able to protect, but they are not engineered to help this use case. Why is that? 

In a nutshell, WAFs and RASPs are completely cut-off from the Magecart attack chain.If you think of any attack, there is point of incursion, a point of data capture and a point of data exfiltration. For a security product to either detect or protect against attacks, it has to be able to monitor the attack chain.

1. As I mentioned earlier, the Point of incursion of a typical Magecart attack is not the server hosting the website, but typically one of many dozens of third-party services integrated into the website’s supply chain. A product like a WAF has no visibility into third-party services and code and therefore completely misses the point of incursion.

2. Secondly, the Point of Capture and Exfiltration of a Magecart attack is the browser. The malicious Magecart javascript code is sent to the browser, and that is where the code executes, the data capture happens at the browser and the exfiltration happens via the browser. Products like web app firewalls have no visibility into what code is executing in the browser. 

Essentially, WAFs were designed 15 years ago for a server-heavy web, whereas today’s web is a lot more front-end oriented, and browser-centric and has a significant supply chain problem. This is one of the reasons why Magecart attacks have not only been successful, but have gone undetected for months, in some cases over a year.

Q3 - Do you anticipate any direction from the PCI Council on making these sorts of recommendations to protecting web client-side users? 

The PCI council is definitely starting to take notice of Magecart, because these attacks not only cause user data theft, but also can erode trust in the web as a place of doing commerce. I cannot speak on behalf of the PCI council, but based on what I know, they are planning to issue commentary on Magecart soon.

GDPR is also a significant factor for enterprises to consider. British Airways got fined over $200 million recently because of a Magecart breach and we believe there’s more to come. 

There’s no doubt in my mind that compliance and standards are going to become very important forcing functions.

Q4 - Do customers who deploy Tala see other non-security benefits like higher shopping cart conversion rates and less help-desk tickets? 

Yes, absolutely. Malicious JavaScript running in the browser can not only steal user form data, but it can also do things to disrupt the entire user experience. Malicious code can overlay competitor ads on your site, it can even redirect your users to another website and so on. This is a big issue because enterprises spend a lot of money on SEO, social media etc., in order to bring users into their site. You don’t want to spend all this effort bringing users to your site, only to have them hijacked by malicious code at the last minute!

Tala protects the browser comprehensively against malicious code, malicious code and malicious data exchange. Although our customers today largely use us to protect data and block malicious code, they get the benefit of preserving customer web experience as well. This has a direct impact on web conversion rates, brand etc.

Q5 - Have you had any new features added or upcoming that make Tala better at stopping client-side attacks or easier to deploy? 

We have added a number of protection features to the product. One is the ability to enforce subresource integrity on the website, or SRI. SRI is a way for the browser to check for code integrity issues by comparing hash values on individual scripts. This is a very effective mechanism to protect against compromises of first-party servers and code, as was the case with British Airways recently. Tala is also focused on DOM XSS protection, and we are now able to identify DOM XSS risks, injection points etc.

We are also adding a number of new features to help enterprises understand their PII data exposure, and catch DLP in real time from the browser. For example, we find that most websites collect user form data and send it to 1 or 2 servers, but because of the massive supply chain running on these sites, the form data is actually exposed to 30 additional domains, on average. This is a very serious problem.

Performance has been our top product priority. Usually people focus on speeds and feeds, where we do extremely well. But the Tala team is also focused on operationalization. We have introduced simpler deployment mechanisms and given our customers more deployment options. For example, enterprises can now deploy Tala through nodeJS middleware, which means that they don’t have to install anything on their web server.

Q6 - Where can readers go to learn more about Tala, Magecart attacks and client-side web security?

We are adding a lot more educational content on our
website and our social media channels, LinkedIn and Twitter (@talasec). Education and awareness around Magecart and website security are sorely lacking and it is the #1 reason why Magecart has been successful.

Enterprises interested in understanding their risk exposure to Magecart and other website breaches can also get in touch with us by emailing us at websitenotify@talasecurity.io. We offer a comprehensive risk analysis and Magecart simulation to help customers identify their weaknesses.

If you are concerned about client-side web attacks, Tala Security is offering a comprehensive Magecart assessment for free to the first 20 readers of this blog to email websitenotify@talasecurity.io with the subject "free magecart assessment"!