better link: https://www.riskiq.com/blog/labs/magecart-british-airways-br...
Yes it is
And the attackers knew how to use SSL as opposed to some 3DS/VBV "partners" I've seen in the wild
Excepted for the botched GDPR "agreement" box
British Airways: Suspect code that hacked fliers ‘found’
21–30 of 64 posts
Re: British Airways: Suspect code that hacked fliers ‘found’
#22"According to RiskIQ, they even went so far as to acquire a Secure Socket Layer (SSL) certificate - which suggests to web browsers that a web page is safe to use." The BBC's technology reporting usually isn't that bad for a mainstream audience, but this is just egregious. On the one hand, perpetuating the myth that "anything I do on this page must be super safe because there's a green padlock", and on the other compl…
Getting a Comodo cert like as the attackers did is extremely non-trivial (at least for the first time). It took me upwards of 4 weeks plus a trip to an actuary and multiple calls with my CPA.
The certificate in question (for baways.com) is this one:
I'm going to generously assume your experience with 4 weeks and two professionals charging you fees was for an Extended Validation certificate, which as the name suggests involves a bunch more paperwork that the ordinary DV cert the article is talking about. But even for EV you've had a bunch of your time wasted by people either being incompetent or deliberately inflating the costs. For an existing organisation in a jurisdiction like the UK or most US states, with online company databases and functioning infrastructure you ought to be talking hours rather than days and there's no reason it should involve accountants.
Re: British Airways: Suspect code that hacked fliers ‘found’
#23Both this link, and the technical one posted by @iicc seem really light on how the infected modernizr got onto their CMS in the first place...
Re: British Airways: Suspect code that hacked fliers ‘found’
#24"According to RiskIQ, they even went so far as to acquire a Secure Socket Layer (SSL) certificate - which suggests to web browsers that a web page is safe to use." The BBC's technology reporting usually isn't that bad for a mainstream audience, but this is just egregious. On the one hand, perpetuating the myth that "anything I do on this page must be super safe because there's a green padlock", and on the other compl…
Although this comment in RisqIQ's report ( https://www.riskiq.com/blog/labs/magecart-british-airways-br... ) is even worse - it suggests that LetsEncrypt certs are less "legitimate" than paid ones: "Interestingly, they decided to go with a paid certificate from Comodo instead of a free LetsEncrypt certificate, likely to make it appear like a legitimate server"
After years of watching actual users, my first guesses as to why the crooks went with a "paid certificate from Comodo" would be:
1. They genuinely didn't know about Let's Encrypt
2. Learning some new stuff to get a free cert didn't seem worth it because they're not paying anyway (at corps this is often because they have a bulk deal, or there will just be a Purchase Order so it's not their personal credit card bill, for crooks it's probably someone else's money anyway)
3. Some minor technical inconvenience made doing the ACME proof of control validations tricky. For example their DNS provider doesn't implement a sane API for changing TXT records.
Re: British Airways: Suspect code that hacked fliers ‘found’
#25This is interesting as a lot of initial speculation for this attack focused on the large amount of 3rd party JS being loaded into the BA payment pages as a likely source of compromise. Instead this looks like a fairly well executed "traditional" attack on BAs CMS/Web server infrastructure. It's a good example of why even front-end infrastructure components need good protection...
The write-up is a little unclear, at least to me. I read it as being that it was a third-party JS attack. At least of a sort - e.g. a compromised third-party package downloaded and then used by BA? [0] [0] https://cdn.riskiq.com/wp-content/uploads/2018/09/Webp.net-r...
I took from the article that the attacker had modified an existing copy of the Modernizr script that BA were running by appending content at the end of it.
The targeting of the attack and the fact that prior to that the file hadn't changed for 6 years make it unlikely that it was a downloaded copy that had been backdoored and then installed by BA.
Re: British Airways: Suspect code that hacked fliers ‘found’
#26What I can't get my head around is how they managed to add their code to the .js file. Correct me if I'm wrong, but the file was hosted by BA within their CMS, yet the attackers were able to update this file to include their 22 lines of code. Does this mean the attackers had access to the CMS for BA.com or is there a step I am missing or has been deliberately omitted?
I'm guessing (and it is just that) that the attacker had indeed compromised some element(s) of BA's Web server infrastructure.
The reason this report doesn't mention it, is that their analysis focuses on publicly facing changes, so they can find the change to the JS file but not the mechanism that was used to get it onto the server.
For that we'd need some statement from BA or some other intel. source that has more information on that aspect.
Re: British Airways: Suspect code that hacked fliers ‘found’
#27This is interesting as a lot of initial speculation for this attack focused on the large amount of 3rd party JS being loaded into the BA payment pages as a likely source of compromise. Instead this looks like a fairly well executed "traditional" attack on BAs CMS/Web server infrastructure. It's a good example of why even front-end infrastructure components need good protection...
> It's a good example of why even front-end infrastructure components need good protection...
I would make that 'especially' instead of 'even', front-end infrastructure is arguably the safest way that an attacker has to try to compromise a system simply because by definition the system has to be somewhat open otherwise it could not do its job.
Re: British Airways: Suspect code that hacked fliers ‘found’
#28This is interesting as a lot of initial speculation for this attack focused on the large amount of 3rd party JS being loaded into the BA payment pages as a likely source of compromise. Instead this looks like a fairly well executed "traditional" attack on BAs CMS/Web server infrastructure. It's a good example of why even front-end infrastructure components need good protection...
> It's a good example of why even front-end infrastructure components need good protection... I would make that 'especially' instead of 'even', front-end infrastructure is arguably the safest way that an attacker has to try to compromise a system simply because by definition the system has to be somewhat open otherwise it could not do its job.
I'd agree, "even" was more a reference to the fact that many companies don't seem to regard storage of front-end assets like JS files as being as important as more obvious targets like database servers.
Re: British Airways: Suspect code that hacked fliers ‘found’
#29Earlier quoted context omitted.
The write-up is a little unclear, at least to me. I read it as being that it was a third-party JS attack. At least of a sort - e.g. a compromised third-party package downloaded and then used by BA? [0] [0] https://cdn.riskiq.com/wp-content/uploads/2018/09/Webp.net-r...
I took from the article that the attacker had modified an existing copy of the Modernizr script that BA were running by appending content at the end of it. The targeting of the attack and the fact that prior to that the file hadn't changed for 6 years make it unlikely that it was a downloaded copy that had been backdoored and then installed by BA.
Thanks, that makes more sense.
Re: British Airways: Suspect code that hacked fliers ‘found’
#30Earlier quoted context omitted.
Although this comment in RisqIQ's report ( https://www.riskiq.com/blog/labs/magecart-british-airways-br... ) is even worse - it suggests that LetsEncrypt certs are less "legitimate" than paid ones: "Interestingly, they decided to go with a paid certificate from Comodo instead of a free LetsEncrypt certificate, likely to make it appear like a legitimate server"
After years of watching actual users, my first guesses as to why the crooks went with a "paid certificate from Comodo" would be: 1. They genuinely didn't know about Let's Encrypt 2. Learning some new stuff to get a free cert didn't seem worth it because they're not paying anyway (at corps this is often because they have a bulk deal, or there will just be a Purchase Order so it's not their personal credit card bill, f…
As I remember, a lot of company didn't want to move to LE because their root certificate was not present in a lot of devices and those devices cannot or will not be patched to include it. Due to this, if you were, for example, on a old Android phone, pages with a LE cert would show as being insecure.