Feedify is compromised with code mirroring Magecart | Hacker News Reader

Feedify is compromised with code mirroring Magecart

threader.app

72 pointsseapunk21 comments

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.

CSP and SRI info:

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

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.

If you're using a third party cdn to serve js assets then you have no chance to assure security.

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?

BA 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.

You're right, with that perspective an hourly check to compare that what is online mirrors what is supposed to be online is a good additional defense.

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.

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]

Terrifying indeed.

[0] https://www.riskiq.com/blog/labs/magecart-ticketmaster-breac...

Not that I don’t believe you, but the linked page doesn’t seem to mention that fact.

It's in one of the images:

https://cdn.riskiq.com/wp-content/uploads/2018/07/rsz_image1...

I 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/

Very 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.

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?

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.

Is presume this is only an issue if you were directly linking to Feedify’s site instead of serving your own copy?

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.

Is there any way to find out who's using Feedify?

A quick search on PublicWWW seems to reveal a few websites: https://publicwww.com/websites/feedify/

Reply on news.ycombinator.com