British Airways: Suspect code that hacked fliers ‘found’ | Hacker News Reader

British Airways: Suspect code that hacked fliers ‘found’

bbc.co.uk

72 pointsTomAnthony61 comments

"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 completely exaggerating the difficulty of going HTTPS now we have LetsEncrypt.

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.

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.

That's a pretty old/ crappy Android phone though, either Froyo (or older) or a Gingerbread without patches.

There are other examples, the Nintendo Wii U, Internet Explorer on old enough XP (but really old XP can't grok modern TLS anyway and so you're screwed) but we're quickly talking about the minority of a minority.

I'm sure the perception was there though.

Wow, the Wii U is one? No wonder I had a bunch of Wii U users reporting my site stopped working when I started forcing HTTPS.

"Minority of a minority", maybe, but I still got around five tweets about it when it happened; more than most other changes I make.

Just to be clear, you're serious right? Because yes, the Wii U has a browser, it hasn't been updated (because the Wii U is basically abandoned at this point) and it never did trust DST Root CA X3, which is the root via which trust to Let's Encrypt was bootstrapped in older browsers. Don't happen to have links for any of those tweets do you? I'd be happy to have an actual example of a user who ran into this for real (nobody can fix it, but it's good to be reminded they exist)

Yes, I'm serious, but it looks like I misremembered, because it took me forever to dig up the post (it turned out not to be on Twitter).

https://www.reddit.com/r/pokemonshowdown/comments/7eix1o/pok...

The problem wasn't just because of the HTTPS cert, but also because it didn't support WebSocket on port 8000.

Crap DNS not supporting CAAA records can be an issue too

Good point. Worth spelling out that your DNS doesn't need to understand CAA records, it merely needs to be able to conform to the obvious requirement that if you ask it "Hey are there CAA records for this name?" it says "No" rather than crashing, silently ignoring the question or returning an error indication.

As usual in DNS this works fine in the Free implementation your OS vendor included, shame about all the expensive proprietary choices that get this wrong for every single new record type.

Speaking of crap DNS, OVH's webUI does not have DNS CAA support and their support claims they don't support it but their API is able to add the record and it works.

It's a pity it isn't just a TXT record.

> Learning some new stuff to get a free cert didn't seem worth it because they're not paying anyway

Even if they are paying, the ROI on spending even a single day on learning new stuff is a long, long time if you're just buying a DV cert.

Learn new thing make brain hurt though. Maybe same for crook.

Ehhh... very few (if any?) major orgs that take credit cards use Letsencrypt. Many, many malicious actors do. It's the go to cert for securing malicious sites

A security team reviewing that baways.com site would definitely make note of the fact that it was using letsencrypt.

Really not understanding the downvotes here. This isn't a judgement on letsencrypt. It's a reflection of reality.

Letsencrypt certs are widely used by malicious actors. Thus one not being used is noteworthy and why RiskIQ made note of it.

If someone who's downvoting me would like to show some examples of major websites from Fortune 100s or large international firms (like BA) using letsencrypt certs to collect payment info, then by all means, please do.

> 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 completely exaggerating the difficulty of going HTTPS now we have LetsEncrypt.

To a lay-person both those things ring very true, especially after Internet giants like Google have pushed https into everyone's throats.

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.

You are referring to an extended validation certificate I presume? A regular certificate you can get in a few minutes with a credit card and an email validation unless things have changed in the last two years.

The certificate in question (for baways.com) is this one:

https://crt.sh/?id=649459815

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.

This was a domain that didn't previously exist, right? Hence this falls just into the general category of phishing domains, rather than anything malicious happening to get a cert issued.

