Payment processing should be isolated from unnecessary code, says expert
UPDATE (26/10) British Airways has revealed a further 185,000 customers may have been impacted by a breach in April and June. Of the original 380,000 victims in September, only 244,000 had their card details stolen, the airline added.
Rogue JavaScript code implanted in the British Airways (BA) payment page has been blamed for a recent high-profile breach which has left the airline in turbulence.
BA admitted last week that the personal data and payment card information of 380,000 customers had been stolen from its site over a period of 15 days, from August 21 until September 5.
The airline said the breach, detected by an unnamed but pre-existing security provider, has already been resolved.
The breach, reported to data privacy watchdogs at the Information Commissioner's Office (ICO), has become the subject of an ongoing National Crime Agency-led police investigation. BA is citing this investigation in declining to comment on the cause of the hack.
Security firm RiskIQ has come up with evidence, however, that card-slurping code was pushed onto BA’s payments page through a backdoored version of the Modernizr JavaScript library.
This code uploaded malicious script to a shadow server controlled by the crooks, according to RiskIQ, which based its analysis on up-to-date web-crawler data.
Attacker code was loaded via BA’s baggage claim information page as part of a targeted attack that was carefully designed to blend in with the airline’s legitimate payment processing infrastructure.
Similar features in BA’s web and mobile apps were also exploited to target mobile as well as internet-based ticket purchases.
RiskIQ blames the heist on a hacking group called Magecart, previously blamed for the July Ticketmaster breach, which resulted in the exposure of 40,000 card details.
Magecart’s previous stock in trade has been to subvert third-party scripts to pwn hundreds of sites in one fell swoop. The BA hack was more targeted.
“Magecart operatives compromised the British Airways site directly and planned their attack around the site’s unique structure and functionality,” RiskIQ said.
Both hacks illustrate the perils of running third-party JavaScript on sensitive webpages – many firms run analytic and customer service tools on payment pages, sometimes even without <iframe> isolation on payment card fields.
Lessons
Professor Alan Woodward of Surrey University urged developers to stay away from the practice of running third-party JavaScript on sites.
Prof Woodward told The Daily Swig: “The PCI [Payment Card Industry] standard warns about a number of common attacks, including code injection, and directs that website operators need to follow best practice to avoid such risks. That would include ensuring payments processing is isolated from any unnecessary code.”
There is a lot in the PCI data security procedures about protecting card data in transmission (use TLS) and storage (encrypt it), but the standard doesn’t specifically address this type of attack. It only addresses the better-known code injection and cross site type attacks, according to Prof Woodward.
“One thing PCI does suggest is that regular security audits are done,” he said. “In a modern system most would consider best practice to be monitoring for file changes. That would have caught this attack.”
Leigh-Anne Galloway, cybersecurity resilience lead at Positive Technologies and expert in payment security, told The Daily Swig: “It should be within scope because it [the standard] deals with storing and transmission, but PCI DSS (data security standard) doesn't explicitly address this vulnerability.”
The Magecart credit-card skimming group remains highly active and a threat to all organizations offering online payment facilities.
Only this week the Feedify Javascript library was compromised with code bearing the hallmarks of Magecart.
The code was purged before reportedly returning hours later.
The India-based push notification tool developer is yet to respond to requests for comment on the incident.
