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.
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 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.
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.
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.
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.](/attack_description.webp)
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
Step 1
The domain baways.com is set up
The attacker set up the domain baways.com as part of their strategy. It is common for the brand to use 'BA' in their marketing materials, therefore the domain name wouldn't immediately cause concern.
At the time, the domain was hosted in Romania and provided by a Lithuania hosting provider that rents out virtual servers cheaply, starting from 2 euros per month. If security monitoring was in place, this might have raised a couple of red flags.
On the other hand, the payment data was sent from the customer's computer.
Step 2
A third-party script enters the picture…
Here's where third-party scripts come into the picture. Essentially, these scripts are lines of code from outside sources used to make a website interactive. Think of chatbots, newsletter sign-up forms, social media features, marketing monitoring, captchas, advertising, and analytic tools…
One tiny weak spot in one of those third party scripts can cause a big security headache.
Monitoring all these external scripts and keeping users safe is a huge challenge. Website owners have only limited control over the content of those scripts because they are often hosted and managed elsewhere. If a vendor makes a mistake or is unaware of a security vulnerability in their code or infrastructure, that might leave doors and windows open for bad actors.
Adding more scripts also means more potential security gaps to monitor. What is okay today, might be a security incident tomorrow.
Some third party scripts are developed and offered by companies or external consultants that may lack the necessary technical expertise. That makes it harder for website owners to monitor the security of their applications over time, expanding the risk.
Also, marketing automation firms can get acquired by larger firms without their customer noticing. These acquisitions frequently lead to personnel changes. Consequently scripts may go unmonitored as the maintainers are no longer with the company, and the new owner may be unaware of their existence or the associated risk. In the most extreme cases this can lead to a full fledged domain takeover if they forget to renew the domain name used to host a script.
Step 3
Injecting malicious code
Typically, any website these days uses a lot of JavaScript, a programming language to build interactive websites, as well as a dozen or a couple of dozen external scripts. The British Airways website at the time of the breach loaded roughly 20 different scripts. It loaded 30, if you count the booking page.
When you visit a website, the website asks your browser to go to another source to obtain a piece of code. Your browser would execute this code. From the browsers point of view, a script is legitimate. For example, listening to the inputs on a form is a totally legitimate action for a script to perform. However, if the data is sent to an endpoint owned by a bad actor, it could have a negative impact: browsers are not set up to assess endpoint legitimacy.
In this case, the attacker injected harmful code in a JavaScript library called Modernizr. Modernizr helps websites run well in all kinds of browsers. It is widely used, also by the British Airways website. As a result, the British Airways web server served the Modernizr-version compromised by the attacker. The malicious script was specifically designed to hit British Airways' infrastructure only.
The fallout was huge. But it could have been worse. If a widely used third-party script is compromised and loaded from a third-party source, it could harm many different and interconnected systems. And just like that, websites all over the world can be serving malicious code. Such an attack is called a supply chain attack. Picture a digital domino effect, setting off trouble across the web globally.
Step 4
Stealing data
It takes skill and dedication to pull this off. The style of the attack carries the trademark of the hacker group, Magecart, that a.o. perfected the technique of sneaking bad bits of code into the digital mix. Their favorite trick: skimming credit cards from people buying online. The trick is to stay under the radar as long as possible to optimize the result.
The script that caused the loss of data and a look under the hood.
First, the code is waiting for the user to complete the payment confirmation on the check-out page. Once the button is clicked, the script grabs the payment and personal data entered in the form. Next, the stolen data is packed and sent to baways.com. This is done quietly in the background, so the customer won't notice. A wait of 500ms may be used to ensure the webpage keeps working as usual, so the customer doesn't realize something is wrong.
Can we blame the customer for being careless somehow? As a matter of fact, the malicious activity was designed to be invisible to users. The payment process appeared normal. There were no security warnings, pop-ups, or slowed performance. There were also no visible changes to the website. This made the attack particularly subtle.
It would have been extremely hard, if not impossible for customers to spot their data being stolen.
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 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.
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
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.
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.
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.