The Third-Party Script Breach That Shook The World

How the British Airways' data breach kickstarted today's toughest web security challenge

by c/side.dev

The story below is brought to you as educational material and is in no way a criticism towards British Airways' security operations. At the time of the attack insufficient security tooling existed to detect attacks leveraging 3rd party resources. To this day the majority of tooling is unable to detect advanced attacks of this particular type.

It happened between August 21 and September 5 2018. During those 16 days, a sophisticated cyberattack hit the British Airways website and app. It exposed the personal data of roughly 300,000 to 500,000 customers.

Payment data were copied and sent to baways.com, a domain that looks very much like the official website and set up specifically to deceive.

You have landed on baways.com. The shady stuff is gone. This domain now serves a new purpose: telling the story of what went down.

This is not just a chilling story from the past. Every day, somewhere, a company faces this kind of challenge. The British Airways hack in 2018 made headlines all around the world and kept the airline in a hot seat for years. The 2018 British Airways Data Breach reminds us of the ever-present threat of cyberattacks.

In 2020 the published its Monetary Penalty Notice.

In this case, the ICO proposed an unprecedented fine of over £183 million for failing to keep customers' data safe. Some of the details of the breach remain undisclosed to this day.

A stack of paper cutouts, one of which is a laptop with hands at the keyboard on top of a cutout of the script that executed the attack

22 June 2018

Gaining access and gathering intel

On June 22, the attacker sneaked into British Airways' systems using a remote-control access tool, Citrix Access Gateway (CAG). Somehow, the attacker got the login details of a Swissport employee, a cargo services provider.

The account that got hacked didn't have multi factor authentication (MFA) enabled. The stolen Swissport credentials gave the attacker access to the British Airways applications. Then, they started to poke around.

The attacker found a way out of the confined remote access (Citrix) environment that should have restricted users to safe parts of the network. British Airways explained in their report to the ICO, Monetary Penalty Notice (sections 3.10, 3.11), they're not exactly sure how the attacker pulled this off. The official documents blacked out the hypothetical details.

Once the attacker bypassed the initial hurdles, they dug in deeper. Then they brought in tools to further explore the British Airways' network. It's like gathering the intel for the attack. They checked the network for loopholes and vulnerabilities, and sized up the security setup, setting the groundwork for the attack plan.

A stack of paper cutouts, one of which is a laptop on top of a cutout of information from the British Airways penalty notice

23-26 June 2018

Finding the keys to the castle

Consider this: While snooping around, the attacker found the login credentials of a privileged domain administrator account (ICO MNP, section 3.15).

These credentials were just sitting in a file: unencrypted, in plain text.

This is a critical security oversight. It's also a game changer in this story. A domain administrator account is one of the highest user levels. This account has control over the settings and configuration of the domain. It can add and remove users. It manages privileges and security settings. Also, it has access to all computers and servers in the domain.

Now the attacker held the keys to the castle, giving them free access to mess up the network resources.

On June 23, they tried to log in with the system administrator's credentials. Three attempts failed. But two days later, on June 25, the attacker managed to log in into three different servers. What happened there is insider knowledge (see blacked out section 3.18 of the ICO MNP). And on June 26, the attacker found the username and password of a database administrator. This adds a new twist to this story.

A hand holding a credit card, on top of a paper cutout of the script that executed the attack on British Airways

26 July 2018

Payment cards in plain sight

By now, the attacker is getting pretty comfortable. They logged into servers to check out what data they could use. The research was worth it: on July 26 they stumbled upon log files with payment card details. More good news for the attacker, because they were stored in plain text.

Roughly 108,000 payment cards used in redemption transactions were exposed. They were used for things like flight miles, rewards, and such.

Now figure this: these payment data weren't supposed to be stored at all. It turned out that this was a testing feature, and it was not supposed to be used when the systems went live.

British Airways reported that the payment card details were stored in plain text due to human error. As a consequence, payment card details had been logged since December 2015. The data were only being kept for 95 days.

Busy days for the attacker. The next discovery were files that contained the code for the British Airways' website.

14 August - 5 September 2018:

… and action!

