
Another Victim of the Magecart Assault Emerges: Newegg - GraemeL
https://www.riskiq.com/blog/labs/magecart-newegg/
======
chrissnell
How did the attackers get the JS onto the cart page? That's the interesting
part to me that the article leaves out. They managed to break into a PCI-
compliant website that presumably has significant defenses and auditing in
place.

~~~
vkjv
Unfortunately, PCI does not put very many restrictions on the parent website.
If credit card elements are in an iFrame, the parent site is excluded from
most requirements because the iFrame is "secure."

Of course, if you own the parent site you can replace the iFrame with anything
you want.

~~~
marak830
I'm still confused as to how they could insert code here.

Are we talking about a server intrustion where they modified the actual cart
code, or something between Newegg and the payment servers? (Sorry this isn't
my domain, I'm just curious)

~~~
lacker
It looks to me like a server intrusion where they modified static files kept
on a webserver (like apache or nginx). But it also seems like we don't have
enough evidence to know for sure. (Edit: or they might have been static files
kept on a CMS.)

------
alyandon
Lovely. I made a purchase recently with NewEgg but at least it was with a
previously stored credit card so hopefully I'm not impacted by this.

However, I am disappointed that NewEgg hasn't made any sort of official
announcement yet.

~~~
alyandon
Replying to myself. I use uMatrix and it just occurred to me that it would
have blocked any communication attempts to neweggstats.com from newegg.com....
so yay?

~~~
Bartweiss
I noticed this too; uMaxtrix should catch this entire class of attack. Privacy
Badger probably wouldn't - it watches for this sort of export, but its three-
strikes rule targets trackers and misses unique attacks. Killing JS outright
would do the trick also, but it looks like it would also have broken Newegg's
checkout page.

Looks like yet another point for "treat web browsing as adversarial". The
price of allowing pages to load freely isn't just high weight, trackers, and
ads - all too frequently it's actual security failures. I understand that
ad/tracker blocking is a problem for keeping sites profitable, but I can't
really imagine bending on that issue as long as monetization techniques and
threat vectors overlap so heavily.

------
Usu
This breach has reminded me of this pretty great article:
[https://hackernoon.com/im-harvesting-credit-card-numbers-
and...](https://hackernoon.com/im-harvesting-credit-card-numbers-and-
passwords-from-your-site-here-s-how-9a8cb347c5b5)

------
mwigdahl
They are just now (around 11:10 CDT 9/19) sending out notification emails to
customers. At the moment they don't even seem to know what accounts were
affected.

------
gregpilling
I am surprised that there is no automated alert to tell the webmaster that his
code has changed on his website. Especially on the payments page!

With 50,000,000 users a month, surely they have a whole team working on
checkout, all the time?

~~~
ryanlol
Do you have such automated alerts set up yourself? Do you know anyone with
such alerts set up?

~~~
reaperducer
I do.

I have a tiny $5 Onion Omega2 on an independent cellular connection that
checks file integrity on the production web servers every 15 minutes.

If the content of any of the files change, I get an e-mail.

If the alerts start coming in when I know I've just pushed a new version to
production, the mail has a link that I can click that will re-scan all of the
files and build new checksums.

If the alerts start coming in in the middle of the night, then I know
something is up.

Obviously, this only works in small environments like mine where I'm the only
one capable of updating the production servers. But it managed to catch a
backdoor left in by the previous developer, who for some reason stored and
updated his resume on the production server.

~~~
noir_lord
Ingenious, Have you considered a blog post on this approach?

It would be interesting to deploy a few of them in different places and check
that they all see the same as well maybe.

Also did you do this as a belts and braces thing or is the system you are
auditing particularly high security/risk in some way?

~~~
ams6110
You can just set up Tripwire to do this sort of thing. It's in most distro
package managers.

[https://github.com/Tripwire/tripwire-open-source/#open-
sourc...](https://github.com/Tripwire/tripwire-open-source/#open-source-
tripwire)

What that won't do is save you from malicious code inserted into 3rd party
content (script libraries, etc.) that you load from a CDN. If you're worried
about that, you should make a copy of a verified version and serve it
yourself.

~~~
reaperducer
_You can just set up Tripwire to do this sort of thing_

I wanted something that was completely independent of the machine. Separate
box, separate network, separate architecture, etc...

 _What that won 't do is save you from malicious code inserted into 3rd party
content (script libraries, etc.) that you load from a CDN. If you're worried
about that, you should make a copy of a verified version and serve it
yourself._

I don't CDN on work projects. It's not worth the risk. If something goes
wrong, I'd rather it be my fault and something I can understand and fix,
whenever possible. Farming stuff out just leads to layers of things that can
break, be compromised, or simply go wrong.

Again, it works at my scale (about 15 sites). It won't work for everyone.

------
anontechworker
For a website with so many visitors and transactions, I’m surprised this API
call never threw enough errors for them to see in logging. I will admit that
JS logging can be messy because of all the different environments but after
some time I would have hoped this would have been caught.

------
raverbashing
So how come is Comodo selling certificates to domain squatters? This seems to
be one sore point here.

~~~
ams6110
They (the attackers) owned the domain. What more is Comodo supposed to do?
LetsEncrypt would have done the same thing.

------
crunchlibrarian
I had a conversation two days ago with the CTO of a very large company you've
definitely heard of who said "we don't need to worry about our website
security, we have a firewall and SSL"

I think these types of attacks are vastly underreported, if anything.

------
adreamingsoul
Wow, I also made a purchase within that time window. Except, I used PayPal
during Checkout.

------
BeetleB
Damn. I made a purchase in that time period. I rarely buy anything from them,
but it had to happen in that interval!

I paid with Paypal. I assume I'm not affected?

~~~
adventured
Given the way the code works, I don't see how you could be affected if your
transaction went through PayPal (ie you didn't enter any payment information,
such as a credit card).

~~~
BeetleB
I did eventually pay with Paypal. However, I do know that at some point in the
last few months, I attempted to make a transaction on some web site and had
issues. It was either:

1\. I tried to pay with Paypal and failed. Paid with CC instead.

2\. I tried to pay with my CC and failed. Paid with Paypal instead.

I don't remember for which site this happened, but the paranoid part of me is
wondering if it may have been Newegg and item 2 above.

------
zxin
This all could have been prevented if they had a Content Security Policy.

~~~
eat_veggies
Presumably, if the attacker has write access to the source files, they also
have the power to change the CSP headers.

