Ticketmaster UK has fallen victim to a security breach. The TLDR is pretty straightforward - but the detail is where things get interesting. Mainly because of how Ticketmaster is handling it, and how the banks and payment processors are reacting.
First Published 29th June 2018
When you blame others, you relinquish the mandate to change.
4 min read | Reflare Research Team
This week saw Ticketmaster - the world’s largest seller of event tickets - fall victim to a hack and subsequent data breach. While the hack itself is unspectacular, the interplay between vendors and banks is typical for unsuccessful incident response. In this briefing, we will take a look at the details.
What happened?
On June 27th, Ticketmaster released a statement informing its customers of a possible hack and breach. The statement claims that a third-party product developed by Inbenta Technologies was to blame for the incident, that less than 5% of users had been affected and that immediate measures had been taken. This is standard procedure for breaches.
The fact that Inbenta Technologies develops integrated chatbots and that such software has repeatedly been the cause of breaches in the past only makes the incident look like even more of an open and shut case.
However, unlike most cases, this incident has seen follow-up statements being released by both Inbenta Technologies and UK-based bank Monzo, which allows us to paint a more complete picture.
Inbenta Technologies’ Statement
In a somewhat unusual move, the developer of the 3rd party chatbot that led to the breach went on public record to contradict the statements made by its customer. According to Inbenta Technologies’ CEO Jordi Torras, the vulnerability existed in a script that was customized specifically for Ticketmaster and was never designed to run on a payment page. Software is commonly designed with different levels of risk in mind. While naturally all vulnerabilities should be avoided, more care is usually paid to software that is going to run in a payment context.
While the responsibility for the vulnerability itself remains with Inbenta Technologies, this muddies the clear line of responsibility for the subsequent breach.
Monzo Alerts Ticketmaster
While Ticketmaster states that it had become aware of the breach on June 23rd and took immediate action, Monzo states that they alerted the retailer of fraudulent activities as early as April 6th. Apparently, the company saw a significant uptick in credit card fraud cases linked to customers who had recently made purchases on Ticketmaster.
Such patterns should be cause for alarm as they are very unlikely to happen randomly. Still, Ticketmaster allegedly responded to Monzo’s alert by stating that they “had found no evidence of a breach and that no other banks were reporting similar patterns”.
This is unlikely to be a lie. Most likely Ticketmaster did have internal auditing results for the timeframe in question which showed no abnormal activity. Since the vulnerability was inside of a chatbot embedded as JavaScript, credit card numbers and private information was most likely stolen before it ever hit Ticketmaster’s servers - thus making detection quite difficult.
Nonetheless, it appears that Ticketmaster was informed of statistical proof of a breach as early as April and failed to identify the vulnerability for two months.
As mentioned above, this doesn’t make the company at fault or liable, but significantly muddies the timeline when compared to Ticketmaster's own release.
Summary
The Ticketmaster breach is somewhat typical for corporate data breaches; Third-party code is used in a security context that it wasn’t designed for. A vulnerability is discovered and abused at some point but the attack remains undetected. Even when reports of payment fraud are received, they aren’t investigated with the thoroughness and zeal required to uncover the attack.
And most typically, once the hack is finally uncovered, as much blame as possible is shifted to other parties while each side is downplaying its role in the incident.
Mitigation for this kind of scenario is tricky, since every party can act reasonably and still contribute to the problem. As general guidelines, organizations should make sure to:
1) Take all reports of unusual fraud activity linked to it very seriously. Even if a breach is not immediately apparent, repeated fraudulent charges on credit cards used on a specific website are a very strong indicator that something is wrong.
2) Develop a proactive information security strategy. Even if the actual fault lies with a third party, a large part of the PR damage cannot be deflected.
3) Only use 3rd party tools in the context that they were developed for.