When a compromised NPM package with malicious code targeted a popular bitcoin wallet, hackers managed to corrupt...
We often build modern applications by extending and configuring software modules from code repositories, package managers or GitHub. This saves developers time, but it also expands the software attack surface and particularly opens the door to social engineering hacks.
Social engineering is a new software attack surface
In the Copay case, the hacker was able to take over maintainership of a popular module in the NPM ecosystem. Doing so established a bit of a history, giving the hacker the look of a real maintainer. Then, the module's actual maintainer handed over maintenance of this package and later explained he did so because he wasn't compensated for maintaining the module and hadn't used it in years.
This illustrates one of the weaknesses of building applications on top of code written and maintained down the open source ecosystem.
"It's basically software developer burnout as a software attack surface," said Adam Baldwin, head of security at NPM. "If someone doesn't have the time to maintain a module, how do you expect them to invest time to vet a particular person who wants to take over its maintainership?"
Security experts first saw efforts to inject malicious components into the software supply chain in 2017. This was the first time hackers used social engineering as an attack to take over a project. Previous injections came from either typosquats or (allegedly) stolen credentials, according to Brian Fox, CTO at Sonatype, a secure software supply chain tool vendor.
Interestingly, the malicious payload was removed just three days after the initial publication. This may have been to cover the hacker's tracks after the payload had been successfully adopted into the Copay application.
"All of these facts just continue to reinforce that we aren't dealing with people seeking to exploit latent vulnerabilities," Fox said. "Hackers are now moving beyond introducing new [vulnerability] and then opportunistically exploiting victims. [They're] selecting a specific victim and backtracking how to exploit them via the supply chain."
Open source code is vulnerable
A third aspect, Fox asserted, is that less-tenured developers publish components in newer ecosystems, such as NPM. This especially stands out compared with BSD or Apache HTTPD. These developers are less likely to adopt secure coding practices, such as vetting libraries and choosing a strong password.
NPM does have built-in protections
The NPM ecosystem does have some mechanisms that help limit the impact of attacks. Once a vulnerability has been identified, NPM places the suspect code in its vulnerability database. Once code has been flagged as insecure, NPM will alert developers who try to install it. NPM will then prompt them to install a safer version.
Adam BaldwinHead of security, NPM
In addition, NPM has automated detection tools. Although NPM continues to invest in more automated detection and analysis, it missed the Copay attack.
"Without manual auditing, I don't believe anyone would have found it," Baldwin said. A September 2018 NPM audit identified known vulnerabilities in about 51% of the packages that developers were attempting to pull down.
Best practices to secure open source code
Unfortunately, there is no magic bullet to ward off social engineering hacks. Even when enterprises cover all the security holes in their systems, hackers are always discovering new vulnerabilities on even some of the most highly vetted software packages. But enterprises can take steps to minimize the use and impact of malicious packages.
One thing developers can do is use code more judiciously. "You are responsible for the libraries you require, so you want to have processes in place to vet your code," Baldwin said.
For example, NPM's enterprise product helps control the packages that developers install and audits the software supply chain for unsafe dependencies. A command called NPM-audit was introduced in 2018 to automate vulnerability warnings.
Enterprises need to assume attacks will happen and prepare for a response. They need a definitive list of components they use and in which applications.
"If you can't immediately answer two simple questions: 'Are we affected by this?' and, if yes, 'Where?' then you have little chance to be able to quickly protect your applications," Fox said. "Unfortunately, many organizations are still unable to achieve this basic level of supply chain hygiene."