6 ms·
Feedify is compromised with code mirroring Magecart
- eat_veggies 8y agoI posted a writeup a few months ago reverse engineering the same code, but hosted on a different website: https://blog.jse.li/posts/marveloptics-malware/ https://blog.jse.li/posts/marveloptics-malware/
- strictnein 8y agoVery nice work! Best breakdown of the magecart code I've seen by far. 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: jQuery.noConflict(); But the malicious JS posts to that URL as well.
- ashelmire 8y agoGood 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?
- brazzledazzle 8y agoLooking 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.
- eat_veggies 8y agoThey 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] Terrifying indeed. [0] https://www.riskiq.com/blog/labs/magecart-ticketmaster-breach/ https://www.riskiq.com/blog/labs/magecart-ticketmaster-breac...
- nneonneo 8y agoNot that I don’t believe you, but the linked page doesn’t seem to mention that fact.
- strictnein 8y agoIt's in one of the images: https://cdn.riskiq.com/wp-content/uploads/2018/07/rsz_image13-2.png https://cdn.riskiq.com/wp-content/uploads/2018/07/rsz_image1...
- mcintyre1994 8y agoIs there any way to find out who's using Feedify?
- arayh 8y agoA quick search on PublicWWW seems to reveal a few websites: https://publicwww.com/websites/feedify/ https://publicwww.com/websites/feedify/
- funnotatparties 8y agoyou use tech with an "ify" suffix, you get what you deserve
- saagarjha 8y agoIs presume this is only an issue if you were directly linking to Feedify’s site instead of serving your own copy?
- strictnein 8y agoYes, 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.
- strictnein 8y agoIf 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. CSP and SRI info: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- onli 8y agoIsn'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.
- Vendan 8y agoI 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.
- strictnein 8y agoYour 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.
- strictnein 8y agoBA had a file they hosted compromised through their CMS. 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.
- llao 8y agoIf 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/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.