British Airways hack: Infosec experts finger third-party scripts on payment pages
Airline yet to reveal breach's cause
Security experts are debating the cause of the British Airways mega-breach, with external scripts on its payment systems emerging as a prime suspect in the hack.
The added code then uploaded data to a server hosted on baways.com, according to RiskIQ. “The infrastructure used in this attack was set up only with British Airways in mind and purposely targeted scripts that would blend in with normal payment processing to avoid detection,” the firm said in a blog post. “The domain was hosted on 18.104.22.168 which is located in Romania and is, in fact, part of a VPS provider named Time4VPS based in Lithuania. The actors also loaded the server with an SSL certificate.”
The suspect code was loaded from BA’s baggage claim information page, RiskIQ claimed.
The info-stealing script on the web app was replicated on the mobile app. Based on the techniques and tactics employed in the hack, the security firm concluded it had been pulled off by a hacking crew called Magecart, which has been active since 2015 and was previously blamed for the recent Ticketmaster breach. According to RiskIQ:
Magecart set up custom, targeted infrastructure to blend in with the British Airways website specifically and avoid detection for as long as possible. While we can never know how much reach the attackers had on the British Airways servers, the fact that they were able to modify a resource for the site tells us the access was substantial.
The credit-card skimming group has previously specialised in messing with popular third-party scripts to gain access to hundreds of sites at one go. The BA hack was more targeted but nonetheless bore the hallmarks of the group, according to RiskIQ.
Payment pages: Stick to the script
The issue provoked a debate among security experts about running external scripts on a payment page and whether this risked PCI non-compliance.
Brian Honan, an infosec consultant who founded and led Ireland's first CSIRT, said:
“If the third party scripts were responsible via iFrames then there are certain controls that should be in place from a PCI DSS perspective. I cannot tell whether those controls were in place or not as I do not have access to the BA site to do so. So in summary, yes you can use iFrames and third party scripts under PCI DSS but you need to secure them according to the guidelines from PCI DSS.”
Professor Alan Woodward of Surrey University pointed out that third-party scripts were central to the recent Ticketmaster breach. He urged developers to stay away from the practice.
“It is problematic. Or rather it might be. If any of the suppliers from those seven domains were compromised then their files could have been modified to include scripts that grab credit card data as it is input.”
“That’s why PCI says that compliance should be dependent upon using only that software necessary on the payment processing page,” Woodward added.
El Reg offered BA a chance to respond to RiskIQ’s analysis - which involved an analysis of contemporaneously collected scans of scripts on BA’s website over time. BA declined. “As this is a criminal investigation, we are unable to comment on speculation,” a spokesman said.
BA's payment page still loads content from seven external domains. Marcus Greenwood, chief exec of cloud-based automation firm UBIO, argued these various analytic, customer service and testing tools ought to be kept well away from payment pages.
BA last week admitted that personal and payment card info for 380,000 customers had been swiped from its site between 21 August and 5 September. The airline said on Friday that an unnamed security partner detected the breach, which has already been resolved.
Al-Bassam complained that prior to the changes it wasn't possible to buy tickets from BA without temporarily disabling ad-blockers or making a specific exception for the airline’s site.
Greenwood alleged that even after these changes and post-breach remediation, BA's site was insecure (as of Friday, 7 September).
El Reg put this to BA alongside a renewed request to comment on the cause of the breach. We're yet to hear back but will update this story if we hear more. ®