Now here we are, at last, at the heart of the breach. The attack is about to go down and roughly 300,000 to 500,000 individuals are about to be affected.

On a side note, it can be really tough to precisely pin down what data is impacted and over what timeframe because of the complexity of the attack vector's dynamic ability, especially since often website owners have no real insight into what happens in the browser of a user. Also, it takes time for forensics to determine the nature of the attack and understand the breach.

What is about to happen now? Let's make an educated guess. The attacker is ready to inject malicious code into a file that is being used on British Airways' website. They are doing some testing and optimizing to make sure the script is working as intended.

The code should secretly copy the payment card data customers enter into the payment form on the British Airways' website or in the app. And remain undetected for as long as possible. Next, it should send the data to an endpoint they control. And so, in a sneaky and sophisticated move, the attacker is skimming the payment cards.

It was happening right under everybody's nose without any disruption of the payment process.

A description of the attack from the penalty notice (as follows): 3.25. Between 14 August 2018 and 25 August 2018, the Attacker [redacted] to redirect customer payment card data to a different website: 'BAways.com'. BAways.com was a site owned and controlled by the Attacker. It appears from BA's Second Representations that [redacted] had the effect of copying and redirecting payment card data to 'BAways.com' (which BA refers to as 'skimming'). [redacted] remained active on BA's website for a period of 15 days between 21 August 2018 and 5 September 2018. During this time, when customers entered payment card information into BA's website, a copy was sent to the Attacker, without interrupting the normal BA booking and payment procedure.

Description of the attack - the ICO Monetary Penalty Notice, section 3.15 clearly stating that the skimming took place between 21 August and 5 September

5-7 September 2018:

Neutralizing and informing

When British Airways is notified of the breach by third party, they acted swiftly. In just 90 minutes, they neutralized the malicious code. Then, 20 minutes later, they blocked access to the suspicious baways.com. They didn't stop there. They promptly reached out to the Information Commissioner's Office (ICO). Not only that, but they also contacted banks involved in the processing of the payments, and nearly half a million customers.

A screenshot of the email sent to notify British Airways customers of the leak

A few days later, they notified an additional 39,480 customers as mentioned in the ICO MNP (section 2.27) and beefed up their security. This included setting up multi-factor authentication (MFA) for all remote access accounts, which adds an extra security layer to protect login credentials.

The breach caught a lot of media attention because of its scale. The Guardian reported that about 380,000 payment cards had been compromised. Also, they reported no travel or passport details had been stolen. As more details emerged, British Airways kept up their communication. British Airways' boss even apologized during a BBC interview. He committed to making it right for everyone affected.

Video from 7Edition on YouTube.

A paper cutout of the British Airways Chief on top of a paper cutout of a news headline that reads 'BA slapped with £183m fine over customer data stolen by hacker'

Numbers Numbers

It took time to get a clear picture of the exact impact of the breach. How many individuals were impacted? What specific data was actually exposed? The Penalty Notice of the Information Commissioner's Office (ICO) of 16 October 2020, reports the cyberattack exposed personal data of about 429,612 individuals including:

  • full card details for 244,000 individuals
  • card and CVV for 77,000 individuals
  • card numbers only for 108,000 individuals
  • usernames and passwords of BA employee and administrator accounts
  • usernames and pins of up to 612 BA Executive Club accounts
The news headline that reads 'BA slapped with £183m fine over customer data stolen by hacker'

4 July 2019

A £183.39 million fine

A major news update occurred on July 4, 2019. The ICO decided to take serious action against British Airways. It announced a fine of about 1.5% of the airline's 2017 turnover, amounting to £183.39 million. It argued in detail about the failures to protect customer data and GDPR violations. GDPR stands for General Data Protection Regulation. This EU framework gives individuals more control over their personal data. It also tells organizations how to handle and safeguard customer data.

Now, GDPR fines collected from data breaches are not used to compensate the affected customers directly. Instead, they are primarily passed on to the EU authorities and the UK Government.

A news headline that reads 'BA settles class action lawsuit over 2018 data breach'

4 October 2019 - today

Litigation for compensation

