Magecart Attack
The previously disclosed Ticketmaster payment card theft attack was not a one-off event, but instead part of the largest payment card theft in history impacting over 800 e-commerce sites around the world. If we consider the true impact of this event it is absolutely astonishing. The Target supply-chain-enabled attack from a few years ago was frightening, and that was only one merchant under attack, on in-store point-of-sale systems, for a mere
9 days. The Magecart website supply chain attack leveraged digital website payment card skimming that victimized over 800 global merchants for over 3 years – multiple orders of magnitude larger and significantly more chilling in scope.
The Magecart hacker group successfully attacked some of the most sophisticated e-commerce players and operated largely undetected since 2015 by taking advantage of a client-side vulnerability that exists in every commercial website today. In the case of Ticketmaster, Magecart actors were able to compromise a 3rd party chatbot service called Inbenta that had been embedded on the Ticketmaster site. By manipulating the Inbenta JavaScript code on Ticketmaster’s webpages, Magecart could exfiltrate payment information from every single Ticketmaster customer who was served the Inbenta code.
The client-side browser is the primary environment wherein websites display and capture critical customer and payment data. It is the front door for interaction with customers and their data. 3rd party JavaScript executes on the client-side browser and is granted unmanaged and unlimited access to the entire web page including the ability to exfiltrate data (keylogging, web injection, form field manipulation, phishing, etc.) and deface/alter web page content. Simply put, by integrating 3rd party JavaScript, website owners are handing out skeleton keys to the front door while they focus extensively on securing the server-side back door. Security pros must think twice about being so cavalier with the skeleton keys to their front door and diligently secure both the server side and the client side of web sessions.
Given that many 3rd party vendors have comparatively weaker security protocols than the corporate websites that run them, it makes them attractive and susceptible attack targets. 3rd party JavaScript has unlimited access to the web page DOM. This means that every 3rd party JavaScript vendor, and the hackers that seek to exploit them, have the same level of access to all web page elements as the website owner?s development team.
What Are the Potential Damages?
Once that vendor is compromised, their code can be modified or replaced representing a major vulnerability for website owners. Magnifying the potential damage, once a hacker compromises a single 3rd party vendor, they have access to every single website that runs the tool.
3rd party JavaScript is served from external remote servers and executes on the client. This makes current security approaches such as pen testing, periodic code review, and dynamic application security testing entirely incapable of preventing these attacks. Since client-side connections with external servers are completely unmanaged and largely unmonitored, the company has no visibility into what these 3rd parties are doing and no way to prevent hackers from maliciously exploiting this access. Nearly every corporate website is currently
unavoidably vulnerable to this attack vector.
Request an Expert Walk-Through of Data Exfiltration from Your Site
Here’s What You Can Do
Luckily, there are steps that can be taken to mitigate or even eliminate the risks of 3rd party JavaScript. Below is an overview of the practical considerations website owners can leverage to protect their companies from the security and privacy risks introduced through 3rd party JavaScript code.
Prevention is the best option
The best thing security pros can do to prevent an attack is to implement technology that controls the access and permissions of every 3rd party JavaScript vendor running on web pages. This insulates websites, their visitors and private customer data from the inappropriate or unwanted behaviors of 3rd parties and the more malicious activities of hackers that seek to exploit them.
Prevention approaches for addressing client-side connections not only secure the organization but are required for adequate data control defined by regulatory compliance (e.g. GDPR and California’s newly passed Digital Privacy Law). Without the ability to control private customer data and prevent unauthorized access by 3rd party website vendors or hackers, an organization is in a state of non-compliance.
Content Security Policy (CSP) enables administrators to specify the domains that the browser should consider to be valid sources of data, meaning on data from these whitelisted domains can be loaded to the page. This ensures that only JavaScript received from whitelisted domains will be executed. While this methodology can contribute to website security effectiveness, it will not mitigate a breach coming through a whitelisted domain (or vendor). CSP also introduces new challenges for R&D teams as CSP requires substantial configuration and ongoing maintenance. CSP can cause 3rd party tools to stop working when 3rd party JavaScript updates are not accommodated in the CSP.
Sub-Resource Integrity (SRI) adds a cryptographic hash to JavaScript allowing browsers to verify that files they fetch are delivered without unexpected manipulation. This provides a path to ensure malicious JavaScript won’t be loaded from compromised 3rd parties. However, SRI is notably complex to apply to dynamic JavaScript code. The majority of 3rd party JavaScript vendors continuously improve their services, which results in frequent changes to JavaScript. Adapting SRI to match this dynamic nature can be burdensome and can result in problematic false positives which detract from website effectiveness. In addition, there are many services with dynamic JavaScript that change per user. In these cases, SRI is not effective.
Source Defense VICE provides dynamic prevention for attacks of 3rd party origin. Source Defense’s patent-pending solution allows security teams to set and enforce security policies to ensure total control of all 3rd party vendors operating on web pages.
Source Defense is easy to deploy, and even easier to manage and maintain. Utilizing machine learning, market best practices and supervised by our data matter experts, the Source Defense platform automates the initial policy definitions thus simplifying administration, deployment, and ongoing 3rd party JavaScript integration. Policy settings may be modified by the administrator, but the system is continuously consuming experiential data to eliminate the need for cumbersome, ongoing maintenance.
By removing the security considerations from 3rd party integrations, Source Defense saves countless man-hours spent on tests and integrations. This allows website owners to focus on enhancing user experience and driving web commerce revenues while ensuring the security and privacy of private and payment data.
Application Monitoring
Monitoring provides a detection-based approach that provides a less secure, reactive methodology. The major inadequacy of detection approaches is that they are incapable of preventing attacks. These include technologies like DAST and RASP. Even with a multitude of global sensors, detection schemes often miss highly targeted and hyper-segmented attacks altogether. Additionally, a detection event signals leakage of customer data and constitutes a compliance violation that requires disclosure. The resulting fines, PR crises, remediation, and operational fire drills are often significant. Fundamentally, these approaches are not scalable, and the persistence of the underlying vulnerability renders these approaches ineffective.
Vendor due diligence assessments
Many organizations, and especially those under strict compliance mandates, perform routine, comprehensive vendor security assessments. Although well-intended and highly recommended, such exercises provide point-in-time assessments. They do not provide prevention or even continuous detection. Although these assessments should be part of a comprehensive security program they are in no way adequate as a stand-alone approach to mitigating or preventing website supply chain 3rd party risk.
Restricting the usage of 3rd party tools
Exercising a debilitating level of caution by limiting or restricting the usage of beneficial 3rd party tools on websites is generally counterproductive to the overall goals of the business. Limiting the number of tools able to be deployed on an organization?s website limits the ability to provide an engaging user experience and extract meaningful analytics. This methodology makes delivering a compelling, differentiated, and dynamic web presence difficult.
The Time to Act is Now
It’s likely that the thousands of sites compromised in this attack are just the tip of the iceberg given the amount of time that this attack was running undetected. Similar attacks on major global airlines, online electronics merchants, online mass merchants and credit rating agencies have recently been reported as exploited by this same attack vector. 3rd party vendors have shifted blame to site owners to incorporate the necessary security measures themselves. It is therefore
critical that site owners proactively employ preventative technology to prevent website supply chain attacks and continue to benefit from the differentiating utility they provide.
Next Steps
Quickly access an assessment of your current risk level:
Checking your exposure
If the industry wide susceptibility to this attack vector does not have you concerned about your own current vulnerability: Request a customized expert walk-through of data exfiltration on your site
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.
