6 ms·

> At the time, BA said hackers had carried out a "sophisticated, malicious criminal attack" on its website. Compromising a single JS resource that was being ca

> At the time, BA said hackers had carried out a "sophisticated, malicious criminal attack" on its website. Compromising a single JS resource that was being carelessly loaded on a payment page doesn’t qualify as sophisticated in my mind. It might not be uncommon in the industry, but tools like SRI and CSP stop these attacks dead in their tracks. I believe we are about one huge attack[0] of this kind away from realising how dire the situation truly is. As a victim of the earlier Ticketmaster attack I’m curious as to if the ICO is investigating that too. 0: https://hugotunius.se/2018/11/29/how-to-hack-half-the-web.html https://hugotunius.se/2018/11/29/how-to-hack-half-the-web.ht...

planetjones 7y ago
Exactly it was a crude and unsophisticated attack. I am pleased the ICO looked at the facts, not the spin and recognised the negligence of BA.
- barking 7y ago
  It seems the ICO website, itself was infected in a similar way last year with a crypto miner. https://scotthelme.co.uk/protect-site-from-cryptojacking-csp-sri/ https://scotthelme.co.uk/protect-site-from-cryptojacking-csp...
  - robocat 7y ago
    But they most they can fine themselves is 4% of their turnover.
    - davegardner 7y ago
      I suspect your comment is at least partly a joke, however the actual maximum fine possible is 4% or €20 million, whichever is higher.
CuriousSkeptic 7y ago
How would SRI and CSP help in this case? Wasn’t the compromised script served from their own infrastructure? And if hackers had access to that, why wouldn’t they they be able to change the SRI and CSP too?
- K0nserv 7y ago
  In this specific case the attackers seems to have compromised a CMS which for some reason was used to serve javascript libraries. It’s likely that they did not compromise the origin itself, only the CMS. Thus using SRI on the origin would have prevented or at least drastically complicated the attack. As a general pattern CSP and SRI are very effective protection against CDN compromises and XSS. With CSP and SRI the stack surface is reduced significantly.
  - zemnmez 7y ago
    the URI: http://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2.min.js http://www.britishairways.com/cms/global/scripts/lib/moderni... doesn't look like its on a CDN
    - K0nserv 7y ago
      It looks like a CMS that is being repurposed as a CDN. I would bet the path https://www.britishairways.com/cms/ https://www.britishairways.com/cms/ resolves via a gateway to a different set of servers than the main BA site. So for all intents and purposes it’s a CDN
- throw0101a 7y ago
  Depending on one's paranoia level, you could have a monitoring script on independent (third-party?) infrastructure that fetches pages and goes through them checking resource hashes. If the SRI hash listed in the origin, or the actual hash of the resource, changes, you get an alert. If an update was not pushed, then you know something hinky is going on. Some folks regularly check the signature of their SSL certs, and monitor certificate transparency logs. It just depends on how vigilant one wants to be.
pjc50 7y ago
So: now what? This is an absolutely vast fine. There have to be companies around the world that are all of a sudden going to take the security of Javascript seriously, who already have a big web app that pulls in hundreds of scripts compiled from tens of thousands of NPM modules. Is security band-aiding going to be applied, or are we going to have to see a radical re-architecting that acknowledges that every dependency is a liability as well as a benefit?
- 1337biz 7y ago
  Unfortunately I expect just some insurances to pop up that cover data security fines. Unless the fees are getting really in-insurable, the cost of an insurance is probably just cheaper than actuary improving security.
  - gcthomas 7y ago
    It may well be that the insurance companies are less likely to get their minimum security demands for agreeing cover ignored than the internal managers looking to spend more money on security.