So, about half a million customers felt left out in the cold and wanted compensation. On October 4, 2019, a group of 6000 impacted customers got the green light to sue British Airways collectively. As a matter of fact, British Airways faced a number of group litigation orders to get compensation throughout 2021 by various law firms. For instance, the law firm PGMBM represented over 16,000 victims and reached a confidential out-of-court settlement. Details of the settlement were not disclosed. In a previous communication, PGMBM estimated damages of up to £2000 per claimant. Another law Firm, Your Lawyer, also participated in the litigation: they referred to an expected average of £6000 per claimant.

Legal battles are complex and can be long-lasting. Also, they add to the financial and reputational harm of data breaches. And what is more, it looks like the financial impact from victims in class action suits might surpass the fines imposed by regulators.

British Airways is not alone in this experience. Why not put class action waivers (US version of the UK group litigation order) in the small print of the terms and conditions? This is what happened in the case of the Marriott data breach case, as well as a massive data breach in 2018. It argued that the class action waiver in their terms and conditions should prevent the class action group from moving forward. Speaking of a lengthy case: the case is ongoing.

A news headline that reads 'British Airways is fined £20m by Information Commissioners Office after personal details of 400,000 customers was accessed by hackers in 2018 data breach'

16 October 2020

The fine is reduced to £20 million

Following negotiations, the ICO reduced the penalty to £20 million. The negotiations assessed the impact of the breach, British Airways' cooperation and accountability, and the financial strain of the COVID-19 pandemic.

Don't Be The Story

The 2018 British Airways data breach was a real wake-up call. It shows how a single leaked credential opened up an internal network to various high-end attacks. Today, adoption of security tooling to prevent inbound attacks has never been as high. We're seeing an increase in adoption of security products focussed on supply chain attacks through registries like Node Package Manager (NPM). However browser side third party scripts are often still forgotten about or protected to the bare minimum required by compliance.

Could you be next?

Never say never. Attacks similar to the British Airways' attack happen regularly. Sites can easily be caught in the crossfire, for example 17,000 websites were compromised as a result of a single exploit. It is never good enough to trust a source and not verify its behavior over time. Knowing the critical need for cybersecurity is a good start.

Consider the basics:

  • Pick safe 3rd party sources. Some 3rd party scripts are developed and offered by companies or external consultants that lack the necessary technical expertise. It's important to acknowledge potential risks; some companies may lack adequate preparation to address cyberattacks.
  • Monitor the scripts over time using specialized tooling that reviews content, not just the source. A one-time security review is not sufficient for a delivery method that can be fully dynamic.
  • Remove services if you no longer need them and do not run scripts on pages unless they serve a purpose there. Example: on the payment portal you may not need to embed third party advertisements.

New security standard for online payments

Preventing attacks with compromised third-party scripts is tough. But even so, keeping customer data safe is a top priority. And talking about keeping credit card details safe? That's where the new Payment Card Industry Data Security Standard 4.0 (PCI DSS 40) comes in. This is a new set of rules created by the PCI Security Standards Council to keep debit and credit card transactions safe from data theft and fraud.

The PCI DSS 4.0 update requires organizations that take payments online, to maintain an inventory of all system components relevant to PCI DSS. This includes bespoke and custom software, as well as third-party scripts (section 6.4.1).

And there's more: forget about yearly checkups. Section 11.6.1 mandates obtaining a tamper monitoring system. Keeping payments safe involves constant reviews and updates of all the digital gear for online shopping. From now on, the PCI DSS 4.0 wants a digital security guard in charge 24/7.

C/side to the rescue

C/side has rolled out a new and very elegant tool. It monitors, optimizes and secures all third party scripts running on your website. This solution makes sure that you are protected at all times by putting itself between your users and the third party service. If a third party serves a different payload to a user, in c/side you'll know about it.

Our free tier offers a range of basic features allowing you to meet PCI DSS 4.0 (section 6.4.3) compliance, as it lets you monitor your scripts. Explore our upgraded tiers for advanced detection methods and more fine grained insights.

Read our full guide to PCI DSS 4.0 compliance here.