Problem solve Get help with specific problems with your technologies, process and projects.

Recent open source flaw highlights danger of social engineering hacks

What happens when open source developers hand the keys of their project over to a new maintainer? It can expose applications to serious security threats.

When a compromised NPM package with malicious code targeted a popular bitcoin wallet, hackers managed to corrupt...

one of the JavaScript modules, called event-stream, used as part of the Copay bitcoin wallet application. The hackers would have been able to drain bitcoin wallets, although there is no evidence it was activated before it was discovered.

This is a novel new approach to take advantage of software developer burnout. These social engineering hacks target the software packages developers use to craft JavaScript applications. The now-common way to build modern apps -- hundreds of individual software libraries, packages or modules -- is a security vulnerability.

This is particularly significant for enterprises that develop client and server apps on top of JavaScript that use the NPM package manager to automatically pull in updates. Organizations should also consider the kinds of practices that vet the security of Java and C# libraries.

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

NPM tooling has helped repurpose JavaScript for server applications. It's made it easy to mix and match the best components for a particular task. While this greatly speeds app development, it also makes JavaScript a popular target for hackers.

There are other factors, aside from its popularity, that make the JavaScript ecosystem more vulnerable to targeted attacks. For starters, NPM will pull down the latest libraries from the repository by default, Fox said. This means successful injection to the repository has immediate propagation to the consumers of those libraries. In contrast, Apache Maven emphasizes basic configuration management principles of build reproducibility and won't pull the latest versions unless you explicitly request them.

Secondly, hackers often can't tell what dependencies are used behind a service written in Java and C#. Many JavaScript application modules, however, are delivered to the browsers, and this visibility lets hackers identify vulnerable packages. Hackers can directly observe how this code is constructed and what dependencies it uses.

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.

You are responsible for the libraries you require, so you want to have processes in place to vet your code.
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."

This was last published in December 2018

Dig Deeper on Open source Java

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

What measures does your organization take to ensure the open source code you use doesn't create vulnerabilities?