Security Expert Nabs Expired Domain for a Popular NPM Library's Email Address (theregister.com) 16
"Security consultant Lance Vick recently acquired the expired domain used by the maintainer of a widely used NPM package," reports the Register, "to remind the JavaScript community that the NPM Registry still hasn't implemented adequate security."
"I just noticed 'foreach' on NPM is controlled by a single maintainer," wrote Vick in a Twitter post on Monday. "I also noticed they let their domain expire, so I bought it before someone else did. I now control 'foreach' on npm, and the 36,826 projects that depend on it."
That's not quite the full story — he probably could have taken control but didn't. Vick acquired the lapsed domain that had been used by the maintainer to create an NPM account and is associated with the "foreach" package on NPM. But he said he didn't follow through with resetting the password on the email account tied to the "foreach" package, which is fetched nearly six million times a week. In an email to the Register, Vick explained... "I did not log into the account, as again, that crosses a line. I just sent a password reset email and bailed.
"Regardless of how much control I have over this particular package, which is unclear, NPM admits this particular expired domain problem is a known issue, citing this 2021 [research paper] which says, 'We also found 2,818 maintainer email addresses associated with expired domains, allowing an attacker to hijack 8,494 packages by taking over the NPM accounts.' In other words, anyone poking around is going to find accounts easy to take over in this way. I was not lucky or special." His point, which he has been trying for several years to communicate to those overseeing NPM — a part of GitHub since March 2020 — is that taking over the NPM account of a popular project to conduct a software supply chain attack continues to be too easy.
Part of the problem is that JavaScript developers often use packages that implement simple functions that are either already built into the language, like forEach, or ought to be crafted manually to avoid yet another dependency, like left-pad (now built-in as padStart). These trivial packages get incorporated into other packages, which may in turn become dependencies in different packages, thereby making the compromise of something like "foreach" a potentially far-reaching security incident.
But Vick argues that with so many upstream attack vectors, "We are all just trusting strangers on the internet to give us good candy from their truck," according to the Register. Their article points out that on Tuesday GitHub launched a beta test of improved 2FA security for all its NPM accounts — which Vick calls "a huge win... [T]hat is the best way to protect accounts. We in the security community have been demanding this for years."
But he's still worried about the possibility of email addresses with weak two-factor authentication or compromised NPM employees, and would like to see NPM implement cryptographic signatures for code. "I am talking with a member of their team tomorrow and we will see where this goes."
That's not quite the full story — he probably could have taken control but didn't. Vick acquired the lapsed domain that had been used by the maintainer to create an NPM account and is associated with the "foreach" package on NPM. But he said he didn't follow through with resetting the password on the email account tied to the "foreach" package, which is fetched nearly six million times a week. In an email to the Register, Vick explained... "I did not log into the account, as again, that crosses a line. I just sent a password reset email and bailed.
"Regardless of how much control I have over this particular package, which is unclear, NPM admits this particular expired domain problem is a known issue, citing this 2021 [research paper] which says, 'We also found 2,818 maintainer email addresses associated with expired domains, allowing an attacker to hijack 8,494 packages by taking over the NPM accounts.' In other words, anyone poking around is going to find accounts easy to take over in this way. I was not lucky or special." His point, which he has been trying for several years to communicate to those overseeing NPM — a part of GitHub since March 2020 — is that taking over the NPM account of a popular project to conduct a software supply chain attack continues to be too easy.
Part of the problem is that JavaScript developers often use packages that implement simple functions that are either already built into the language, like forEach, or ought to be crafted manually to avoid yet another dependency, like left-pad (now built-in as padStart). These trivial packages get incorporated into other packages, which may in turn become dependencies in different packages, thereby making the compromise of something like "foreach" a potentially far-reaching security incident.
But Vick argues that with so many upstream attack vectors, "We are all just trusting strangers on the internet to give us good candy from their truck," according to the Register. Their article points out that on Tuesday GitHub launched a beta test of improved 2FA security for all its NPM accounts — which Vick calls "a huge win... [T]hat is the best way to protect accounts. We in the security community have been demanding this for years."
But he's still worried about the possibility of email addresses with weak two-factor authentication or compromised NPM employees, and would like to see NPM implement cryptographic signatures for code. "I am talking with a member of their team tomorrow and we will see where this goes."
Vox Populi (Score:5, Interesting)
The elephant in the room, of course, is by its nature Javascript in the browser and the npm ecosystem has allowed vast numbers of under-trained and inexperienced programmers to not only get their training (or not) and their experience (such as it is) but to deploy their products with very little QA other than the feedback they might get from users or themselves when actually using it.
The next hot pepper ingredient is that the publication process is so cheap and easy that the most trivial function can get into commun use.
The foreaach library is about 20 lines of functional code which, as the article says, and implements something you can do without it. I have a hard time imagining that there are that many people seeking it out and installing it directly. But it is probably referenced by a number of packages that are popular and less trivial, written by someone who composed it by copying some other code or tutorial, and then never removed for generations since everything seems to be working.
The main saving grace in this incredibly fertile ecosystem for cyber-predators is that incursions are not that hard to detect and, when found, excised. As with a chess board, the same open system lets everyone see what is going on.
Personally I have fully bought into this crazy fragile setup but I think I know enough (after 50 years of programming) to managed the risks. I don't think it is all that hard to teach beginners how to do it as well. It just seems to be a neglected subject in all the blogs and tutorials.
Is the maintainer alive? (Score:3)
Here's another elephant to think about: is the maintainer still alive?
(I'm not actually asking if the maintainer has died, just pointing out a potential situation.)
People pass away, sometimes suddenly, and what happens to these single-maintainer libraries when that happens?
We recently had an article about increasing the security of open source software. Perhaps there should be some mechanism of last resort that people could register for, in the manner of landlords and utility bills: there's a mechanism with
Re: (Score:2)
Google has a feature where if you don't access your account for 3 months, it sends an email to your recovery address, and if that is ignored it deletes everything.
NPM should have a similar system where if a user isn't seen for a while it pings them to check they are still there, and if not marks the package as deprecated. It could even install a compile time warning in the code, or some kind of warning when the package manager pulls it, to let users know.
Re: (Score:2)
No reasonably skilled developer would introduce a dependency just to implement a feature that already exists in the language itself, yet a lot of other projects have done just that. Conclusion there's a lot if inadequately skilled developers out there.
It's fine to use others' code to build your own project, I do it myself. However, it is not fine to do it with no audit at all. When I use others' libraries, I look the code over and use the particular version that I have looked over, not whatever happens to b
Re: (Score:1)
Those 20 lines of code are probably copied verbatim from the MDN forEach page anyway, something all those idiots who decided it was a better idea to "just use a package" in their code could have copied.
Re: (Score:1)
This isn't the same as a package from a standard distribution repo or some game you got from Steam. Those get downloaded once and run locally. That means they can be vetted, protected, and even mirrored by local administrators so that problems like a random upstream compr
Not quite the same (Score:2)
a bit of a repost (Score:4, Interesting)
We wouldn't see so many dup stories here if the ones approving the stories regularly read the front page.
Anyway... XKCD is always relevant: XKCD: Dependency [xkcd.com]
Keys? (Score:2)
Everybody knows domain-validation is weak and such authentication should be limited to services tied specifically to that domain. LetsEncrypt, etc.
So what people do for decent security is to use signing keys. I don't even care which domain, say, a Brave update comes from, as long as the signature matches. Perhaps both factors would be better, but given the seriousness involved, why shouldn't packages be signed by default?
There are OOB ways to do authentication if all other options fail, but those should
Re: (Score:3)
Except: many signatures are published on the website of the software author, and a stolen domain could be used to publish a new signature for modified software bundles. Merely adding security steps and marking off checkboxes doesn't improve the underlying security unless other steps, such as validating GPG signatures, are taken. I'm old enough that my key is signed by some very early promoters of GPG, but my personal key might cause havoc if stolen from my personal vault. And not all of my colleagues are as
It's not easy to get a lapsed domain (Score:2)
Re: It's not easy to get a lapsed domain (Score:2)
There's no reason I see to assume they were getting any emails for that address during that time.
No to signed code (Score:2)
Signed code stinks, it causes abandoned software to be unusable after time has passed, come up with something else please. Although it's ok for open source if that code can be copied/forked and compiled etc.
I'm shocked (Score:2)
I'm shocked that npm, or anything that big, wouldn't avail themselves of the domain whois to notice that the npm account is older than the current domain ownership.
This isn't a security issue of using e-mail. It's a security issue of not using the whois date.
It's abandoned. Welcome to humans. That's fine. It can remain as-is forever. npm, for no good reason, is simple ignoring the freely-available piece of information that unarguably confirms it so.