Data Disaster “What If’s?”: MageCart – What if British Airways Had Lokker?

The British Airways Incident

In 2019, British Airways was notified that they were facing a record £183 million fine from the UK Information Commissioner’s (ICO) based on their loss of 380,000 individuals’ credit and debit card details. The fine was reduced to £19.8 million in October 2020, not because BA wasn’t at fault, but because they were devastated by the COVID-19 pandemic.

However, the fine won’t be their biggest cost. They’re now facing group legal actions from law firms representing affected customers, with total claims reach £800 million ($1.09 billion) or more – an astoundingly expensive incident.

The responsibility for this loss of data lies squarely with BA. They have a complex, global environment with long-standing issues around access control and maintenance, and they were slow to patch critical utilities on their payment sites.

But it’s worth noting that they were the victims of a sophisticated operation that takes advantage of payment sites’ dependencies on third-party code and services, and against which defenses have been limited – a type of attack referred to as “MageCart.”

What Magecart did to BA‍

The term Magecart is popularly used both for the groups of cybercriminals who target online shopping cart systems to steal users’ payment card information using a specific type of attack and for the attack they use. The technical term for what they’re doing is “web skimming” or “formjacking,” and it involves inserting malicious code onto a website to steal a copy of the information a user enters into an online payment form.

It’s analogous to the use of physical card skimmers on gas pumps and ATMs. If done correctly, neither the user nor the site suspects it is happening. The Magecart groups have been very successful and continue to be active. BA was not the first company to fall victim to them.

The Magecart operators gained access to BA’s internal network by compromising an account used by an employee of a cargo handling company in Trinidad and Tobago, which was relatively easy to do since BA wasn’t requiring its suppliers to use multi-factor authentication.

Once they had that access, they moved laterally within BA’s network, eventually obtaining the ability to edit the payment page on BA’s public-facing website.

They then altered 22 lines of JavaScript code in a library called Modernizr so, when a user enters information on the form, a copy would be sent to their server (“baways.com”) as well as to BA’s databases.

Because BA’s mobile application mirrors its main website, this code change propagated to the mobile application too. From that point forward, anyone who used BA’s online payment forms had their data stolen.

The Aftermath‍

Once the breach came to light, British Airways reported it to their customers and fixed it. They also reported it to the UK ICO, because their failure to protect personal data was a potential GDPR violation – as expensive as we’ve seen, in terms of brand damage, fines, and upcoming settlement payouts.

But… could all of this have been prevented?

BA should have absolutely had better access control safeguards in place, but a dedicated group focused on a specific target may eventually find a way in. They also failed to update Modernizr, which had a known vulnerability.

Magecart is a sophisticated set of attackers, though, and if that specific vulnerability hadn’t been present, they might well have found another. However – if there were a way for BA to instantly detect the intruders’ change to their JavaScript code, and rapidly spot the fact that data was being redirected to a suspicious third-party server, this would have stopped the attack cold.

Privacy automation could have helped prevent BA’s data catastrophe

A solution like Lokker’s Privacy Automation Platform would have detected this particular privacy attack at two points. First, Lokker would have noticed Magecart’s changes to Modernizr’s Javascript and reported it. Second, it would have recognized that the code was intended to send data outside the company to a new destination. The new destination domain was newly created, and while it was too new to be on lists of bad domains, the mere fact that it was new would have caused Lokker to send BA an alert.

Depending on how Lokker is configured, it can either notify you that the change has occurred and let you decide what to do about it. Or it can spot a problem, cut off the data flow, and then alert you that the system has done so.

In the case of this attack, automatically cutting off that flow wouldn’t necessarily have even taken the payments website offline, as the Magecart crew was siphoning off a copy of the data while leaving the payment function intact.

There are other ways to spot this kind of hostile activity, but Lokker, since it’s an active privacy monitoring solution, watches for suspicious changes continuously.

This matters because a sophisticated attacker – and the group that hit British Airways was sophisticated – may only interfere with some transactions, or may be able to spot routine scans and avoid showing itself to them.

Lokker filters all transactions, all the time and can catch those attackers even if they’re clever.

Had it been available to them at the time, BA could have detected this attack early and been able to shut it down fast – maybe even before any personal data got out. This would have drastically reduced the fine, even if they still would have had to report the intrusion itself.

 

Author:
Kurt is an experienced marketing and sales executive with a passion for privacy and technology. From the background of a successful media and content agency entrepreneur, Kurt delivers fresh insights by making connections between tech, marketing, security, and personal freedom and responsibility.