British Airways, Another Victim of Ongoing Magecart Attacks
12.9.2018 securityweek Incindent

The data breach that British Airways said last week to have impacted 380,000 of its users was caused by an attack from Magecart, a threat group known for the use of web-based card skimmers.

The incident, the airline revealed on September 6, resulted in cybercriminals accessing the personal and financial details of customers who made bookings between August 21 and September 5, either via the company’s website or their mobile app.

On Friday, chief executive Alex Cruz told BBC the airline experienced “a very sophisticated, malicious, criminal attack” on their website. The breach resulted in customer names, postal addresses, email addresses and credit card information being stolen.

British Airways says the breach of customer data spanned a total of 15 days, but the attackers likely had access to the company’s systems before that, RiskIQ reveals. A paid certificate from Comodo used in this attack was issued on August 15, suggesting the miscreants “likely had access to the British Airways site before the reported start date of the attack on August 21st,” the security firm says.

RiskIQ, which has been tracking Magecart attacks since 2015, and which found a couple of months ago that the threat group also stole the information of Ticketmaster UK customers, said today they discovered how the data of British Airways’ customers was stolen.

The culprit was a modified version of the Modernizr JavaScript library that was loaded from the baggage claim information page of the British Airways website. Modified on August 21, the file contained 22 lines of JavaScript, and was long enough to steal the information of 380,000 users.

The script would extract user’s name and information from the payment form as soon as they hit the button to submit their payment on the compromised British Airways site. The data was sent to the attackers’ server.

“This attack is a simple but highly targeted approach compared to what we’ve seen in the past with the Magecart skimmer which grabbed forms indiscriminately. This particular skimmer is very much attuned to how British Airways’ payment page is set up, which tells us that the attackers carefully considered how to target this site instead of blindly injecting the regular Magecart skimmer,” RiskIQ says.

The attackers’ infrastructure was also specifically tailored for this attack, targeting scripts that would blend in with normal payment processing to stay under the radar. The attackers set up the domain baways.com, hosted on 89.47.162.248, an IP located in Romania but part of a VPS provider based in Lithuania.

What made it possible to target the users of British Airways’ mobile app as well, the security firm reveals, was the fact that the software loads a series of resources from the airline’s website, including the same compromised Modernizr JavaScript library. The hackers, however, also “put in the touchend callback in the skimmer to make it work for mobile visitors as well,” RiskIQ points out.

“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, and the fact they likely had access long before the attack even started is a stark reminder about the vulnerability of web-facing assets,” RiskIQ concludes.

Magecart is an active threat that has been continuously refining tactics and targets to maximize returns. As part of the Ticketmaster attack, they targeted third-party provider Inbenta, but switched to targeting a specific brand in the British Airways incident, specifically tailoring their attack to match the site’s functionality. The threat group is expected to continue to evolve, the security firm says.

[Update]

Comodo, which has already revoked the SSL certificate for baways.com, says it followed all industry standards and Baseline Requirements from the CA/Browser Forum when issuing the certificate in mid-August.

“Domain Validated (DV) certificates are issued once the requester can prove that they own the domain requesting the certificate,” a Comodo CA spokesperson told SecurityWeek in an emailed comment.

“While Certificate Authorities (CAs) can and must authenticate certificate requesters according to their validation level (EV, OV, or DV), they are not able to discern the intention of the certificate requester in advance of real-world use,” the spokesperson said.