BA systems down globally

[Gareth79]

Andy Zarse said:

randlemarcus said:

Andy Zarse said:

I only used one, last week, and now it’s blocked by my bank and several online subscriptions have failed. Thanks BA, what a nightmare.

What I find most shocking is BA holding credit card and CCV numbers in non-encrypted form. I’d expect my local taxi firm to encrypt, let alone a huge international airline.

You can buy software cheaply enough, and yet penny pinching BA decide it’s too expensive. Does anyone know what might be the reason for this beyond saving money?

Not sure they are. The data came as you were typing stuff into the webpage, not after, so, while it's absolutely BAs fault, it wasn't necessarily their backend architecture at fault.

Ah okay, thanks for the clarification. So they’re also not encrypting sensitive data during transmission to/from BA.com either? Bonkers and just about as egregious.

They need to be hit with a massive fine, as said above. Alex Cruz’s metaphorical head should be on the end of a pole.

It would have been, but if it was a compromised 3rd party script then it's essentially something running in your browser that picks the data off the form as you type it in and sends it to the hacker's servers directly. Usually the script would have been doing something innocent like helping sharing to twitter/facebook, loading fonts, tracking user interaction, advertising etc. eg. On PH right now there are at least 15 external 3rd party scripts loaded.

Ideally I guess you'd switch off all but the most essential scripts on the purchase/payment pages, I think this hack will focus people's minds further on tightening down what goes on, there are ways of securing them (hash values). The other thing is regular scanning/monitoring of 3rd party scripts to detect malicious changes.

[anonymous-user]

anonymous said:

[redacted]

Makes sense. Why does a multinational need to run 3rd party scripts at all?

[Harpoon]

anonymous said:

[redacted]

Not my area of specialism but always keen to learn... what's the weakness of using a hash (or nonce) to validate the script hasn't changed?

[kev1974]

anonymous said:

[redacted]

I can understand why they would not rewrite their own version of jquery when jquery does exactly what they want, but I don't understand why they wouldn't just host and use a "frozen" copy of jquery on their own servers that they can control completely?

[anonymous-user]

anonymous said:

[redacted]

Thanks

[EddieSteadyGo]

anonymous said:

[redacted]

If we are getting into the detail of what went wrong, if BA had used the basic protection of placing the credit card part of their page into an iframe, hosted by a properly secure provider, none of the stolen credit card data would have able to be taken.

[anonymous-user]

EddieSteadyGo said:

If we are getting into the detail of what went wrong, if BA had used the basic protection of placing the credit card part of their page into an iframe, hosted by a properly secure provider, none of the stolen credit card data would have able to be taken.

Does a company the size of BA not constantly audit their IT security? Sounds like relatively basic stuff, especially on your customer facing payment page.

[EddieSteadyGo]

fblm said:

EddieSteadyGo said:

If we are getting into the detail of what went wrong, if BA had used the basic protection of placing the credit card part of their page into an iframe, hosted by a properly secure provider, none of the stolen credit card data would have able to be taken.

Does a company the size of BA not constantly audit their IT security? Sounds like relatively basic stuff, especially on your customer facing payment page.

On my comparatively tiny website, I pay for a third party monitor to perform a daily scan for any malicious scripts as a backstop measure. Of course, this is a last resort - I try and apply best practise to ensure I don't get into that situation in the first place.

But modern systems have become incredible complex. So if you place the credit card details bit of the page inside a separately hosted iframe (or similar technology), you isolate this part and so dramatically reduce the effect of any malicious infiltration. I'm sure the tech bods at BA will understand this far better than I do. Why they didn't implement it is another question...

[essayer]

As mentioned, a replaced JS dependency posted all form data to a third-party server

https://www.riskiq.com/blog/labs/magecart-british-...

tbh, what's more concerning is how someone's been able to amend files on the BA webservers, or inject rogue code into the dev/build process.. hope they have details on how they've been compromised!

[EddieSteadyGo]

essayer said:

As mentioned, a replaced JS dependency posted all form data to a third-party server

https://www.riskiq.com/blog/labs/magecart-british-...

Not *all* form data. It wouldn't be able to access the form data entered onto an iframe of an externally hosted element of the page.

From a customer's point of view, they would see very little difference if the page was structuring in this way. But it means the card data would be protected. Many companies including my own use this approach to mitigate the risk of the type of breach experienced by BA.

[essayer]

At the point hackers have the ability to modify files on your web server, iframes aren’t going to make much difference - they’ll modify your payment pages, or if the external iframe is under your control, they’ll go after that too.

Individual module loads like this and, even worse, external dependencies are the absolute bane of the modern web and the sooner people learn how to package things properly, the better.

[CzechItOut]

essayer said:

As mentioned, a replaced JS dependency posted all form data to a third-party server

https://www.riskiq.com/blog/labs/magecart-british-...

tbh, what's more concerning is how someone's been able to amend files on the BA webservers, or inject rogue code into the dev/build process.. hope they have details on how they've been compromised!

From that link it reads as if 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?

[CzechItOut]

anonymous said:

[redacted]

What makes you think they won't use a CMS? I presume they have a mechanism for business users to add and update content, images etc?

[CzechItOut]

anonymous said:

[redacted]

I was taught early on it is them and us.

[dmsims]

More info on the hack:

https://www.bbc.co.uk/news/technology-45481976

just to add

Why wasn't a content security policy in place ?

Edited by dmsims on Tuesday 11th September 14:06

[dmsims]

anonymous said:

[redacted]

Check domain against known list
Not on the list - gets blocked

[CzechItOut]

dmsims said:

Check domain against known list
Not on the list - gets blocked

Where are you doing the blocking? The script (with the malicious code attached) was running in the browser.

[dmsims]

anonymous said:

[redacted]

Yes I think we already knew that

I am going to test it on a submit button

Even if a CSP would not work why did they not know a file had changed ?

[dmsims]

But whilst on the BA site contact is made with the attack server

Doing a comparative hash check on a site is trivial and can be done in 160 lines

[PurpleTurtle]

Apologies for not having time to read the whole thread, this may already have been answered.

Who is running BA's website? Is it in-house BA IT in the UK or has it been outsurced and offshored?