Recent open source flaw highlights danger of 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.

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."