Hackers that compromised Ticketmaster blamed for British Airways security breach
Magecart's malicious JavaScript so pervasive that commerce websites are being compromised every hour
Researchers at security consultancy RiskIQ claim that British Airways was breached by the same group, dubbed Magecart, that compromised Ticketmaster earlier this year.
And Magecart is now so prolific that RiskIQ claims to be getting hourly alerts of new websites compromised by Magecart's malicious JavaScript code. For British Airways, though, the group customised its JavaScript to evade detection.
RiskIQ claims that the attack on BA and the attack on Ticketmaster were similar and bare all the hallmarks of Magecart.
It claims that the Magecart uses a form of ‘digital skimming' to steal card and personal details when people are checking out online. "Magecart injects scripts designed to steal sensitive data that consumers enter into online payment forms on e-commerce websites directly or through compromised third-party suppliers used by these sites," claims its research published today.
It continues: "Our first step in linking Magecart to the attack on British Airways was simply going through our Magecart detection hits. Seeing instances of Magecart is so common for us that we get at least hourly alerts for websites getting compromised with their skimmer-code...
"In the case of the British Airways breach, we had no hits in our blacklist [of] incidents or suspects because the Magecart actors customised their skimmer in this case."
One of the problems of securing British Airways's commerce site is the number of different JavaScript processes that are spun-up by the organisation's bloated website.
"Just loading the main British Airways website spins up around 20 different scripts and loading the booking sub-page bumps that to 30. While 30 scripts might not sound like much, many of these are ‘minified' scripts spanning thousands of lines of script," continues the research.
RiskIQ researchers, examining the data it scrapes every day from billions of pages, claim they were able to identify the modified JavaScript that was probably the cause of the compromise.
"We saw this script was a modified version of the Modernizr JavaScript library, version 2.6.2 to be precise. The script was loaded from the baggage claim information page on the British Airways website. The noted change was at the bottom of the script, a technique we often see when attackers modify JavaScript files to not break functionality."
The malicious script was both simple and effective, according to RiskIQ, targeting the data only when a user clicks to submit a payment. The information from the payment form was extracted along with their name and sent to the attacker's server, claim the researchers.
"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 Airway's 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.
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."
RiskIQ claimed that the data was exfiltrated to a server in Romania, belonging to Time4VPS, a virtual private server company based in Lithuania. The attackers also used a paid certificate from Comodo, rather than use a free LetsEncrypt digital certificate for added authenticity.
"What is interesting to note from the certificate the Magecart actors used is that it was issued on 15 August, which indicates they likely had access to the British Airways site before the reported start date of the attack on 21 August - possibly long before. Without visibility into its internet-facing web assets, British Airways was not able to detect this compromise before it was too late."
The successful attacks against both British Airways and Ticketmaster ought to serve as a loud wake-up call to organisations about the security risks of running JavaScript and other processes on payment pages and other sensitive elements of any website, RiskIQ suggested.
"Companies, especially those that collect sensitive financial data, must realise that they should [not only] consider the security of their forms, but also the controls that influence what happens to payment information once a customer submits it."
Meanwhile, start-up bank Monzo - which accused Ticketmaster of ignoring its warnings of a potential compromise - has proactively cancelled the credit cards of customers that used any of its debit or credit cards on British Airways' website and issued new cards.
Magecart has been operating since at least 2016, according to Clearsky, attacking online retailers across the world using malicious JavaScript, although RiskIQ claims that it has been operating since 2015.
Back in 2016, Tel Aviv, Israel-based Clearsky detailed the group's methods: "Malicious JavaScript code acting as a form grabber or a simple ‘cloud based' keylogger was injected into breached shops. As buyers filled in their payment details, the data was captured and sent in real time to the attacker.
"This means that the information got stolen even if the seller worked according to PCI standards and did not keep credit card details in a database after purchase completion. This method is different than other ways of stealing payment details, such as infecting the buyer's computer, implanting malware in point of sale terminals, or dumping entire databases from breached online shops."
The group gain access to websites' check-out processes by exploiting vulnerabilities in web platforms, such as Magento Commerce and Powerfront CMS, or by compromising administrators' credentials - either by brute force attack or phishing.
This malicious JavaScript is hosted on domains that the group are constantly registering, and the attackers add a <script> tag to surreptitiously load malicious JavaScript from one of the many domains that they own.
"The malicious JavaScript code is served over HTTPS with a Valid SSL certificate. Using HTTPS is important for the attacker to keep its malicious activity undetected, because script loaded over HTTP would trigger a ‘mixed content' warning to the user," Clearsky warns.