One of the biggest problems here is that there is no “chain of custody” from Github source to uploaded NPM module; otherwise one of the developers using the malicious package could have audited the source code before including it in their own code. ‘npm publish’ would ideally insist on reproducible builds, enforce this by minifying or compiling packages itself, and finally encourage the community to always audit the code associated with a module. Of course, people are lazy, NPM has no incentive to incur that server and engineering overhead, and someone could sneak in code anyways with a minor version update... There’s no clear solution here, and I think the only thing keeping up this house of cards is that there are much easier ways for black hats to make money.
> Our penetration testers would see it in their HTTP request monitoring tools! > What hours do they work? My code doesn’t send anything between 7am and 7pm.
Which Time Zone? Hah!
(Not that this one nit pick takes away from the general very well made point of the article, I just love how TimeZone problems infect everything)
I'm more of a back-end dev who doesn't know all the ins and outs of the actual software used - can someone explain to me why this is an npm problem, and not an excessive dependencies problem?
I thought npm was simply a package manager - I don't see anything in the article that is specific to npm, except he happens to say that word.
The best part is when you get caught, you can just play dumb and say your npm credentials were compromised (assuming precautions were taken in not using a collection domain tied to you).
Couldn't one circumvent CSP by sending the data to a legitimate analytics service that everyone uses like Google Analytics?
So it seems developers are in fact responsible for dependencies that they use... Who would've thought...
What if the author snuck his code into frontend modules, and also snuck his code into backend modules?
If CSP is enabled, the frontend checks to see if the backend code has opened up the particular port or route on the backend.
The back-end code could sniff through require.cache to see if he could hook into the existing server instance ( same port ), or open a new port ( depending on CSP ).
I suppose the CSP equivalent on the backend is some sort of firewall. I also suppose servers have better monitoring of requests. Still, this method would circumvent CSP!!!
Also, hooking into the existing server instance would throw red flags if the instance was ever console.logged. You might also do an audit of your ports and see a suspicious one opened in that method. And a firewall likely would block other ports. But, still, it's feasible even with a CSP, until discovered.
Well-written, educational, incites action. Thank you.
I'm sometimes frustrated by uMatrix blocking every requests to third party website and forcing me to accept each of them when needed. But when I see exploits like this I'm happy that I haven't uninstalled it :D. You still have to be vigilant when whitelisting requests in the uMatrix panel though.
If this prompts you to action, and you need a quick and efficient way to build a CSP policy for the various services you use: https://www.npmjs.com/package/csp-by-api
Amazon has no CSP at all, nor does eBay.
Seems particularly prescient given item?id=16087024
This is a problem for the PHP composer ecosystem as well. I took a look at how many vendor packages our core has and its about 20...
A perfect example of this is the Hot Pockets deal.
Some guy made a cookie session middleware called node-yummy, which eventually became a dependency of Express. Express has a bajillion downloads, so yummy up and brokered a deal by which on every install they tweeted a like for Hot Pockets. So, Hot Pockets really started soaring, with no one having any idea what they were tweeting by installing and updating Express, until someone ruined all the fun by posting it on Medium, and getting picked up by HN 
IMO the really not acceptable part is that the open souce projects are not being pulled from Github. When something claims to be open source, we should have a gaurantee from NPM that we can see the source. The current setup implies the opposite  https://github.com/defunctzombie/node-yummy/issues/7  https://medium.com/friendship-dot-js/i-peeked-into-my-node-m...
Reminds me of Writing Worms for Fun and Profit by lcamtuf:
I recently had a problem with a package that doesn't have its npm releases tagged in git. It surprised me how hard it was to figure out which git revisions corresponded to specific npm releases. I had tracked down the npm version of the package that introduced the bug I was trying to fix, but without getting in and doing some real diffing, I couldn't figure out which commit introduced the bug.
At the time, I'd never added anything to npm, but since then, I have. It dawns on me that npm versions aren't tied to git revisions at all!
There is this trade-off between usability and security. For example being able to load data from other domains, now with origin policy we have do fetch the data server side. One nice thing about web apps is that they do not require a server to work. But due to xxs injections we cant have nice things.
while this post is about the more general attack vector, its worth pointing out that if you use a modern credit card tool like Stripe Elements it is impossible to steal credit card numbers as they are embedded in an iframe and your page just gets a token that is meaningless to anyone else
Easy Solution: on login and payment forms, go to a plain HTML page, use a standard form to submit without JS (or only JS you write). Forget client-side validation and/or write it yourself.
I've gotta post the obligatory Ken Thompson hacking the compiler story
Wow thats a rough read. Could something similar be done to django sites ?
Yeah, and Call Manager has a bug that lets incoming callers transfer themselves to intercom. Keep an eye on that Cisco phone on your doctor's desk while he discusses your HIV test results with you. I could be recording it.
What could be the npm package the author of this article is referring to?
The author mentions that Chrome Extensions are a bad distribution method. I think he is wrong. First, there are more users of Chrome Extensions than the users of npm, second, most of them don't care what those extensions send over the network. And I guess CSP doesn't apply to browser extensions.
So if you want to steal passwords, make some extension like "Mp3 Youtube Downloader" or "Ad Blocker" and get access to millions of happy users' browsers.
CSP looks like an ugly hack rather than a good solution. Why would you need to specify allowed sources for scripts if you control your HTML code? I don't understand why the author praises it. What a stupid time-wasting technology.