- 7373737373 7y ago
  It would be reasonable to expect an increased interest in security architectures. Unfortunately security has not been a main focus of businesses - research, development and actual use of secure systems is mostly limited to academic, financial, defense and intelligence circles. Current programming languages provide no effective means of applying the principle of least authority to third party dependencies. Examples: restricting I/O of an imported library, in many cases down to pure computation, as well as accounting for and limiting their resource use. People, take a look at (object) capability security: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security Systems implementing this let you handle permissions like other objects, transferring them by simply including them as a function parameter. There is no ambient authority, meaning a string of a file path is not sufficient to open a file. The function needs to have access to a capability object, which combines authority (the right to do something, say read a file) with designation (the path to a specific file). When you create a new process, it starts without any capabilities, in which case it is restricted to pure computation. Unlike current systems, this passing of permissions allows you to reason about what your code actually can do, it effectively limits its behavior, it creates reliable boundaries, because the program can't just construct permissions out of thin air.
philjohn 7y ago
Similar way that TicketMaster were attacked ... that wasn't fun.
zemnmez 7y ago
> but tools like SRI and CSP stop these attacks dead in their tracks. this isn't... usually true. in the case of this attack, the Javascript was appended directly to a 'known good' library resource[1]. Typically CSP whitelists based on origin, which would make CSP ineffectual in this case. Also, websites like BA have advertising, and it's nearly impossible to run CSP with ads unless you use the `strict-dynamic` directive, which whitelists any javascript loaded by your javascript recursively... including this javascript[2]. There are other, more uncommon modes for CSP which you might be referring to: 1. Nonce, which provides protection by ensuring each script has a server-calculated one-time-use token. This would not have any effect, as the script is part of one naturally loaded by the server. 2. Hash[2], which provides protection by checking the script's content against a predetermined hash. This possibly could be effective, but in practice rarely is. If the attackers could edit this script, there's absolutely no reason to believe either (1) this just updates the generated hash or (2) the attackers cant just update the hash. (this is essentially the same as SRI). Hash is potentially effective where taking advantage of a third-party CDN with known content that should not change, but by the look of the url: http://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2.min.js http://www.britishairways.com/cms/global/scripts/lib/moderni... the resource was not on a CDN. [1]: https://medium.com/asecuritysite-when-bob-met-alice/the-british-airways-hack-javascript-weakness-pin-pointed-through-time-lining-dd0c2dbc7b50 https://medium.com/asecuritysite-when-bob-met-alice/the-brit... [2]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
- K0nserv 7y ago
  From the reporting I've read, primarily by RiskIQ, in both the Ticketmaster and BA case it was not the origin servers that were compromised in which case SRI would have been effective in so far that it would have required the attackers to compromise the origin servers too at which point it's all game over anyway. So I would assert that SRI would have stopped both these attacks.
  - zemnmez 7y ago
    i cant find any hits for "origin" or "CDN" on the original RiskIQ article: https://www.riskiq.com/blog/labs/magecart-british-airways-breach/ https://www.riskiq.com/blog/labs/magecart-british-airways-br... the RiskIQ article identifies the location of the script as "the main website" additionally, I'm not sure how this would solve the problem. If BA went to all the effort of putting their frontend assets on a CDN, why wouldn't their HTML, with the hashes also be on the CDN? and if the hashes are not generated by the CDN, how does the server generate the hashes without being affected by changes on the CDN? regardless of outcome, if the process is automated, does a human being need to read a diff every time any file on any CDN changes? Can't an attacker then just wait until the hashes are automatically updated?
deleted 7y ago
[deleted]
Silhouette 7y ago
It might not be uncommon in the industry, but tools like SRI and CSP stop these attacks dead in their tracks. It depends on what you're using them for. If you're talking about static resources loaded from something like a CDN -- in other words, a situation where you also control the intended content to be downloaded -- then SRI is potentially useful. But how could that sort of system work if you rely on a payment service to supply the client-side scripting that runs behind the credit card form on your site and turns the user-provided card details into a token of some sort? For example, if you use a service like Stripe, you're almost certainly loading a script from their servers that they control to run the card details form on your site. Between PCI-DSS rules and the obvious need for Stripe to be able to deploy changes quickly in the event of discovering a vulnerability, you can neither self-host the equivalent script nor provide any useful checksum or similar that is guaranteed to remain correct. I suppose in theory Stripe could provide an API that you can access from your servers to fetch the current checksum for the current version of a resource like https://js.stripe.com/v3/ https://js.stripe.com/v3/, and then you could render your link to that script with the integrity attribute included when you serve your page with the card details form, and as long as no-one breaks anything with a cache or the like then that might work. I'm not quite sure what attack vector it would be guarding against though, since any scripts like this will surely already be served over HTTPS and therefore trigger warnings if anyone without Stripe's cert tries to serve them via some sort of MITM attack. So SRI and the like take care of some aspects of this problem, but given you might be relying on a lot more external services than just (presumably relatively careful) ones like Stripe, it doesn't solve the whole problem.

