The official Ticketmaster logo.

The Ticketmaster Magecart Attack

Starting in 2017, Ticketmaster was targeted by a hacking group known as Magecart, who compromised the Ticketmaster website via 3d-party JavaScript suppliers SociaPlus and Inbenta. The ultimate objective of the Magecart attack was to steal the Payment Card Data of Ticketmaster customers using a JavaScript keylogger on payment pages.

Because Magecart attacks typically leave no visual clues and have no impact on the normal operation of the site, detection can be difficult, and it's often not until the customer Payment Cards are loaded with fraudulent charges that a Common Point of Purchase can be identified to reveal the source of the attack.

The Fundamentals of a Magecart Attack

There are only two, simple steps required for a Magecart attack to succeed and if an attacker can complete both of them, the impact can be significant.

  • Inject malicious JavaScript into the page.
  • Steal sensitive data from the page.

To inject their malicious JavaScript into the Ticketmaster website, the attackers didn't need to find a vulnerability in the Ticketmaster site itself. The attackers instead chose to target the JavaScript supply chain of the Ticketmaster website, which is just as effective and is often a more attractive proposition to the attackers.

As a website operator, whilst it would be ideal to successfully neutralise both of these risks, it is sufficient to only neutralise one of them to stop the attack, and, you can focus on only sensitive pages like Payment Pages or your Login Page.

Managing JavaScript Dependencies

Using a Content Security Policy, organisations can take strict control of what JavaScript dependencies are expected and permitted to load across their site and with Script Watch, you can even monitor those dependencies on an ongoing basis and be notified about any changes. With a 3rd-party compromise such as the case here with Ticketmaster, these compromised 3rd-party dependencies would be expected and permitted to load, but, we still have solutions available to mitigate this attack.

Alongside a Content Security Policy, the use of Subresource Integrity allows a site operator to ensure that any JavaScript permitted to load has not been tampered with and remains free of malicious code. Report URI always recommends the use of SRI on any 3rd-party JavaScript, in addition to the following detection capabilities for Magecart attacks.

Ticketmaster confirmed that a Content Security Policy was not used prior to the Personal Data Breach.

- Information Commissioner's Office (Penalty Notice)

Monitoring Data Exfiltration

As an e-commerce site, it was part of the normal operation of the site for a customer to enter their Payment Card Data, along with other sensitive PII, like their name and address, into the page. The page then needs to send this data somewhere to be processed and this is where the attack can be reliably detected.

The attackers used a Drop Server located at webfotce.me to send the data that their JavaScript Skimmer had stolen from the Ticketmaster Payment Pages where it could later be recovered. As with all client-side attacks of this nature, the data needs to be exfiltrated and the communication from the Payment Page to webfotce.me could have been detected or even blocked.

Content Security Policy allows you to take full control of where your site can send data, and, using Data Watch, you can be notified if your pages start sending data to a new location, resulting in a Data Breach. Leaking sensitive data like PCD or PII can attract the attention of Privacy Regulators, especially in light of recent regulation like GDPR, and attract heavy fines like that of the ICO, the data regulator in the UK, who fined Ticketmaster.

The amount of the penalty that the Commissioner has decided to impose is £1,250,000

- Information Commissioner's Office (Penalty Notice)

How we can help

You don't need to spend time developing and maturing a Content Security Policy to work perfectly on your site in order to leverage our tooling. To use products like Script Watch or Data Watch, you can get started with auditing your JavaScript Dependencies and Data Exfiltration Endpoints with a single line of code or config.

Once that single line of code or config is deployed, we can establish a baseline for your site and then our Script Watch and Data Watch products will monitor and alert you to any changes on your site for you to investigate immediately. Often, one of the most damaging aspects of a Magecart attack is that they can go undetected for days, weeks or even months, increasing the scale of the Data Breach as they go.

In addition to this, we have a selection of features and tools detailed below that will help you get started with CSP and work through to enforcing a policy across your whole site, but please reach out to sales@report-uri.com if you need more information.

Average length of a Magecart breach: 22 days

- RiskIQ (Magecart: The State of a Growing Threat)

Script Watch

Script Watch will monitor all JavaScript dependencies across your entire site and immediately notify you of any changes. A new JavaScript dependency could be the start of a Magecart attack.

Because Script Watch leverages the browser native Content Security Policy, there is no code or agent to deploy and running in the browser means we analyse your site in real-time as your users are browsing. We don't have the same limitations as external scanning services such as authentication or pay walls, geo-sensitive content or an attacker potentially serving safe content to the crawler.

Read More

Data Watch

Data Watch will monitor all of the locations that your webpages are sending data to. If your website starts sending data to a new location, it could be the start of a Magecart attack.

With Script Watch and Data Watch combined, you can monitor for clear indicators that your site has been compromised. Attackers will always want to inject their hostile JavaScript, and they'll always want to exfiltrate their stolen data.

Read More

The CSP Wizard

We often find that creating a CSP is the first difficult step that organisations face. Having a complete list of all resource dependencies across your entire site like images, scripts or styles, from both 1st-party and 3rd-party locations, is tough to achieve.

The CSP Wizard was created to solve this problem, and in seven days or less, it can you give a complete list of all resources used across your entire site.

With the list of all resources you use on your site, and our easy to use tool, creating a viable Content Security Policy is easier than ever with just a few clicks.

Documentation

The CSP Builder

All Content Security Policies will need to be tweaked at some point. New resources may be added to the site or old resources removed, and the policy needs to be updated to reflect those changes and kept up to date.

You can import your existing policy into the CSP Builder and use our fully featured tool to make any changes that you require right there in the UI. When you're done, hit Generate, and the CSP Builder will provide you with your new, updated policy.

CSP Builder

Content Security Policy

Script Watch and Data Watch will allow you to rapidly detect and respond to a Magecart attack and combined, that capability puts you ahead of the field. If you want to take it a step further, Content Security Policy can mitigate a Magecart attack and stop it from even happening.

Deploying an effective Content Security Policy can be difficult, but our CSP Reporting allows you to gather feedback and safely test a policy before deployment. Once deployed, an effective Content Security Policy will block a Magecart attack and stop the hostile JavaScript from even running.

Read More

Threat Intelligence

We subscribe to various feeds of Threat Intelligence data, along with managing our own internally generated feeds, to keep apprised of the latest threats that exist online.

Using this Threat Intelligence Data, we can better analyse the sources of JavaScript on your website and detect malicious activity sooner.

Read More