Event-Stream Backdoor Doesn't Mean Open-Source Community Failing at Security
News last week that event-stream, the popular open-source code library managed by NPM, had been compromised by a hacker (or hackers) looking to steal Bitcoin led some to question the underlying security of the open-source components that they are using in their software.
According to reports, a hacker gained control of the event-stream package by offering to take over maintenance of the open-source project from its creator. This component, with its 2 million weekly downloads, was used in the Copay Bitcoin digital wallet, buried deep in one of its dependencies. Once in control, the hacker reportedly injected malware into the node.js library, adding a piece of code with a backdoor into the wallet app. An industrious security researcher, who is apparently a computer science student at California State University, Fullerton, is credited with initially discovering the backdoor.
While users of open-source components expect some inadvertent bugs and vulnerabilities to be present in the code that is taken from open source, like all software, they trust that the maintainers of projects are acting in good faith and will not intentionally include exploitable code in their libraries. Essentially, we give them the keys to our businesses, leaving the door open for them to come in and fix the place up at night when needed.
But what happens when the evil maid comes in and uses their access to steal and undermine our security?
Given the fact that open-source software comprises between 60 and 80 percent of the code base in modern applications, the idea of abandoning it is unrealistic, bordering on heresy. In performing a postmortem that can actually lead to actionable insights, we should try to take a look at what made this attack work and why it might not be as big a threat as some would have us believe.
Assessing the Facts of the Case
We need to face the fact that as long as we are building applications to hold information worth stealing, hackers are going to try and compromise them.
By all accounts, the Copay hack was a rare case when it comes to the hacking of open-source components, and not representative of the vast majority of attacks involving open-source projects.
To start with, it targeted a specific victim. According to reports, the malicious code contained in the injected library only became active if it detected that it was being used in a specific environment. Realizing that they were compromising a popular component, the hacker apparently wished to avoid setting off too many alarms by impacting software outside of their intended target. Considering these circumstances, it is likely that the attacker examined their intended victim, and worked backward, looking for an easy point of entry—eventually leading them to approach the developer who had created the library.
This attack was actually quite unusual, as open-source component hacks go, in that at its core, it was a social engineering operation and not the exploitation of an existing vulnerability. In describing how the attacker took control of the event-stream project, its original owner, named Dominic Tarr, described in his statement that he was approached by someone who claimed to be willing to take the project off of his hands. Having lost interest in keeping up the project some time ago, Tarr says that he was happy to turn it over to someone with the GitHub username @right9ctrl. From there, the hacker was unhindered when they injected their code in October, simply having asked for access.
Known Vulnerabilities Pose A Significantly Higher Risk To Software
While there has been some indication that supply chain attacks are an increasingly attractive option for hackers, they are also impractical when it comes to performing scalable and profitable attacks. This kind of attack is highly targeted and does not represent a real threat to the “health of the herd,” as it were.
In a “classic” open-source exploitation, hackers prefer to target known vulnerabilities—the flaws in the components which are discovered by researchers and published on databases like the National Vulnerability Database (NVD).
Instead of having to go through the work of taking over a project and slipping in malware during a short window, hoping to catch a single target with a hack, they can receive all the details about what is vulnerable and how to exploit it from the posting on the database. From there, all they have to do is ping targets to see who is using the vulnerable version of the component. This tactic nets them far more potential victims with only a fraction of the work.
As the number of published open-source vulnerabilities has risen dramatically over the past two years, attackers have a wide range of options in choosing ready exploits to use for their own malicious operations.
Sometimes, The System Works
The good news is that the open-source community is actually pretty great at dealing with issues of security. Even though the attacker managed to compromise the component, their attack was discovered relatively quickly.
Once uncovered by the student researcher, the open-source community sprang into action. Word of the vulnerable component has made its way out to users throughout the industry at a rapid pace, and the users of the offending package are quickly upgrading to the unaffected version.
The solution to attacks like those on the supply chain is not locking down the community with harsh regulations in what amounts to an act of security theater. Instead, we need more engagement with the community, encouraging them to continue monitoring and maintaining projects. When issues—be they bugs or vulnerabilities—do arise, these talented volunteers are the ones to develop a fix.
At the end of the day, the community of developers care about the health of their ecosystem and are quite keen on policing it. Messing with this mechanism is unlikely to lead to a desirable outcome.
Where Do We Go From Here?
While attacks like event-stream are always a possibility, there are a couple of steps that we can take to improve our overall security.
The first is to know which components are being used in our products, including in dependencies. Developers love open source because it can be a quick fix, but far too often they fail to check if it has any known vulnerabilities associated with it. Nobody digs down to the dependencies. There are automated tools out there—including ones made by my company, WhiteSource Software—that can help to provide visibility into an organization’s open source usage and prevent vulnerable components from being used in a product.
If businesses are going to depend on open-source tools for their products, then perhaps more thought needs to go into how we give back to the open-source community. There are options, such as supporting open-source projects with sweat effort contributions by having company developers take the time to help maintain the code, and, at times, giving financial support as well. Companies should also give thought to what their responsibility is to their users when utilizing open-source components—and what measures they are taking to code securely.
Like any group, there will be bad apples out there looking to take advantage of a situation. But we should not overreact when incidents like these occur.
Instead, we need to trust that the community will continue to keep us safe, weeding out the vulnerabilities and bad actors along the way.