planetjones 7y ago

Exactly it was a crude and unsophisticated attack. I am pleased the ICO looked at the facts, not the spin and recognised the negligence of BA.

barking 7y ago
It seems the ICO website, itself was infected in a similar way last year with a crypto miner. https://scotthelme.co.uk/protect-site-from-cryptojacking-csp-sri/ https://scotthelme.co.uk/protect-site-from-cryptojacking-csp...
- robocat 7y ago
  But they most they can fine themselves is 4% of their turnover.
  - davegardner 7y ago
    I suspect your comment is at least partly a joke, however the actual maximum fine possible is 4% or €20 million, whichever is higher.

CuriousSkeptic 7y ago

How would SRI and CSP help in this case? Wasn’t the compromised script served from their own infrastructure? And if hackers had access to that, why wouldn’t they they be able to change the SRI and CSP too?

K0nserv 7y ago
In this specific case the attackers seems to have compromised a CMS which for some reason was used to serve javascript libraries. It’s likely that they did not compromise the origin itself, only the CMS. Thus using SRI on the origin would have prevented or at least drastically complicated the attack. As a general pattern CSP and SRI are very effective protection against CDN compromises and XSS. With CSP and SRI the stack surface is reduced significantly.
- zemnmez 7y ago
  the URI: http://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2.min.js http://www.britishairways.com/cms/global/scripts/lib/moderni... doesn't look like its on a CDN
  - K0nserv 7y ago
    It looks like a CMS that is being repurposed as a CDN. I would bet the path https://www.britishairways.com/cms/ https://www.britishairways.com/cms/ resolves via a gateway to a different set of servers than the main BA site. So for all intents and purposes it’s a CDN
throw0101a 7y ago
Depending on one's paranoia level, you could have a monitoring script on independent (third-party?) infrastructure that fetches pages and goes through them checking resource hashes. If the SRI hash listed in the origin, or the actual hash of the resource, changes, you get an alert. If an update was not pushed, then you know something hinky is going on. Some folks regularly check the signature of their SSL certs, and monitor certificate transparency logs. It just depends on how vigilant one wants to be.

pjc50 7y ago

So: now what? This is an absolutely vast fine. There have to be companies around the world that are all of a sudden going to take the security of Javascript seriously, who already have a big web app that pulls in hundreds of scripts compiled from tens of thousands of NPM modules. Is security band-aiding going to be applied, or are we going to have to see a radical re-architecting that acknowledges that every dependency is a liability as well as a benefit?

1337biz 7y ago
Unfortunately I expect just some insurances to pop up that cover data security fines. Unless the fees are getting really in-insurable, the cost of an insurance is probably just cheaper than actuary improving security.
- gcthomas 7y ago
  It may well be that the insurance companies are less likely to get their minimum security demands for agreeing cover ignored than the internal managers looking to spend more money on security.
7373737373 7y ago
It would be reasonable to expect an increased interest in security architectures. Unfortunately security has not been a main focus of businesses - research, development and actual use of secure systems is mostly limited to academic, financial, defense and intelligence circles. Current programming languages provide no effective means of applying the principle of least authority to third party dependencies. Examples: restricting I/O of an imported library, in many cases down to pure computation, as well as accounting for and limiting their resource use. People, take a look at (object) capability security: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security Systems implementing this let you handle permissions like other objects, transferring them by simply including them as a function parameter. There is no ambient authority, meaning a string of a file path is not sufficient to open a file. The function needs to have access to a capability object, which combines authority (the right to do something, say read a file) with designation (the path to a specific file). When you create a new process, it starts without any capabilities, in which case it is restricted to pure computation. Unlike current systems, this passing of permissions allows you to reason about what your code actually can do, it effectively limits its behavior, it creates reliable boundaries, because the program can't just construct permissions out of thin air.