Yes, the crooks probably "legitimately" owned this name (given that their line of work is stealing credit card details it seems plausible they'd have used stolen cards to buy the domain, but maybe not)

It probably wouldn't have tripped as "phishing" unless the crooks were dumb enough to host false BA branding on it, rather than just an API to accept the stolen credentials.

Because "BA" is so short and non-specific I'm doubtful that tools like Facebook's Certificate Transparency based "phishing warning" would have been useful here. And if you were an over-worked BA employee given 500 CT "phishing" warnings a day, what would you do? Visit the site in Chrome maybe? Then you see it has a generic holding page, no sign of phishing, you file it as a false positive, move on? How are you supposed to know it's being used by crooks?

>According to RiskIQ, they also acquired a Secure Socket Layer (SSL) certificate - which suggests to web browsers, not always accurately, that a web page is safe to use

Looks like the article got updated

What 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.

Why "yet"?

I've worked with CMS tools that allow you to add plain HTML blocks, even stuff inside <script></script>. If their CMS allows this, and some marketing person had "password123" as their CMS password, and they allow access from the web (instead of intranet/VPN + 2FA requirements)...

CMSes get hacked every day now. It's the new entry level thing to probe for and hack into. Then the fact that most CMSes these days allow some form of creating code blocks in the content or injecting code into the templates, and it's not very hard to believe.

I see BA is using Google Tag Manager, which is another handy way to inject $RANDOM_JS into a site.

This 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.

Thanks, that makes more sense.

Previous attacks by this Magecart group did go through third parties:

https://www.riskiq.com/blog/labs/magecart-ticketmaster-breac...

I think the underlying problems are the same either way. In all these attacks the customer loads a page with dozens of scripts from at least a dozen servers and he or she has to trust them all.

Speaking as someone who frequently has to reload the checkout page five or more times while authorising successive waves of third party servers in Request Policy and NoScript - there is no way to tell. Any one could be the source of an attack or the destination for malicious exfiltration.

Should I do a geoip lookup on every sever on a page when shopping on-line? Baways.com looks like a perfectly plausible server for yet another piece of cruft, or analytics, or some baroque chain of payment services providers.

Since the customer has no way of telling we are depending on the suppliers noticing that the website they are serving has changed. Otherwise it's up to the banks to find the common thread in each new wave of fraudulent payments, oops.

The current sorry state of security online can only be fixed by the suppliers. I think that doing things properly will necessarily involve more respect for customers and less adtech/ spyware so that payment processes are better separated from everything else on the web </rant>

> 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.

Indeed. Also, don't store JavaScript files within your CMS.

But if someone adds a <script> element to some template in your CMS and it doesn't get filtered out...

It would be nice if browsers implemented an <endscript> tag and refuse to parse anything below it as a script. It would raise the bar on injection attacks for very little additional complexity. Slightly troublesome in that all of your buttons and similar would have to just call already defined functions (no inline code), but that's a reasonable tradeoff I think.

Content Security Policy can do things very close to that. You can't say "don't load anything after this", but you can whitelist script sources and forbid inline code.

How's that modified modernizerjs script ended up in there? I mean, it must have been included directly from the BA website? I also wonder how can BA be so sure about the dates this was stealing payment data, since this was apparently a frontend attack. Maybe they somehow know when that js script had been modified?

Both 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...

This is a good advert for using sub-resource integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Here’s the thing tho’, BA’s website exists solely to provide information on and sell their own services. Why is there third-party anything on it in the first place? Fix that and you’ll fix everything, well almost.

Disclaimer: worked on ba.com in the ‘90’s

I would guess third party payment gateway and tracking/analytics. It's doubtful that BA would undertake the task of creating bespoke systems for either of those

It's not a third party script. It's a copy of modernizr hosted on their own server. Someone has either hacked their CMS (Teamsite) or it's an insider.

I love it how big companies still use legacy CMS like Teamsite thinking it is too expensive to move to something modern.

If you have a large customer-facing website retail website, redoing the whole thing in something "modern" (which will only be "modern" for a year or so) is actually very expensive. Have you ever migrated a non-trivial website from one platform to another?

Uhh, yeah, it wasn’t such a bad choice 20 years ago. I had no idea they were still using it lol. Interwoven we called it back then.

How can you tell it is Teamsite?

How do you know they use TeamSite? A similar hack occurred against TicketMaster. I wonder if they use TeamSite as well. Maybe a 0day?

Marcus Greenwood (Founder of UB.IO) put out some good analysis of this at https://medium.com/the-automator/so-about-that-ba-hack-a82e5...

And there's more analysis at http://huagati.blogspot.com/2018/05/things-you-probably-dont...

And the fake BAWAYs server is still up - https://twitter.com/inventur_es/status/1039519364733497344

Ehh, Marcus's analysis is off on some of the details and his prediction of a 3rd party JS (which he strangely originally kept referring to as XSS, which makes me question his thoughts even more) ended up being wrong.

Maybe some sort of one use creditcard numbers should be used so that if hackers steal them they're worthless, and have a centralized service for providing those one use generated numbers...

Why not a quick scan twice a day if all static content looking for ip addresses and domains against a whitelist of allowed domains? This would have found the issue same day.

A simple connect-src CSP would have prevented this

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

Genuine question... Why the scare quotes around the word "found"? I'm assuming "hacked fliers" refers to the people who had their details stolen. So how exactly did they "find" the "suspect code"?

English is my first language, but I'm really struggling to grok this headline.

I think it’s because it’s not been confirmed by BA that this was the attack used.

From the BBC:

> Quotation marks should be single:

> in headlines and cross-heads (eg: UK ‘to leave EU’); in promo text and for quotes within quotes (eg: Tom Bone said: “They say, ‘The Labour Party is finished’ before every election”) and inside quote boxes (eg: They sprayed ‘go home’ on our front door – Sandra Harris).

> In headlines where the attribution is clear, do not include unnecessary quote marks (eg Britain won’t hold referendum, says PM rather than Britain "won’t hold referendum", says PM).

> They should be double:

> outside the categories listed above - on the ticker, in regular text, summaries and picture captions. Also, at first use of phrases such as “mad cow disease” or “road rage”. (But quotation marks will be single if the phrase comes inside a direct quotation (eg: The minister said: “The spread of ‘mad cow disease’ had ruined thousands of lives.”) Either way, no punctuation is required after the first reference.

https://www.bbc.co.uk/academy/en/articles/art201307021121335...

Thanks for the clarification. I've re-read this headline a dozen times and it finally makes sense.

By removing the phrase "that hacked fliers" you're left with "Suspect code 'found'". Which is the core of the statement. But that doesn't give enough context so the reference to the fliers was added.

I also think they wanted to lead with "British Airways" so a bit of contortion was necessary.

It's because they are reporting that somebody thinks they've found the dodgy code, rather than a statement of fact that the dodgy code has been found.

If I had had the developer console open in chrome while going through the booking, would I have seen in the network tab the posting to baways.com...

I think the answer is yes.

So I wonder why this issue was not reported earlier by some techie guy who's just booked a flight

Reply on news.ycombinator.com