The British Airways data breach is something that we can all learn from.

By Michael Brown

British Airways is the latest Company to suffer a cybersecurity and personal data breach, one of the first high profile breaches to occur this side of the GDPR coming into effect. The effect was the loss of 380,000 customers’ personal and financial data. BA’s CEO has promised that their customers will be “100% compensated.” Let’s see what that means in practice. One thing seems certain: this data breach will cost BA tens of millions (if not hundreds of millions) of pounds in direct and indirect loss. And that’s before any data protection fine is considered. With potential GDPR fines of £918 million (being 4% of their parent company IAG’s global turnover last year), half of BA’s 2017 profit could be wiped away in a single GDPR fine. Perhaps more worrying than the quantifiable loss itself, BA’s reputation is in play — millions of BA’s customers might decide to revisit their trust in the brand.

The news broke a week ago on 6 September with BA putting out a statement: “We are investigating, as a matter of urgency, the theft of customer data between 22:58 BST August 21 2018 until 21:45 BST September 5 2018 from our website, ba.com, and our mobile app. The stolen data included personal and financial details of customers making bookings and changes on ba.com and the airline’s app. The data did not include travel or passport details.” BA furthered in press interviews that name, address, email, card number, expiry date and the 3 digit pin on the back of the card (known as the CVV2 code) were stolen. Notice the subtle messaging BA employed. Instead of reporting a “data breach of BA servers”, they report that they are investigating the “theft of customer data” — good guys riding to the rescue. A seemingly slight but oh so important shift in focus.

In the premise that customers accessing the website during this two week window had their payment information (including, crucially, the CVV2 code) stolen, instincts lead us to suspect a compromise of BA’s web server farm rather than a full breach of their database. We know that Mastercard and Visa card processing rules (called PCI DSS — Payment Card Industry Data Security Standard) prohibit the storage of the CVV2 code beyond the initial time of entry for card verification only. They are never written to the database. Also, had the database been compromised, it would be very likely that all BA customers’ personal and financial data would likely have been compromised, not simply those of customers accessing the website or mobile app during a two week window.

So What Happened

Almost every modern transactional website makes use of javascript (a computer-based programing language at the heart of the world wide web and used to allow customers to interact with web-based services). BA utilises a number of javascripts, including one written under a free license from MIT called ‘Modernizr’. The compromise occurred in the modification of this file. Modernizr’s function is to allow web services (such as BA’s website) to understand more about users’ visits and the capabilities of their web browsers. It’s a good choice to hide malicious code in, because the script is typically deployed throughout a website’s pages, often including payment pages. In this case, the code was extended to the mobile app as well, which loaded it from the web servers.

Our research shows that on 18 August 2018 03:13:31 GMT, three days before the attack, BA’s web servers reported that it was serving a version of the Modernizr javascript from its own global website content management system that hadn’t changed since 18 December 2012, some 6 years without change. Javascript is served up by the web server you visit with your web browser, but the code itself is actually executed on your PC in the browser. Compromises occur when rogue javascript code is injected into your web browser and executed there. Kudos to BA for hosting the file itself rather than referring to the modernizr javascript from a third party website, common practice for many companies. Web pages can include code by reference from any URL on the Internet. Unfortunately, this can lead to attacks through the compromise of a company’s suppliers’ websites, so called “supply chain attacks”. We are regularly called into data breaches involving this type of attack. Indeed this happened in the Ticket Master breach detected in late June this year. However, this does not appear to have happened to BA as they self-hosted the file. A smart choice, but it also means BA can’t tie the breach to a supplier’s lapse of security of processing presently.

Only a few days later, BA’s web farm began to serve a modified version of the Modernizr javascript. It was time stamped with a last modified attribute of 21 August 2018 at 20:49:38 GMT. This time stamp is some 70 minutes early than the time reported by BA that the breach took effect — remember GMT and BST are one hour different this time of year. In any event, it is close. The new script appears to contain additional javascript that copied all customer data entered on the payment form on BA’s payment web page and sent it off to the following URL:

https://baways.com/gateway/app/dataprocessing/api

There are a few interesting observations worth noting at this point. First is that the attackers registered a new domain called baways.com. The selected domain was close enough to seem realistic upon first inspection. Baways.com was first registered on 16 August 2018 at 05:59:18 GMT. The registrar is namecheap.com, instead of BA’s usual global domain registrar ascio.com.

The domain baways.com resolves to IP address 89.47.162.248, which is pointing to a server at a Lithuanian hosting company. It offers virtual servers from two euros a month. 380,000 BA customers’ personal and financial data was transmitted there. Vilnius, Lithuania. I’m sure the warrants have gone out to this Lithuanian hosting company to reveal what they have and where it went from there. It is almost certain though that access to the Lithuanian servers was through the dark web. It is clearly a red flag that BA’s website was serving code requiring customers to communicate with a server in Lithuania. You see, it was the customer’s computer itself that transmitted the customer’s credit card and personal data to the attackers, all on instruction from BA’s web servers.

In order to prevent browsers’ reporting that this transmission was unencrypted, the attackers took the time to obtain an SSL website certificate. All this points the significant efforts going into perpetrating the attack. It seems highly likely they were in BA systems for some time before the 15th as the criminals planned the attack.

Although travel and passport information appears not to have been stolen, it likely could have been had the attackers simply wished to copy it off. Perhaps they didn’t want to expand the footprint of their code injection, thereby increasing the chances of being detected. The value of a credit card with CVV2 code is much greater than a passport number and expiry date?

Remaining Questions

How did BA’s web servers get compromised in the first place? Was it BA’s source code control that was compromised? Did compromised code get pushed to a secure web server farm? Or was access to the web farm itself compromised? Also, why did it take more than two weeks to detect the intrusion? A defensive technique using a program called tripwire may well have prevented or provided instantaneous detection of the breach. Tripwire records cryptographic hashes of every file on a server and reports when they are changed in anyway.

We simply won’t know until it is unearthed how the attackers gained a foothold in BA’s IT estate. Without understanding that, it isn’t possible to know for sure what else, if anything, that has been compromised. In writing this article, my mind wanders to the time that the attack was discovered, the hurried work of BA’s talented IT team, the crucial hours and sequence of events leading up to the remediation of the rogue Modernizr script at 9:45pm that night.

There will be many costly lessons learned by BA. I can only suggest that you take advantage of them by reviewing your own security stance with help from experienced experts who study these kinds of events for a living.

Published Articles

WannaCry update

WannaCry update

Do you WannaCry? By Michael Brown Overview What is WannaCry and how does it work? WannaCry (aka Wanna, WannaDecryptor and WannaCyptor) is ransomware, which is computer malware that extorts money from you by requiring you to pay a ransom to access your own data. This...

read more
Is Craig Wright Satoshi Nakamoto?

Is Craig Wright Satoshi Nakamoto?

Is Craig Wright Satoshi Nakamoto? By Michael Brown Today an Australian businessman named Craig Wright claimed on his personal website to publish cryptographic proof that he is Satoshi Nakamoto, the creator of Bitcoin and the blockchain algorithm that underpins it. I...

read more