philjohn 7y ago

Similar way that TicketMaster were attacked ... that wasn't fun.

zemnmez 7y ago

> but tools like SRI and CSP stop these attacks dead in their tracks. this isn't... usually true. in the case of this attack, the Javascript was appended directly to a 'known good' library resource[1]. Typically CSP whitelists based on origin, which would make CSP ineffectual in this case. Also, websites like BA have advertising, and it's nearly impossible to run CSP with ads unless you use the `strict-dynamic` directive, which whitelists any javascript loaded by your javascript recursively... including this javascript[2]. There are other, more uncommon modes for CSP which you might be referring to: 1. Nonce, which provides protection by ensuring each script has a server-calculated one-time-use token. This would not have any effect, as the script is part of one naturally loaded by the server. 2. Hash[2], which provides protection by checking the script's content against a predetermined hash. This possibly could be effective, but in practice rarely is. If the attackers could edit this script, there's absolutely no reason to believe either (1) this just updates the generated hash or (2) the attackers cant just update the hash. (this is essentially the same as SRI). Hash is potentially effective where taking advantage of a third-party CDN with known content that should not change, but by the look of the url: http://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2.min.js http://www.britishairways.com/cms/global/scripts/lib/moderni... the resource was not on a CDN. [1]: https://medium.com/asecuritysite-when-bob-met-alice/the-british-airways-hack-javascript-weakness-pin-pointed-through-time-lining-dd0c2dbc7b50 https://medium.com/asecuritysite-when-bob-met-alice/the-brit... [2]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

K0nserv 7y ago
From the reporting I've read, primarily by RiskIQ, in both the Ticketmaster and BA case it was not the origin servers that were compromised in which case SRI would have been effective in so far that it would have required the attackers to compromise the origin servers too at which point it's all game over anyway. So I would assert that SRI would have stopped both these attacks.
- zemnmez 7y ago
  i cant find any hits for "origin" or "CDN" on the original RiskIQ article: https://www.riskiq.com/blog/labs/magecart-british-airways-breach/ https://www.riskiq.com/blog/labs/magecart-british-airways-br... the RiskIQ article identifies the location of the script as "the main website" additionally, I'm not sure how this would solve the problem. If BA went to all the effort of putting their frontend assets on a CDN, why wouldn't their HTML, with the hashes also be on the CDN? and if the hashes are not generated by the CDN, how does the server generate the hashes without being affected by changes on the CDN? regardless of outcome, if the process is automated, does a human being need to read a diff every time any file on any CDN changes? Can't an attacker then just wait until the hashes are automatically updated?

deleted 7y ago

[deleted]

Silhouette 7y ago

It might not be uncommon in the industry, but tools like SRI and CSP stop these attacks dead in their tracks. It depends on what you're using them for. If you're talking about static resources loaded from something like a CDN -- in other words, a situation where you also control the intended content to be downloaded -- then SRI is potentially useful. But how could that sort of system work if you rely on a payment service to supply the client-side scripting that runs behind the credit card form on your site and turns the user-provided card details into a token of some sort? For example, if you use a service like Stripe, you're almost certainly loading a script from their servers that they control to run the card details form on your site. Between PCI-DSS rules and the obvious need for Stripe to be able to deploy changes quickly in the event of discovering a vulnerability, you can neither self-host the equivalent script nor provide any useful checksum or similar that is guaranteed to remain correct. I suppose in theory Stripe could provide an API that you can access from your servers to fetch the current checksum for the current version of a resource like https://js.stripe.com/v3/ https://js.stripe.com/v3/, and then you could render your link to that script with the integrity attribute included when you serve your page with the card details form, and as long as no-one breaks anything with a cache or the like then that might work. I'm not quite sure what attack vector it would be guarding against though, since any scripts like this will surely already be served over HTTPS and therefore trigger warnings if anyone without Stripe's cert tries to serve them via some sort of MITM attack. So SRI and the like take care of some aspects of this problem, but given you might be relying on a lot more external services than just (presumably relatively careful) ones like Stripe, it doesn't solve the whole problem.