The site was extremely well designed and did not feel at all ‘spammy’ to use – indeed, on the surface it felt reassuringly professional, with a slick revolving banner of destinations. It just clearly wasn't British Airways.
First Published 14th September 2018
The world's favourite airline?!?
4 min read | Reflare Research Team
On September 6th 2018, British Airways announced that users who had interacted with their website between August 21st and September 5th may have had their credit card information stolen by attackers. An estimated 380,000 people were affected by the attack. A comprehensive analysis of the incident published by AttackIQ shows that a small snippet of JavaScript code was uploaded to British Airways servers by attackers. Instead of adding a new script file to the servers, the code was added to an existing, legitimate file. This made it somewhat harder to detect.
The added code waited for users to enter their payment information before sending it to an attacker-controlled server which, likely to further obfuscate the attack, used the domain name baways.com - a domain name sounding similar to but unaffiliated with British Airways.
Who are the attackers?
As we have covered in previous briefings, there is an important difference between the proof required to assist incident response and the proof required in a court of law. In this context, we are talking about the lower threshold for proof required for preventive actions.
The attack methods, the server infrastructure and the target used in against British Airways are very similar to those used in the attack against Ticketmaster. This implies that the attack was carried out by the same threat actor: A cybercriminal group commonly named Magecart. While other attackers could easily mimic the actual attack code, the acquisition of target servers in Eastern Europe combined with the silent infiltration of the target company and long-term strategic approach to attack-monetization point to this well-established and highly capable actor.
It is quite likely that other scripts operated by Magecart are currently active but undetected on payment websites of other companies. While large breaches like the ones hitting TicketMaster and British Airways are covered on the news, breaches of smaller online shops are likely to go unnoticed for much longer and stay unreported once they are discovered.
How can companies protect themselves?
In the previous attacks, the security of third-party tool providers - mostly for chatbots - was infiltrated to hit the more valuable main target. In this case, the attack hit a system operated by British Airways directly. Since we have already covered the risk tradeoffs to be considered for third-party services, let’s have a look at how alterations to code on a public-facing corporate website can be avoided.
It appears that the British Airways website was managed through a Content Management System (CMS). This is a somewhat common approach as it allows content on the site to be updated by non-technical staff.
However, it appears that the CMS allowed users to update script resources. Doing so is convenient but extremely dangerous. A single user with sloppy passwords or malicious intent could lead to an attack. Instead, CMS should limit user editing to contents only. All code resources - and this includes scripts - should only be editable by programmers.
When changes are made by programmers, they should be tracked using source code management systems and deployed to servers in a manner that can be tied to the developers making the changes and approving the deployment. Combined with regular monitoring of file changes, this can be a very effective tool to quickly detect attacks from external sources to insider threats. If, for example, a script file is changed but no deployment is recorded for the same time, something is seriously wrong.
While nothing can provide complete security, the pattern of relatively easy attacks leading to a few lines of script code being embedded, leading to the loss of tens of thousands of payment datasets means that even these basic measures would likely go a long way to reduce risk.