how-things-work
Matthew Gast
By Matthew Gast
Posted On September 20, 2018

The British Airways Breach: PCI is Not Enough

Data Breach | PCI | Application Security

 I’ve previously written about the Ticketmaster breach, which was the work of Magecart, a group that has been active since 2016. One of their latest victims was British Airways, which announced that they had been breached on September 7 (remember that date because it will be important later on).

Magecart’s techniques are sophisticated and worth understanding in detail, especially because they point out a major gap that occurs even with perfect PCI compliance. PCI is focused on servers, which made sense in the past. When an application is self-contained and monolithic, protect the application. Today, however, applications run both on servers and within the browser, and securing against browser attacks is hard.

 

So, on to the British Airways breach. I haven’t thought much about BA since my most striking flight with them on July 7, 2013. (How do I know that date? It was the day after Asiana flight 214 crashed at San Francisco, and my 7 am flight was canceled and replaced with the BA flight in the afternoon. On takeoff, I could see the carcass of the Asiana plane.)

 

 

But, back to data security. Magecart embedded just 22 lines of Javascript into the BA web page. Scripts running in the browser can do anything. For the BA breach, the script was programmed to collect payment information fields when a button was clicked (or a touch event ended, just to be sure to get anybody on a mobile device), and bundle that information up to the attacker’s services. To camouflage the breach, the attackers used the domain baways.com (registered with privacy protection, of course!), so any tools that reported third-party access would have a similar-ish looking domain and might sneak under the radar. They even bought an SSL certificate so that the browser wouldn’t throw errors for mixed content!

 

 

 

 

PCI has a long list of requirements for security, many of which made sense when applications were developed as standalone monolithic code. BA was fully compliant with requirements like “don’t store CVVs.” Attackers obtained payment details by compromising end users browsers - an environment that BA has no control over.

 

The attack was probably first noticed when the malicious script was first detected. The script in question, modernizr-2.6.2.min.js, had a timestamp of 2012. When it was “updated” to include the malicious code, it received a new timestamp from August 21 of this year. The rogue domain used by the attackers to collect information was registered on August 16. These all point to a sophisticated attack, where the attackers were able to modify a script on the BA web site, then registered a domain for the specific purpose of collecting data. Once the malicious script was detected, of course, the script received a new timestamp. Out of curiosity, I checked it while writing this post. The date? September 7, the day BA announced the breach (and presumably removed the malicious code):

 

 

 

 

What can you do about these attacks? Stay tuned for a future post!