Open source is an amazing model and tool, and it’s not a stretch to say that open source is in many ways responsible for the rapid acceleration of technology over the last 20 years. The Linux Foundation recently surveyed and found that almost every organization today uses open source code. CTO of the Cloud Native Computing Foundation and Co-Founder of the TODO Group at The Linux Foundation said, “it has become table stakes for most businesses, even though it’s not always fully understood at the executive or strategic level.”

Despite this, or maybe because of it, open source is also a security minefield. Successful libraries are responsible for securing the code used by millions, the teams that maintain them do so unpaid and in their spare time, and changes pushed in the master codebase are often propagated and given greater authority by package aggregators. I’m not talking about vulnerabilities in the code right now, I’m talking about what happens when the inherent vulnerability of the supply-chain gets compromised.

We saw an example of this just this week when an attacker breached a widely used node.js module.

The module had more than 2 million installs, but the core developer had gotten busy with work/life/other and no longer had time to maintain it.

That left the master codebase exposed to an attacker, who executed a clever long-play attack using a mix of pretexting and technological brute force.

  • The attacker first contributed to the library, building trust.
  • Over a short time, the attacker befriended and offered to take on the maintainer role to lighten the load on the original developer
  • Once master merge authority was given, the attacker merged a trojan into the library which monitored for Bitcoin and Ethereum hot-wallet credentials, checked the wallet’s balance, and sent the credentials to an offshore server.
  • The trojaned version was pushed to the npm package manager, and from there was distributed into the wild. This last piece is a normal part  of the open-source update process, but in this case it had the effect of pushing malicious changes into production systems – all by using by a process the owners of those production systems don’t control.

This is the scary part. How do you stop that? Especially if you want/need normal non-malicious updates? You don’t, you just have trust that it’s safe. Unfortunately, as we saw here, this isn’t always safe.

In the world of modern software, it’s turtles all the way down… Just because the code you write is secure doesn’t mean the the code others write for you is. The only way to get ahead of this, the only way to prevent what happened here, is deep and continuous abuse-case (i.e. security) testing.

In the meantime, for this particular hack, you can watch the power of the Crowd in action by following the comments in the Github page. There you’ll see developers reverse-engineering what the attacker did and helping identify impact and severity.

It’s also a great way to learn. Nearly half of our Crowd say they learned to hack via online resources and blogs.