Good writeup! Do you know whether the libraries in question were compromised, or were the compromised sites obtaining modified version of the libraries from some other source?
Looking at Twitter it sounds like they remove it and the attacker adds it back. Maybe a generous interpretation is they don’t know yet and have multiple servers backing cloudflare with only one compromised so it’s switching between caching the two versions. The alternative that they are breached and can’t contain it is terrifying if you’re their customer.
They are breached and can't do anything about it. Some websites hacked by the same group tried to remove it, and later, they added in "IF YOU WILL DELETE MY CODE ONE MORE TIME I WILL ENCRYPT ALL YOUR SITES! YOU VERY BAD ADMINS" [0]
Yes, if you're hosting that file, you'd be fine, although I might worry about the security of the rest of their architecture (I'm not sure what feedly does, tbh).
The one caveat to the above statement is that some places give you a file to host, but it's more or less a script that just document.writes another script tag which loads an external JS file. If that's the case, then you'd still be vulnerable.
If you're responsible for a website that collects payment details or other sensitive information you need to stop what you're doing right now and create a job that downloads all the JS libraries on your site and diffs it against a known "clean" copy. Run that job daily/hourly as your level of exposure demands and have it reviewed by someone who knows Javascript at a deep level.
Yes, that sucks and isn't fun, but this isn't going away and these guys are good at what they do.
Next step is versioning of JS libraries, which enables you to utilize SRI, and then look at implementing CSP. You can lock this down, but it'll likely require a lot of buy in from people across the enterprise. The diffing job requires none.
Isn't that the wrong approach? That's not something to do hourly, that's something you do once when deploying the site, and then again when you update the libraries. Which you host locally. If the code on your site happens to change every hour there is no way you have a chance to assure security.
I think they are saying, "diff your release branch against what's live", in the hopes of catching "someone hacked your server and changed your JS" early.
Your release branch wouldn't have any 3rd party JS, so diffing it vs the live stuff would catch a BA style attack, but not a TicketMaster style attack, which is more prevalent.
Not quite true; you can set a Content-Security-Policy header which whitelists scripts by their cryptographic hash. Assuming you know the exact contents of the script you want to run (which you should, if the only issue is that you're using a CDN), this should be fine. Just set the header yourself.
If you're letting third parties load arbitrary code on your site, that's harder to deal with. Then a compromise of them is likely to also be a compromise of you.
If you're using a third party CDN to serve Javascript assets on a page that requests users to enter sensitive information, such as credit card details, then you are DOING IT WRONG.
Seriously, do the devs not realize that "cloud" means "somebody else's computer" and using "cloud assets" on your payment pages means somebody else is deciding what Javascript to run on your payment pages?
If you embed third-party code, you expose your users to dangers like this. Please at least use
Subresource Integrity (https://developer.mozilla.org/en-US/docs/Web/Security/Subres...) but best host the code yourself, as that also protects your users' privacy.
22 comments
[ 3.4 ms ] story [ 56.3 ms ] threadhttps://blog.jse.li/posts/marveloptics-malware/
edit:
One of the clever things they do is have a different response for the GET and POST on what looks to be a JS file:
> hxxps://webfotce.me/js/form.js
Like with the new one( hxxps://info-stat.ws/js/slider.js ) if you do a GET you just get some innocuous looking JS:
But the malicious JS posts to that URL as well.Terrifying indeed.
[0] https://www.riskiq.com/blog/labs/magecart-ticketmaster-breac...
https://cdn.riskiq.com/wp-content/uploads/2018/07/rsz_image1...
The one caveat to the above statement is that some places give you a file to host, but it's more or less a script that just document.writes another script tag which loads an external JS file. If that's the case, then you'd still be vulnerable.
Yes, that sucks and isn't fun, but this isn't going away and these guys are good at what they do.
Next step is versioning of JS libraries, which enables you to utilize SRI, and then look at implementing CSP. You can lock this down, but it'll likely require a lot of buy in from people across the enterprise. The diffing job requires none.
CSP and SRI info:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
Many, many websites have 3rd party JS that updates at will.
Only doing the check when you do a deployment wouldn't catch either one.
If you're letting third parties load arbitrary code on your site, that's harder to deal with. Then a compromise of them is likely to also be a compromise of you.
Seriously, do the devs not realize that "cloud" means "somebody else's computer" and using "cloud assets" on your payment pages means somebody else is deciding what Javascript to run on your payment pages?