how-things-work
Matthew Gast
By Matthew Gast
Posted On August 16, 2018

Analysis of the Ticketmaster Breach

Data Breach | CSP | Application Security | PCI

Although there have been a number of breaches in the last few weeks, the story around the breach at Ticketmaster is more interesting than most. It combines sophisticated web design, re-usable components, the security model of the web browser, and even a dash of payment regulations.

ticketmaster-data-breach 

The breach itself is interesting because many breaches take place on the server side of an application. As a result, the focus of many security products is to enable IT departments and the security teams within them to defend resources you control. Historically, these have been servers in your own data centers, though increasingly applications are now built on services that you rent but have control over. Draw a line around the resources you own, keep hackers out, and call it a day.

 

Application architecture is increasingly heterogenous. Making an application is, if you’ll pardon the terrible pun, like being a chef. You start with a list of ingredients, and when the result isn’t quite right, you can add a dash of something to come up with the perfect dish. Rather than having to build the entire application yourself, it’s much more like assembly.

 

In the case of Ticketmaster, they decided to add a chat function. Fortunately for application architects, there is a competitive industry in supplying chat functions to web sites. Ticketmaster chose to use a company called Inbenta, which works by having the web application host a JavaScript for chat functionality. Unfortunately for Ticketmaster, once you let a script run, it has access to everything that’s in the web browser. You’ve just given your chat supplier access to everything that’s on the page, including the credit card transactions. Whatever security model was in place on the application servers is now irrelevant, because the best way to compromise the application is not attacking the heavily fortified application itself, but to attack the web component that has access to … everything.

 

Let’s face it: pre-Tickemaster breach, how many IT security teams would have been able to link the addition of a third-party component to the overall security of the application? My guess is not many. UK bank Monzo described how they discovered the breach because they were able to associate credit card fraud with cards that had been used at Ticketmaster and compromised. (By one account, the compromise may have been aided by a one-line modification to the chat script.)

 

The existing PCI standards are, I’m sure, catching up to these changes in application design. One of the advantages of PCI is that is highly prescriptive, and tells a security team exactly what needs to be done. The disadvantage of a prescriptive approach is that it needs maintenance to address new threats.

 

What can an application security team do to defend an application against embedded components? After all, security applies to the application as assembled, and now your security depends on being able to protect the application against attack vectors that may affect components you have no control over.

 

Scripts are powerful because they have access to the entire page. The two ways to use scripts more safely are to ensure that the scripts are not altered, and that they are given clear communication channels to only the resources they need. To maintain script integrity, you can use the sub-resource integrity tag, but that requires maintaining hashes for each script. To keep scripts from communicating data back to attackers, a Content Security Policy (CSP) can restrict where an application can communicate to, and the web browser will prevent connections to anything not on an allowed list. tCell can automate both script integrity and CSP, so if you need to protect an application from the components, give us a call!