What if the BEAM ecosystem got hit by a worm?

Blogs & Podcasts Blog Posts
, , , ,
1

One package.
One update.
A worm crawling through the BEAM ecosystem.

A dark “what if” — and how we can stop it before it’s real.

11 Likes
2

  1. Keep human control
    After reading the post-mortem of the npm-debacle, one takeaway stands out to me: we should avoid letting CI automatically update packages and dependencies. Keeping this as a manual step—with 2FA—adds a valuable layer of control. It’s a bit like the stock market: crashes sometimes happen when automated systems react blindly to one another’s signals.

  2. Don’t trust humans (yourself)
    Earlier this month, Josh Junon was targeted by a successful phishing attack. While we don’t have full details—such as whether a password manager was in use—it’s notable that the phishing domain (npmjs[.]help) was a clear lookalike. A good password manager would typically flag this, which raises the possibility that one wasn’t used or its warning was ignored. Both could have been prevented and, imho, should have due to the sizes of the packages install base.

  3. The way forward!
    The BEAM ecosystem currently lacks some critical safeguards that could help prevent these types of incidents. That’s why investing in the development of stronger tools and practices is not just important—it’s essential as clearly stated in the linked post.

  4. In the meantime
    In the meantime, let’s stay vigilant, support one another, and make security a shared responsibility.

Lookout fir yourself aaand each other - Jerry Springer.

4 Likes
3

That’s not really the thing I would like people to take from this. Having the possibility that CI’s can publish makes a lot of sense, but only if done right. (Release Environments in GH for example so that only select jobs triggered by the right people get access).

I for sure prefer a clean CI setup over a large project handing out control to a lot of people.

One other way is to force WebAuthn based 2FA for all package maintainers. WebAuthn will not work on any domain.

2 Likes
4

Why not allow CI to build/upload new package versions but then add an additional (browser) 2FA step to “publish” the new version? That way a compromised API token would be much less dangerous but you still get the benefits of CI.

Keep in mind that building on developer machines offers no security benefit here. A lot of these attacks have actually targeted developer machines. It’s only the 2FA step that matters.

A great first step would be to support WebAuthn 2FA at all.

1 Like
5

That’s what I meant.

But you still risk chain attacks that extract secrets from the CI env. There are ways to circumvent it (Release Env’s being one of them), but if major NPM-package maintainers ‘fail’ to do it property, how much should we trust ourselves and others?

Example: only a few weeks ago I realized GH pages were generated and published for every PR. A slight oversight. Each PR could simply add JS or add an extra dependency to the installation instructions.

1 Like
6

Well sure but building outside of CI doesn’t help with that.

All you can really do here is either carefully vendor and check your deps or keep important secrets out of CI.

The 2FA-for-publish strategy is option B there: it makes the secret (hex API key) unimportant (because it can no longer publish).

Fundamentally it seems like the lesson from this npm business is that, actually, communities catch these attacks pretty fast. It’s just that they’ve built tools which propagate code even faster.

1 Like