The British Airways Hack: JavaScript Weakness Pin-pointed Through Time-lining

The British Airways Hack: JavaScript Weakness Pin-pointed Through Time-lining

Why Modernization Is Not A Good Thing

A few years ago I predicted that JavaScript would soon be a dead language as it has fossilized itself and was just so clunky to use. How wrong could I have been, in that it now rules the roost in terms of making Web pages more dynamic. But it is now opening up holes on the Internet, and it is suspected that it was behind the British Airways hack.

There was great speculation that the hack had been caused by JavaScript, as the company defined that they did not store CVV numbers, but released a statement after the initial incident report to say that they could have been involved in the data capture. This pointed towards a JavaScript injection attack, and where over 3 80,000 credit card details could have been breached.

The research team at RiskIQ found the clues to the JavaScript injection by noting the time frame of the hack, and then noticed that the modernizr-2.6.2.js file had been changed just two hours before the start of the date of the breach defined in the British Airways press release (20:49 GMT, 21 August, 2018). This file had not been changed since 2012.

It is thought that the Magecart hacking group had added just 21 lines of code to the file, and where the ba.com site was a heavy usage of JavaScript.H ere we can see the integration of Modernizr [code]:

It is likely that the hackers had access to the BA.com site, and modified the code to insert a backdoor.

Modernizr is a JavaScript library for enhanced interaction, but was modified to capture data from the payment form, and send the data onto a server located in Romania. The code itself was built on the standard code:

Overall the hackers modified the modernizr-2.6.2.min.js script so that it captured a mouse event, and then gathered the form data and sent it to baways.com (and where it even had a digital certificate on the site):

Both the mobile app and the Web pages used this back-end JavaScript, and thus both were compromised. X-option headers and CSP code integration are one way to enhance the detection of code injection, but, unfortunately, the ba.com site achieves a lowly D grade on its integration of these methods [scan] with only iframe injection being detected:

Ticketmaster hack

The Magecart group have also been pin-pointed, too, for a recent hack on Ticketmaster, and which was reported on Wednesday 27 June 2018. It affected around 40,000 users, and 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 their 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 2018, 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.

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.

Conclusion

JavaScript integration has grown arms and legs, especially as we have moved more processing away from the server, and towards the browser.

Lessons learnt:

• Analyse the risks of JavaScript whenever there are credit card details involved.
• Continually monitor the usage of pages to spot changes or unusual behaviour.
• Companies processing payments on sites need to have good threat intelligence.
• Sandboxing of the pages to analyse their operation should be run on a continual basis.
• Strong linkages are required with third party organisations, in order to spot credit card frauds at an early stage.