Incident Report Guessing: Chatbots, the BA Hack and Ticketmaster

One of the major problems with current incident response reporting is that it lacks a great deal of detail, and basically just gets a…

Incident Report Guessing: Chatbots, the BA Hack and Ticketmaster

One of the major problems with current incident response reporting is that it lacks a great deal of detail, and basically just gets a message out that there has been a hack. This leaves industry experts crawling over bits and pieces of information, in order to make sense of the attack. There are some hints that it could have been caused by 3rd party JavaScript integration (which changed on the first day of the data breach), but this has not been confirmed yet:

There is also speculation that the BA hack related to a similar mechanism to the Ticketmaster hack. I must say there is no current evidence of this, but here’s an outline of the Ticketmaster hack, and how it was detected by an external organisation (Monzo).

Introduction

The reporting of the breach happened on Wednesday 27 June 2018 and outlined that around 40,000 users had been affected, and included included credit card payment data, addresses, name and phone numbers.

The detection of the breach was on 23 June 2018, and within dates of the announcement, there were already reports of users being scammed. Every user on the site was then advised to change their password, if they used the same password on other sites. This worried many, as Ticketmaster were hinting that there hashing method used to store password could have been crackable.

It is likely that the breach had been occurring for several months, and it was detected by a third party (Monzo). Monzo have since defined that they detected the frauds on 6 April 2019, and where around 70% of its users who reported a fraud, had also bought tickets (and where just less than 1% of their customers were using Ticketmaster at that time).

Monzo told Ticketmaster about this … and Ticketmaster did very little about it:

Our investigation shows no evidence of a breach, and we don’t believe we’re the source of this’ and now several months later, it comes up that they’ve been breached all this time.

But the statistics were showing that there was an extremely high probability that a hack had occurred. Monzo then issued new cards for all the affected users. The facts are that Ticketmaster had not been hacked, but it was a subcontractor: Inbenta Technologies.

How did it happen?

Inbenta operated a chat bot and had taken some standard JavaScript code, and modified it for Ticketmaster. Ticketmaster then ran this code for a chat service, but also used it on their payments payment (without Inbenta knowing about this). Unfortunately hackers found the script and were able to modify it to harvest user data (from February 2018 onwards). Inbenta then fixed the vulnerability on 26 June 2018.

The technical reporting of the incident, too, perhaps shows many weaknesses, and it is almost impossible to make proper judgements on the scope of the breach. Very little has been published on the encryption used, or on the password hashing method (and where the passwords were even hashed?). A hashing method of BCrypt would be seen as good practice, but to use a fast hashing method would, possibly, allow virtually all of the passwords to be revealed (and then used on other Web sites).

Conclusions

Ticketmaster will be investigated by the Information Commissioner’s Office (ICO) and they will decide whether they will be liable against the 1998 or 2018 Data Protection Acts or — more scarily — against GDPR. We need to use statistics in order to detect beaches, and especially anomaly detection. In this case the stats showed there was a problem, but where the company could not see it.

The incident reporting, too, has been extremely weak, and companies need to have better incident response plans, in order for professionals to understand the risks involved, and thus provide advice to users (and also to improve on current practices).

We all see anomaly detection in practice, and where our banks will detect a change in our spending pattern or something out of the ordinary. For example if I’m in Aberdeen purchasing petrol, and then five minutes later I’m in Switzerland, the system will detect that something isn’t right, and reject the payment request. Increasing we live in a world where we must defeat human-sourced hacks, and there is often no signatures for those activities.

The full story from Monzo is here:

Companies need to get better at reporting the technical details of a hack, otherwise there will be speculation until the evidence is revealed. The word on the wires is that this hack could relate to a 3rd party integration of JavaScript, and which could have been compromised, and forwarded data to malicious entities. This has not been proven yet, and should just be seen as speculation.