
Feedify is compromised with code mirroring Magecart - seapunk
https://threader.app/thread/1039585850848362497
======
strictnein
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/HTTP/CSP)

[https://developer.mozilla.org/en-
US/docs/Web/Security/Subres...](https://developer.mozilla.org/en-
US/docs/Web/Security/Subresource_Integrity)

~~~
onli
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.

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

~~~
thaumasiotes
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.

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

~~~
eat_veggies
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...](https://www.riskiq.com/blog/labs/magecart-ticketmaster-breach/)

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

~~~
strictnein
It's in one of the images:

[https://cdn.riskiq.com/wp-
content/uploads/2018/07/rsz_image1...](https://cdn.riskiq.com/wp-
content/uploads/2018/07/rsz_image13-2.png)

------
eat_veggies
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/](https://blog.jse.li/posts/marveloptics-malware/)

~~~
strictnein
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.

------
llao
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...](https://developer.mozilla.org/en-
US/docs/Web/Security/Subresource_Integrity)) but best host the code yourself,
as that also protects your users' privacy.

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

~~~
strictnein
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.

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

~~~
arayh
A quick search on PublicWWW seems to reveal a few websites:
[https://publicwww.com/websites/feedify/](https://publicwww.com/websites/feedify/)

