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
