3 ms·

This is interesting as a lot of initial speculation for this attack focused on the large amount of 3rd party JS being loaded into the BA payment pages as a like

This is interesting as a lot of initial speculation for this attack focused on the large amount of 3rd party JS being loaded into the BA payment pages as a likely source of compromise. Instead this looks like a fairly well executed "traditional" attack on BAs CMS/Web server infrastructure. It's a good example of why even front-end infrastructure components need good protection...

ID1452319 8y ago
Indeed. Also, don't store JavaScript files within your CMS.
- jandrese 8y ago
  But if someone adds a <script> element to some template in your CMS and it doesn't get filtered out... It would be nice if browsers implemented an <endscript> tag and refuse to parse anything below it as a script. It would raise the bar on injection attacks for very little additional complexity. Slightly troublesome in that all of your buttons and similar would have to just call already defined functions (no inline code), but that's a reasonable tradeoff I think.
  - detaro 8y ago
    Content Security Policy can do things very close to that. You can't say "don't load anything after this", but you can whitelist script sources and forbid inline code.
tomalpha 8y ago
The write-up is a little unclear, at least to me. I read it as being that it was a third-party JS attack. At least of a sort - e.g. a compromised third-party package downloaded and then used by BA? [0] [0] https://cdn.riskiq.com/wp-content/uploads/2018/09/Webp.net-resizeimage-22.png https://cdn.riskiq.com/wp-content/uploads/2018/09/Webp.net-r...
- raesene9 8y ago
  I took from the article that the attacker had modified an existing copy of the Modernizr script that BA were running by appending content at the end of it. The targeting of the attack and the fact that prior to that the file hadn't changed for 6 years make it unlikely that it was a downloaded copy that had been backdoored and then installed by BA.
  - tomalpha 8y ago
    Thanks, that makes more sense.
daddylonglegs 8y ago
Previous attacks by this Magecart group did go through third parties: https://www.riskiq.com/blog/labs/magecart-ticketmaster-breach/ https://www.riskiq.com/blog/labs/magecart-ticketmaster-breac... I think the underlying problems are the same either way. In all these attacks the customer loads a page with dozens of scripts from at least a dozen servers and he or she has to trust them all. Speaking as someone who frequently has to reload the checkout page five or more times while authorising successive waves of third party servers in Request Policy and NoScript - there is no way to tell. Any one could be the source of an attack or the destination for malicious exfiltration. Should I do a geoip lookup on every sever on a page when shopping on-line? Baways.com looks like a perfectly plausible server for yet another piece of cruft, or analytics, or some baroque chain of payment services providers. Since the customer has no way of telling we are depending on the suppliers noticing that the website they are serving has changed. Otherwise it's up to the banks to find the common thread in each new wave of fraudulent payments, oops. The current sorry state of security online can only be fixed by the suppliers. I think that doing things properly will necessarily involve more respect for customers and less adtech/ spyware so that payment processes are better separated from everything else on the web </rant>
jacquesm 8y ago
> It's a good example of why even front-end infrastructure components need good protection... I would make that 'especially' instead of 'even', front-end infrastructure is arguably the safest way that an attacker has to try to compromise a system simply because by definition the system has to be somewhat open otherwise it could not do its job.
- raesene9 8y ago
  I'd agree, "even" was more a reference to the fact that many companies don't seem to regard storage of front-end assets like JS files as being as important as more obvious targets like database servers.

ID1452319 8y ago

Indeed. Also, don't store JavaScript files within your CMS.

jandrese 8y ago
But if someone adds a <script> element to some template in your CMS and it doesn't get filtered out... It would be nice if browsers implemented an <endscript> tag and refuse to parse anything below it as a script. It would raise the bar on injection attacks for very little additional complexity. Slightly troublesome in that all of your buttons and similar would have to just call already defined functions (no inline code), but that's a reasonable tradeoff I think.
- detaro 8y ago
  Content Security Policy can do things very close to that. You can't say "don't load anything after this", but you can whitelist script sources and forbid inline code.

tomalpha 8y ago

The write-up is a little unclear, at least to me. I read it as being that it was a third-party JS attack. At least of a sort - e.g. a compromised third-party package downloaded and then used by BA? [0] [0] https://cdn.riskiq.com/wp-content/uploads/2018/09/Webp.net-resizeimage-22.png https://cdn.riskiq.com/wp-content/uploads/2018/09/Webp.net-r...

raesene9 8y ago
I took from the article that the attacker had modified an existing copy of the Modernizr script that BA were running by appending content at the end of it. The targeting of the attack and the fact that prior to that the file hadn't changed for 6 years make it unlikely that it was a downloaded copy that had been backdoored and then installed by BA.
- tomalpha 8y ago
  Thanks, that makes more sense.

daddylonglegs 8y ago

Previous attacks by this Magecart group did go through third parties: https://www.riskiq.com/blog/labs/magecart-ticketmaster-breach/ https://www.riskiq.com/blog/labs/magecart-ticketmaster-breac... I think the underlying problems are the same either way. In all these attacks the customer loads a page with dozens of scripts from at least a dozen servers and he or she has to trust them all. Speaking as someone who frequently has to reload the checkout page five or more times while authorising successive waves of third party servers in Request Policy and NoScript - there is no way to tell. Any one could be the source of an attack or the destination for malicious exfiltration. Should I do a geoip lookup on every sever on a page when shopping on-line? Baways.com looks like a perfectly plausible server for yet another piece of cruft, or analytics, or some baroque chain of payment services providers. Since the customer has no way of telling we are depending on the suppliers noticing that the website they are serving has changed. Otherwise it's up to the banks to find the common thread in each new wave of fraudulent payments, oops. The current sorry state of security online can only be fixed by the suppliers. I think that doing things properly will necessarily involve more respect for customers and less adtech/ spyware so that payment processes are better separated from everything else on the web </rant>

jacquesm 8y ago

> It's a good example of why even front-end infrastructure components need good protection... I would make that 'especially' instead of 'even', front-end infrastructure is arguably the safest way that an attacker has to try to compromise a system simply because by definition the system has to be somewhat open otherwise it could not do its job.

raesene9 8y ago
I'd agree, "even" was more a reference to the fact that many companies don't seem to regard storage of front-end assets like JS files as being as important as more obvious targets like database servers.