JavaScript PCI nightmare: Ticketmaster, Inbenta and the canary in the coal mine
As you may have read, Ticketmaster had a breach of personal information and credit card details — here’s their breach report website.
Ticketmaster are no small chicken — they list nearly 7000 employees online and they have a dedicated Information Security department as they’re an online only ticket buying service — so it’s worth digging in to what happened.
JavaScript in your PCI payment process
Ticketmaster blame Inbenta, a chatbot AI provider, for the breach. Inbenta have pulled links to Ticketmaster’s customer case study, and instead provided their own incident report. In their incident report, Inbenta blame Ticketmaster.
Inbenta’s chat bot works, for website developers, by providing a single line of HTML which calls a Javascript from Inbenta’s web server.
Javascript allows controlled code execution via a website, for example to redirect traffic from forms, or run a chatbot assistant.
Inbenta say they provided Ticketmaster with a custom .js file hosted on their server — they also say Ticketmaster placed the chatbot code on their payment processing website unknown to Inbenta. This means that Inbenta’s webserver was placed in the middle of all Ticketmaster credit card transactions, with the ability to execute Javascript code in customer browsers. Ticketmaster have now stopped using Inbenta services.
According to Inbenta, back in February 2018 somebody altered the Ticketmaster JavaScript maliciously. This is the start of the issue. Monzo provided a timeline around how they discovered fraudulently Mastercard transactions tied to Ticketmaster in April 2018, including a visit from Ticketmaster. Ticketmaster’s statement by contrast says they discovered the issue in June 2018 — I presume two months was taken to identify the issue being the Inbenta integration.
“On Saturday, June 23, 2018, Ticketmaster UK identified malicious software on a customer support product hosted by Inbenta Technologies, an external third-party supplier to Ticketmaster.” — Ticketmaster
Mitigating these kinds of attacks
Here is the thing — web developers should be extremely careful what third party Javascript code is placed within the payment and personal information processes of their sites. Businesses should make a risk assessment around this — not just due diligence, but seriously assess the risk and impact of a breach of a third party on their business. I’ll give you a spoiler: the risk is very real — this isn’t the first time this has happened, somebody who works for PCI post breach assessment told me that over 75% of all web store breaches they assessed at large enterprises happened due to this reason, a massive increase. The impact is huge — for example, attackers can read and store CCV numbers on cards via Javascript, as they are ‘live’ in the customer web browser.
In the world of online payment security, companies are investing heavily in PCI standards compliance, risk, resourcing, encryption etc — the situation on that end is actually (believe it or not) beginning to improve for businesses — especially in a post GDPR world.
However, attackers are looking for other links in the chain to exploit. Cracking AES encryption? Not happening soon. Breaking into the webserver of a chatbot provider? Yes, that is happening. As Inbenta point out in their incident report, a single line of HTML code in Ticketmaster’s website led to this issue.
The canary is dead. Check your supply chain. Because attackers are.
Update: back in May 2018, Ticketmaster were notified of the issue however the social media team failed to follow up the issue:
This is the server, if you want to check your work logs to see if anybody got owned:
According to VirusTotal, Symantec started to identify inbenta.js (Ticketmaster version) as an “Infostealer” back in May:
I can see the Javascript file being uploaded to a variety of threat intelligence tools from April through just before the breach announcement, so clearly somebody was looking into it. For example Hybrid Analysis showed the file as malicious in late April:
Using VirusTotal Intelligence I can see both antivirus firms and web filtering firms detected attacks on February 14th 2018 (which appears to be when first compromised):
Unfortunately it looks like all the warning signs were missed here.
