Barbarians!
They don't even know proper Latin. The plural of "datum" is "data".
Netizens buying stuff from Newegg had their bank card details skimmed by hackers who, for a whole month, stashed the Magecart toolkit on the dot-com's payment pages. From August 16 to September 18, shoppers' sensitive card data was silently copied by the Magecart code during the site's checkout process, and sent to neweggstats …
This post has been deleted by its author
...Or, just be can't be bothered?
Compiling the candidate list is easy from the logs. Vetting the list is a one-off task. Using the list to look for exceptions and new good-guys is the point. If a unknown/new IP shows up, then who the hell is it, and what the hell is it doing?
It is well past time for serious web bizzies to stop having intimate relationship with whoever shows up.
"Time to limit outbound connections to known ip addresses?"
On the server side or the client side?
On the server side, it won't make any difference as the code is run client side.
On the client side, the task is certainly challenging. Assuming you already use ad/script blockers to significantly reduce the number of URL's visited, creating a whitelist might be possible for an individual with a relatively constant list of sites, but scaling across all residents in a home or a business to determine "good" from "bad" with minimal false positives in a timely manner? I've had enough experience with various web filtering solutions to know that their are gaps with all of the major players but I'm sure they will be willing to sell the world solutions and provide an improvement in what we are stuck with at present.
I expect the real solution has to be regulatory - when fines reach the point that businesses become more conscious of some of their practices, security will improve. Maybe not as fast as we would like, but making people do things better has always been hard. I watch with interest to see if GDPR gives us this.
Why not server side? The server is delivering these links to the client and it should not be delivering any old un-vetted crap even if that means the link has to be resolved in order to vet the underlying IP. Tedious and convoluted? Yup, but only because webpages have become such a chaotic Cluster. Time for more engineering and less code-slinging.
Due to how NPM works even a single clock widget can have thousands of dependencies. Using NPM and auditing all scripts you serve are mutually exclusive.
Somebody posted a blog post talking about how easy it is to steal credit card data from sites thanks to NPM a while ago:
https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5
I've never purchased anything from an outfit called 'Newegg' - and I don't remember ever specifically visiting a website with that name. However, I am familiar with the name, and I'm pretty sure that's in the context of NoScript - its list of scripts on a given page.
This leads to the question: Are there sites using services provided by (scripts from...) Newegg - or is what I'm remembering Neweggstats? i.e. are there potentially other sites out there that were also running the dodgy Neweggstats script?
are there potentially other sites out there that were also running the dodgy Neweggstats script?
If you read TFA, you'll see that the neweggstats domain was specifically created to exfiltrate data in this hack. When they hit BA they had a similarly misleading domain name (baways.com
). So this looks like a consistent MO for these crooks, and I'm sure that if they're not using it on another site right now, they're preparing to.
So, all you have to do is check every single site that you might input your credit card into and make sure that none of them are connecting to an unauthorised third party site, bearing in mind that many websites uses scripts on different domains to function, and that you probably won't be able to guess which are legit and which are bogus without at least checking the whois records for every single one.
"If you read TFA, you'll see that the neweggstats domain was specifically created to exfiltrate data in this hack. "
I did read TFA. And I've just read it again - while the phrasing says the dodgy domain was used for newegg, it doesn't say it in a way that firmly leads me to infer exclusivity. There's enough ambiguity there to make me question it based on my recollections.
That said, however, on my drive today I realised that what I was actually remembering was the name newrelic, not newegg.
So, all you have to do is check every single site that you might input your credit card into and make sure that none of them are connecting to an unauthorised third party site, bearing in mind that many websites uses scripts on different domains to function, and that you probably won't be able to guess which are legit and which are bogus without at least checking the whois records for every single one.
Can I assume from that helpful explanation that you didn't notice the mention of NoScript in my original post? I would imagine most people who use NoScript are perfectly well aware that "many websites uses scripts on different domains to function". That's a large factor in why we use it, not to mention why I'm able to vaguely remember seeing (albeit incorrectly in this case) a particular domain name in play on other sites - a result of looking at what scripts sites are trying to load.
It isn't 100% clear to me but it looks like they managed to edit the aspx page to include the magecart script. This is similar to how they amended a local copy of the modernizr script on the BA site.
The script could be blocked by Content Security Policy but if they have access to the server they may be able to change the CSP headers too.
Does anybody know how they got the code into the page?
@Spazturtle NPM dependencies are definitely a problem but from what I have seen that isn't what happened here or in the BA case. at least not directly.
I'll be honest, XSS is a little confusing for me, there are non-persistent and persistent XSS
This was a persistent XSS attack, so they would have had to store their code somewhere, DB?
To get their code on there, they are probably exploiting either some unpatched or 0day vuln or SQL injection, but I am just guessing here
This was a persistent XSS attack AFAIK, some banks do carry out ad-hoc security checks for unusual transactions, for example phoning the customer. There is no ability as of yet to enter a 2FA OTP into a POS terminal
I fail to see how a bank can mitigate the failing of a separate business in securing their website, especially one which allows for financial data to be inputted. A better solution would have been for the compromised business to have at least some inkling what is going on in their infrastructure, but that costs money for staff to implement and carry out such a task. Unfortunately these business love money too much and dont want to properly invest in security
I have my own website, and while its not the most complicated by any means, I know evey single bit of code thats on there, can these businesses say the same about their websites?
One possible solution would be to cronjob a script which searches their DB's and code for :// and report back what it finds, but for that to work, they have to at the very least know what their estate looks like
I've seen this kind of clusterfuck before at a company I worked for briefly, they had no 2FA on their registra account but had a DNS record pointing vpn.TLD.com to a IP address which was a GoDaddy shared hosting webserver in the USA which had someting like 2,000 websites when checking reverse IP, they didnt have any offices in that region. Think about it, no 2FA on registra account, VPN pointing to shared hosting websites, in a country where they didnt have any presence. When I asked about it, nobody knew what it was. This company was a joke and was run by jokers
"some banks do carry out ad-hoc security checks for unusual transactions, for example phoning the customer."
My bank blocks those sorts of transactions, then doesn't tell me. I know this coz it blocked a couple of my own transactions, then didn't tell me. I had to go into a nearby branch and ask WTF is going on.
I did a whois on (new egg stats.com) out of curiosity, its been registered through a 3rd party, "WhoisGuard Protected" based in that bastion of criminals, Panama
Is this a national service that Panama offers, protecting criminals?
I wonder what the words are to their national anthem
It seems part of the chorus goes like this:
"It is necessary to cover with a veil from the past"
>>The domain also had a digital certificate from Comodo to make it look nice and legit
We have brain washed users for years to look for the visual indicators to confirm a site's legitimacy. This has always been the wrong assertion for what is actually happening. All a certificate is doing is ensuring the data between the user's browser and the web-server is encrypted not that it is legitimate.
The debate around EV certificates looks like is heading for the same conclusion for the same reasons. The psychology of positive indicators vs the psychology of negative indicators is well worth a read.
That's not really relavant in this case, because the domain (new egg stats.com) was pointed to from within an embedded javascript and would not have been shown in the address bar, it might not have shown up in the Noscript blocked list either as a 3rd party script, showing the dodgy domain name, because the script is being served by the 1st party company website database, not a 3rd party, Noscript would very much likely have flagged it as a "Cross-site suspicious requests", whether or not an end-user would know its legitamacy or not is another question, it sounds like a domain owned by newegg, as opposed to some autogenerated domain name with random gibberish, but with hindsight we know it isn't.
I'm purely going by the information in this screenshot
@FlamingDeath
Most browsers would also warn with something like "this page contains insecure content". That should be a big red flag on a checkout page!
I remember when you had to show that you are a legitimate legal entity to get an SSL certificate. Those days are long gone, and now we have this crap. It seems that EV certificates were an attempt to make certificates attributable to a legal entity again.
Sureley a CSP would stop this code sliding into their websites?
HTTPS is just not enough
Scott Helme give great advice on this, and even set-up securityheaders.com to check it (along withother websec) and run a service to handle your CSP reports (report-uri.com) (assisted by Troy Hunt)
Quite fankly if your running any sort of secure site and it doesnt Get an A on SSLLabs and an A on Security Headers, your not doing it right
This article definietly needs this scene from Fight Club as it appears to be lacking a picture
The JS addiction of developers leads to such scenarios. Web users are now so used to dozens of different domains referenced by scripts on a page that they think nothing of it.
Tools like NoScript are great, unfortunately for many users, even if they have installed it, there's a tendency to click through warnings / just allow everything as fine grained control of site scripts is non trivial
I dislike Amazon as they dodge their UK taxes, but grudgingly use them for online purchases as fall back when all other options I can find are too often using potentially dubious third party scripts / iframes etc. - on Amazon I can purchase with just about everything turned off in terms of scripts.
After years of being called paranoid by friends & family members about profligate use of JS, I'm enjoying lots of "told you so" moments in recent weeks.