5 ms·

For those who are wondering what happened, British Airway’s website had malicious JavaScript included in some files they were using. Compromised third party lib

by jrpt 7y ago

For those who are wondering what happened, British Airway’s website had malicious JavaScript included in some files they were using. Compromised third party libraries (in this case, the Modernizr library) was the attack vector. The malware would take sensitive data off the webpage and send it back to the hackers surreptitiously. Most sites still would have no idea if this were to happen to them today. That’s why I’ve developed Enchanted Security (https://enchantedsecurity.com/ https://enchantedsecurity.com/) - a virtual content security policy that tracks the network requests and even blocks malicious ones. It’s like a firewall but running on your users’ browsers. This would’ve prevented what happened to British Airways. Get in touch if you’re interested in learning more.

leejo 7y ago
Here's a breakdown of the attack: https://www.riskiq.com/blog/labs/magecart-british-airways-breach/ https://www.riskiq.com/blog/labs/magecart-british-airways-br...
- Anthony-G 7y ago
  Thanks. That was really interesting. I concluded from the article that as a noScript/uBlock user, I wouldn’t have been protected from this attack. In general, I’ve noticed that for many ecommerce sites, I have to enable some third-party script and refresh the page a number of times. Not only do you have to guess which third-party script is the one providing the functionality to complete the transaction but it’s an iterative process where the loaded third-party scripts have a further dependency on yet another third-party. Even as a technically aware user, I don’t have time to go examining whois records and TLS certificates to attempt to determine if baways.com (or baplc.com or bacdn) are genuine. In any case, I doubt either of these extensions would protect use from “trusted” JavaScript from making a POST request to a third-party site. (BTW, I’m not arguing against the use of these browser extension as they do a great job of protecting against other threats). I’m glad the ICO fined BA a non-trivial amount because users/customers shouldn’t have to be constantly on the alert, exercising a high degree of vigilance – and staying up-to-date with ever-changing and increasingly complex stacks of web technology.
donaltroddyn 7y ago
Interesting approach, but doesn't using your product add another attack vector? Surely Enchanted's CDN will be a rich target for attackers. Full disclosure: I'm in private beta with a product that periodically loads production sites and compares all executed JS to the last-known-good profile (usually from CI prior to deployment), and raises warnings if anything changes. We don't run in actual users' browsers, so we won't see malicious code as early as Enchanted, but you don't have to trust us.
- jrpt 7y ago
  For your first question, there's an optional hash you can add that locks the code to its known hash. Also, you can self-host everything if you like. The type of product it sounds like you're running is a scanner and scanners have a couple problems. First, there's cloaking: if the malware can detect that it's a scanner (usually pretty easily) then the malware doesn't activate. Second, the malware comes from trusted code that you already think is trusted, and that's a problem if you overlook something because it's trusted. By contrast, Enchanted Security would see it since it runs on every users' browser all the time.
  - donaltroddyn 7y ago
    To be honest, if you can get clients to reliably use SRI, that's probably better protection than either of our products. Yeah, our product could be classed a scanner, but there's no (little) risk of cloaking, as the network request or JS loaded to work out whether we're a real user is enough by itself to raise the alarm. To pull it off, the attacker would have to compromise the host of a trusted resource, determine that we were a scanner from our network request alone, and serve to us the original resource. There's a few ways to help ensure that our network requests aren't easily recognised, which is part of our "secret sauce". Our approach does protect against the case where an attacker gets access to the client company's server and makes changes to the resources served, which can allow them to work around / selectively serve embedded snippets. The second problem you mention isn't an issue, as we don't trust hosts, only the hash of resources (the same idea as SRI).
    - 7y ago
buro9 7y ago
3 things I don't understand about your product (but I like the idea in general of helping people get over the initial cliff of enabling CSP): 1. How does including a bit of JavaScript apply a CSP and block things if the CSP is not sent via HTTP headers? Are you installing a service worker and proxying every request through that so that you can apply the blocking or something? (I have not looked into this area for a while) 2. How is adding another 3rd party resource not expanding the attack surface rather than reducing it? 3. How do you know what is good/bad and should be allowed/denied? On #3 I run a few hundred forums that have user generated content and whitelist a small number of 3rd party embeds such as YouTube, Google Maps, Strava, etc. I want those to keep working but don't wish anything not in my whitelist to work. But if I expanded the list in future to allowed embedding Twitch... how would your system know that this is a "good" action and to allow it?
- jrpt 7y ago
  You're correct that it's not using CSP headers (which is difficult in practice to use), which is why I call it a virtual content security policy. Yes, it's another resource that expands your attack surface but when you have sites running tens of scripts already, I think one more is a small attack surface delta, and there's ways to minimize that risk too. For knowing what to allow/deny yes there's blacklists but also various more intelligent things as well. That's one of the problems with CSP headers is that they're too black and white today. With Enchanted Security, for example, you can configure it to say things like "allow Google Analytics but only for my tracking id UA-123456789-1" (this is because hackers have used Google Analytics as a data exfiltration mechanism where they sent data back to their hacker-controlled GA account)
gradschool 7y ago
There's a typo on your page. Where it says "this require reworking" should be "this requires reworking".
mardoz 7y ago
I think this needs some clarification. From my reading of the issue the Modernizr library and its NPM entry were never compromised, instead the version hosted by BA on their website was overwritten by the hackers with one that exfiltrated the sensitive data from the payments pages. Not only is the version of Modernizr used on the BA website extremely old (2.6.2 was released in 2012) but for hackers to be able to modify hosted scripts demonstrates an extreme lack of care; I wouldn't be entirely surprised if they just hadn't updated the CMS hosting the script. Some people have been saying that anyone could be caught by this but I do think that the lack of process to allow this sort of thing to happen warrants this sort of fine.

by jrpt 7y ago

leejo 7y ago

Here's a breakdown of the attack: https://www.riskiq.com/blog/labs/magecart-british-airways-breach/ https://www.riskiq.com/blog/labs/magecart-british-airways-br...

Anthony-G 7y ago
Thanks. That was really interesting. I concluded from the article that as a noScript/uBlock user, I wouldn’t have been protected from this attack. In general, I’ve noticed that for many ecommerce sites, I have to enable some third-party script and refresh the page a number of times. Not only do you have to guess which third-party script is the one providing the functionality to complete the transaction but it’s an iterative process where the loaded third-party scripts have a further dependency on yet another third-party. Even as a technically aware user, I don’t have time to go examining whois records and TLS certificates to attempt to determine if baways.com (or baplc.com or bacdn) are genuine. In any case, I doubt either of these extensions would protect use from “trusted” JavaScript from making a POST request to a third-party site. (BTW, I’m not arguing against the use of these browser extension as they do a great job of protecting against other threats). I’m glad the ICO fined BA a non-trivial amount because users/customers shouldn’t have to be constantly on the alert, exercising a high degree of vigilance – and staying up-to-date with ever-changing and increasingly complex stacks of web technology.

donaltroddyn 7y ago

Interesting approach, but doesn't using your product add another attack vector? Surely Enchanted's CDN will be a rich target for attackers. Full disclosure: I'm in private beta with a product that periodically loads production sites and compares all executed JS to the last-known-good profile (usually from CI prior to deployment), and raises warnings if anything changes. We don't run in actual users' browsers, so we won't see malicious code as early as Enchanted, but you don't have to trust us.

jrpt 7y ago
For your first question, there's an optional hash you can add that locks the code to its known hash. Also, you can self-host everything if you like. The type of product it sounds like you're running is a scanner and scanners have a couple problems. First, there's cloaking: if the malware can detect that it's a scanner (usually pretty easily) then the malware doesn't activate. Second, the malware comes from trusted code that you already think is trusted, and that's a problem if you overlook something because it's trusted. By contrast, Enchanted Security would see it since it runs on every users' browser all the time.
- donaltroddyn 7y ago
  To be honest, if you can get clients to reliably use SRI, that's probably better protection than either of our products. Yeah, our product could be classed a scanner, but there's no (little) risk of cloaking, as the network request or JS loaded to work out whether we're a real user is enough by itself to raise the alarm. To pull it off, the attacker would have to compromise the host of a trusted resource, determine that we were a scanner from our network request alone, and serve to us the original resource. There's a few ways to help ensure that our network requests aren't easily recognised, which is part of our "secret sauce". Our approach does protect against the case where an attacker gets access to the client company's server and makes changes to the resources served, which can allow them to work around / selectively serve embedded snippets. The second problem you mention isn't an issue, as we don't trust hosts, only the hash of resources (the same idea as SRI).
  - 7y ago

buro9 7y ago

3 things I don't understand about your product (but I like the idea in general of helping people get over the initial cliff of enabling CSP): 1. How does including a bit of JavaScript apply a CSP and block things if the CSP is not sent via HTTP headers? Are you installing a service worker and proxying every request through that so that you can apply the blocking or something? (I have not looked into this area for a while) 2. How is adding another 3rd party resource not expanding the attack surface rather than reducing it? 3. How do you know what is good/bad and should be allowed/denied? On #3 I run a few hundred forums that have user generated content and whitelist a small number of 3rd party embeds such as YouTube, Google Maps, Strava, etc. I want those to keep working but don't wish anything not in my whitelist to work. But if I expanded the list in future to allowed embedding Twitch... how would your system know that this is a "good" action and to allow it?

jrpt 7y ago
You're correct that it's not using CSP headers (which is difficult in practice to use), which is why I call it a virtual content security policy. Yes, it's another resource that expands your attack surface but when you have sites running tens of scripts already, I think one more is a small attack surface delta, and there's ways to minimize that risk too. For knowing what to allow/deny yes there's blacklists but also various more intelligent things as well. That's one of the problems with CSP headers is that they're too black and white today. With Enchanted Security, for example, you can configure it to say things like "allow Google Analytics but only for my tracking id UA-123456789-1" (this is because hackers have used Google Analytics as a data exfiltration mechanism where they sent data back to their hacker-controlled GA account)

gradschool 7y ago

There's a typo on your page. Where it says "this require reworking" should be "this requires reworking".

mardoz 7y ago

I think this needs some clarification. From my reading of the issue the Modernizr library and its NPM entry were never compromised, instead the version hosted by BA on their website was overwritten by the hackers with one that exfiltrated the sensitive data from the payments pages. Not only is the version of Modernizr used on the BA website extremely old (2.6.2 was released in 2012) but for hackers to be able to modify hosted scripts demonstrates an extreme lack of care; I wouldn't be entirely surprised if they just hadn't updated the CMS hosting the script. Some people have been saying that anyone could be caught by this but I do think that the lack of process to allow this sort of thing to happen warrants this sort of fine.