British Airways Breach (2018)

I wanted to talk a little bit about the British Airways breach; I won’t be focusing on the intention to fine from the ICO. I’ll just be talking a little about vulnerabilities, how they can be addressed, and the issues mitigations may bright. I’ll also be talking about a security incident that hit the ICO and how it was potentially very similar to what happened to British Airways.

On 08 July 2019 the ICO released a statement, that their intent to fine British Airways was announced to the London Stock Exchange and that the fine was set at £183.39 million.

Willie Walsh, Chief Executive of IAG (BA’s parent company), stated:

“We intend to take all appropriate steps to defend the airline’s position vigorously, including making any necessary appeals,” he said.

Which shows that BA does take defence seriously!

Breach Announcement and Compromised Transactions

So in short, what happened? September 6^th 2018, British Airways announced it had detected the theft of customer data and tweeted:

“We are investigating the theft of customer data from our website and our mobile app, as a matter of urgency. For more information, please click the following link: https://t.co/2dMgjw1p4r” — British Airways via Twitter September 6, 2018 (Tweet now deleted).

The link led to a page which explained: “We are investigating, as a matter of urgency, the theft of customer data between 22:58 BST August 21 2018 until 21:45 BST September 5 2018 from our website, ba.com, and our mobile app.”

In interviews with the BBC, published September 7^th 2018, British Airways noted about “380,000 transactions were affected, but the stolen data did not include travel or password details.”

It did however include payment card numbers, expiry dates, and CVV security codes.

Interestingly, British Airways were not the only people to push out an update about the breach. Monzo also pushed out a message that they had proactively cancelled affected customer’s cards (about 1,300 Monzo customers were affected) and dispatched replacements. According to their own statement this process took 3 hours and included an in-app message explaining the action they were taking and why they felt it necassary.

After discovery, British Airways appears to have disclosed the breach quickly; within one day. However the breach lasted months.

The number of customers affected was initially set at 380,000. However, this was adjusted on 25 October 2018. An additional 185,000 transactions were found to have been compromised between April and July 2018. Of the 185,000 transactions 77,000 included name, billing address, email address, payment card number, expiry date, and CVV security code. The other 108,000 transactions did not include the CVV.

At the same time, the original 380,000 transactions was reduced to 244,000 transactions affected between August and September. Which brings the total to around 429,000 transactions compromised.

How did the breach occur?

The full details of how the website was compromised have not been released yet, however RiskIQ published a likely theory. They posted on September 11 2018, that the nature of the disclosure led them to immediately suspect MageCart was involved. In part this was due to the disclosure mentioning that only the site (and not supporting infrastructure or databases) was compromised and that the compromise was between very specific dates (22:58 BST August 21, 2018 and 21:45 BST September 5 2018).

RiskIQ supported the Magecart claim by showing that the British Airways website had a third-party (but self-hosted) script which appeared to have been modified to include code to exfiltrate payment data from the payment page.

In short, the British Airways site used an old version of Modernizr (2.6.2 released September 2012) which was appended with a script that serialises the payment form contents and sends it to “baways.com” a site which is not under the control of British Airways.

There were several reports referring to the issue as a cross-site scripting vulnerability. For example Wired reporting here that:

“These details served as clues, leading analysts at RiskIQ and elsewhere to suspect that the British Airways hackers likely used a “cross-site scripting” attack, in which bad actors identify a poorly secured web page component and inject their own code into it to alter a victim site’s behavior.”

Interestingly however, neither the linked BBC article, nor the RiskIQ article appear to use the phrase “Cross-site Scripting” or the short form “XSS”. One article lists many protections for XSS, although it appears unlikely that many of these steps would have prevented this attack.

There was confusion around the actual vulnerabilities used, for example one article stated that the vulnerability in Modernizr was well known:

“The vulnerability in Modernizr is a well-known one, and BA had not updated it since 2012 – long after problems were known to exist.”

However, it does not appear that Modernizr itself was exploited, the file was simply modified through other means. The fact that the modernizr version was outdated does not appear to be directly relevant. Although it could indicate wider issues at British Airways around keeping systems and libraries up to date.

Code doesn’t become more vulnerable as it gets older, it’s not like food that goes off – however if a vendor releases a security update to fix a known vulnerability and you don’t apply it, it could make an attacker’s life a lot easier.

Whist we’re talking about outdated JavaScript libraries though, how common are they? According to research by Northeastern University more than 37% of sites use use at least one library version with a known vulnerability.

So far, no specific details on how the file was modified have been released. However Magecart are believed to have compromised around 17,000 websites by modifying JavaScript files stored in S3 buckets.

The details of the British Airways breach are also very similar to an earlier attack which affected around 4,000 websites in February 2018. This attack appears to have affected the Information Commissioner’s Office own website. The short story to that breach was that a third-party script was maliciously modified, allowing attackers to inject crypto-currency mining software into victims web browsers.

The affected script was Browsealoud, which many sites were including on their sites by linking to the script stored on the vendors site – something the vendor requested from users., as the file had a comment which said:/* [Warning] Do not copy or self host this file, you will not be supported */

The difference with this breach, other than an intent to fine marked over £183 million, is that personal data was not the target and therefore does not appear to have been compromised.

How Can Companies Protect Themselves

The first step should be to minimise the attack surface; for pages that are particularly sensitive remove unnecessary scripts from those pages. For example, if you do not require third-party JavaScript libraries on your payment page, remove them.

For those scripts that you do deem necessary, you can protect against malicious content using both Content-Security-Policy (CSP) and Sub-Resource Integrity (SRI). I’ve previously written about CSP, so I’ll discuss SRI here.

Sub-Resource Integrity is a browser protection which has been around for a quite a while. Edge implemented it EdgeHtml 7 on 30^th April 2018 and Chrome appears to have enabled it by default it in Chrome 45, released September 2015.

SRI is fairly simple to add; it requires you to alter the way that you import resources. For example, instead of simply linking to the script, you need to include a few additional attributes, such as:

<script src="https://example.com/framework.js" integrity="sha384-cGxlYXNlIHJlcGxhY2UgbWUgd2l0aCBhIGhhc2ggb2YgdGhlIGZpbGUgY29udGVudHMu" crossorigin="anonymous"></script>

The above code snippet uses a SHA384 hash of the script content to check if the file has changed, you can generate these hashes using a command such as:cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A

When the resource is requested, the browser will compute the hash and if it’s different to the one supplied by the application, then the file will not be included. This could break the page functionality – but it’ll stop the malicious code from executing and prevent the attack.

Timeline

Read More

• TalkTalk Breach (2015)
• Target Breach (2013)