Wow! Every once in a while an exploit methodology comes along and makes me think “why didn’t I think of that?” This is one of those…:
While attempting to hack PayPal with me during the summer of 2020, Justin Gardner (@Rhynorater) shared an interesting bit of Node.js source code found on GitHub.
The code was meant for internal PayPal use, and, in its package.json file, appeared to contain a mix of public and private dependencies — public packages from npm, as well as non-public package names, most likely hosted internally by PayPal. These names did not exist on the public npm registry at the time.
With the logic dictating which package would be sourced from where being unclear here, a few questions arose:
What happens if malicious code is uploaded to npm under these names? Is it possible that some of PayPal’s internal projects will start defaulting to the new public packages instead of the private ones?
Will developers, or even automated systems, start running the code inside the libraries?
If this works, can we get a bug bounty out of it?
Would this attack work against other companies too?
Without further ado, I started working on a plan to answer these questions.
