British Airways hack: Infosec experts finger third-party scripts on payment pages • The Register
British Airways hack: Infosec experts finger third-party scripts on payment pages
Airline yet to reveal breach's cause
John Leyden Tue 11 Sep 2018 // 10:37 UTC
86 comment bubble on white
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.
Why infosec folk think it was the payment system
Although BA hasn't disclosed the root of the breach, the unusual precision it ascribed to the hack's duration suggests it may already know what happened.
"Between very specific times and dates (22:58 BST August 21 2018 and 21:45 BST September 5 2018) over a period of two weeks, it appears that the names, addresses, and all bank card details of customer data were stolen," said David Atkinson, founder of cybersecurity company Senseon. "No passport details or travel details were compromised.
"This indicates that it was a payments system that was compromised with an advanced cyber-attack that exploited a vulnerability in the payments system or its underlying servers. Because the time range is so specific it is likely that British Airways knows the full extent of the threat."
BA has said little related to the cause of the breach, much less who might have carried it out. Security vendor RiskIQ has advanced the theory that malicious code was planted on the airline’s payments page, via a modified version of the Modernizr JavaScript library. To carry out the attack in this way, hackers would have had to modify JavaScript files without hobbling its core functionality.
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 89.47.162.248 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.
BA suspicious script [source: RiskIQ blog post]
Suspicious script tag supposedly added by Magecart on BA website. Pic: RisqIQ
BA attack script [source: RiskIQ blog post]
That alleged BA attack script in detail. Pic: RisqIQ
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.
"Crucially there is also no 'iframe' isolation of the payment card fields," he said in a blog post exploring whether the airline could still be vulnerable to attack. "This is bad because it is trivial for any JavaScript file loaded to steal the card details and post to another third-party domain" he said, noting the site hosted third party scripts, including from external domains that the company itself owns, on the payment page.
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.
Security researcher Mustafa Al-Bassam said BA had switched around the third-party JavaScript code loaded onto its website in response to a privacy complaint he'd initiated. These changes – only applied in the month running up to the breach – related to running third-party ads and trackers (including LinkedIn, Twitter and DoubleClick) on a booking page.
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. ®
Airline yet to reveal breach's cause
John Leyden Tue 11 Sep 2018 // 10:37 UTC
86 comment bubble on white
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.
Why infosec folk think it was the payment system
Although BA hasn't disclosed the root of the breach, the unusual precision it ascribed to the hack's duration suggests it may already know what happened.
"Between very specific times and dates (22:58 BST August 21 2018 and 21:45 BST September 5 2018) over a period of two weeks, it appears that the names, addresses, and all bank card details of customer data were stolen," said David Atkinson, founder of cybersecurity company Senseon. "No passport details or travel details were compromised.
"This indicates that it was a payments system that was compromised with an advanced cyber-attack that exploited a vulnerability in the payments system or its underlying servers. Because the time range is so specific it is likely that British Airways knows the full extent of the threat."
BA has said little related to the cause of the breach, much less who might have carried it out. Security vendor RiskIQ has advanced the theory that malicious code was planted on the airline’s payments page, via a modified version of the Modernizr JavaScript library. To carry out the attack in this way, hackers would have had to modify JavaScript files without hobbling its core functionality.
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 89.47.162.248 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.
BA suspicious script [source: RiskIQ blog post]
Suspicious script tag supposedly added by Magecart on BA website. Pic: RisqIQ
BA attack script [source: RiskIQ blog post]
That alleged BA attack script in detail. Pic: RisqIQ
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.
"Crucially there is also no 'iframe' isolation of the payment card fields," he said in a blog post exploring whether the airline could still be vulnerable to attack. "This is bad because it is trivial for any JavaScript file loaded to steal the card details and post to another third-party domain" he said, noting the site hosted third party scripts, including from external domains that the company itself owns, on the payment page.
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.
Security researcher Mustafa Al-Bassam said BA had switched around the third-party JavaScript code loaded onto its website in response to a privacy complaint he'd initiated. These changes – only applied in the month running up to the breach – related to running third-party ads and trackers (including LinkedIn, Twitter and DoubleClick) on a booking page.
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. ®
