British Airways 2018: 22 lines of JavaScript and a £20 million fine

Between 22 June and 5 September 2018 attackers had access to British Airways' systems. For the last two weeks of that period, payments made on ba.com and in the BA mobile app passed through a modified script that copied the card details to a server the attackers controlled. The UK Information Commissioner's Office (ICO) found that the personal data of about 429,612 customers and staff was affected, including card numbers and CVVs for around 244,000 customers, and in October 2020 fined BA £20 million, down from a proposed £183.39 million.

Researchers at RiskIQ attributed the skimming to Magecart, the umbrella name for groups that inject card-stealing JavaScript into checkout pages. The BA case is worth studying because it has both halves of a web skimming attack: a network intrusion that gave write access to the site, and a very small change to the code that browsers ran.

Step 1: a supplier's login

According to the ICO, the attacker first got in using the credentials of an employee of a third-party supplier (Swissport, based in Trinidad and Tobago) to reach BA's Citrix remote access environment. That account was not protected by multi-factor authentication. The ICO's view was that MFA would have significantly raised the bar against exactly this kind of account takeover, and that the measures BA lacked were available at the time without excessive cost.

Step 2: breaking out and escalating

The Citrix environment was supposed to restrict what the supplier's user could do, but the attacker broke out of it into the wider network. There they found a privileged domain administrator username and password stored in plain text in a file on a server, and later the credentials of a system administrator. With those, they could browse the systems that built and served the website.

The ICO also found that a logging feature meant only for testing had been left switched on in production, so payment card details were written to a debug log in plain text. That widened what was exposed.

Step 3: 22 lines on the payment page

RiskIQ reviewed historical copies of every script on BA's pages for the attack window and found the change. The attackers had modified a copy of Modernizr, a common feature-detection library (version 2.6.2), served from BA's own site. They added 22 lines at the bottom of the file, so the library kept working and nothing on the page looked different.

The added code listened for the mouseup and touchend events on the payment form's submit button. When a customer pressed Pay, it read the form fields and the name of the person paying and sent them as JSON to baways.com, a domain registered to look like BA's. The server had a paid TLS certificate, so requests went over HTTPS and looked like normal traffic in the browser. Because the BA app loaded the same payment page, app users were caught too.

The customer's card went to BA's payment processor as normal. A second copy left at the same moment, and the purchase completed without error.

How it was found

BA didn't find it. On 5 September 2018 a third party told BA that data was being sent from its website to an external site. BA contained the attack that day and notified the ICO and customers on 6 September. By then the attacker had been inside for more than two months. The ICO listed the monitoring that should have caught it earlier: unusual activity inside the Citrix environment, access to files holding hard-coded credentials, use of privileged accounts, and unauthorised changes to website code on production systems.

Controls that break each step

Remote access and credentials

• Require MFA on every remote access route, especially for supplier accounts, and give suppliers only the systems they need.
• Harden remote desktop environments and test that users can't break out of them.
• Never store admin credentials in files. Use a vault, and scan servers and shares for secrets.
• Turn off test logging before go-live, and never log full card data.

The payment page

• Keep payment fields off your page: hosted payment pages or the processor's iframe fields mean your scripts never touch card data.
• A strict Content Security Policy with connect-src and form-action limited to your own and your processor's domains blocks exfiltration to a look-alike domain.
• Subresource Integrity hashes on scripts, and a build pipeline where production JavaScript can't be edited by hand on the server.
• PCI DSS v4.0 now requires an inventory and authorisation of every script on payment pages (6.4.3) and a mechanism to detect unauthorised changes to them (11.6.1).

Detection

• Monitor the live pages the way a browser sees them, comparing script hashes against the last release.
• Watch for newly registered domains that resemble your brand.
• Collect CSP violation reports. A browser trying to send data to an unknown host is a strong signal.

The lesson

The skimmer was small, but it was the last step of a long chain that began with a supplier login without MFA. Payment pages need protection at both ends: tight control over who can reach the servers, and browser-side controls that assume a script may one day be changed anyway.

Sources: Mayer Brown: BA ultimately fined £20m (ICO penalty notice summary); The Register: ICO fines BA £20m; Tech Monitor: RiskIQ on the BA hack; Computing: BA hit with £20m fine; Splunk: lessons from the ICO's BA penalty notice; BleepingComputer: BA fell victim to card scraping attack; PCI SSC: PCI DSS v4.0 document library.