Npm Password Resets Show Developers Need Better Security Practices
The incident highlights why developers need to improve their security posture and practices, especially since it is estimated that more than 80 percent of any modern application consists of open-source code, most of it consumed from component repositories.
Many of the packages available in the npm registry are interconnected through a complex system of dependencies. If malicious code makes its way into a single one of them, the infection could trickle down to thousands of other packages and potentially millions of end-user applications.
An example of this system’s fragility took place in March 2016, when a dispute over the name of a package led to one developer unpublishing all of his packages from the public npm registry, including a small one called left-pad. This triggered a chain reaction of failures in thousands of other packages that either directly depended on left-pad or were using packages for which left-pad was a dependency. The incident came to be known in the community as npm-gate.
“As we saw with the removal of left-pad in #npmgate, even small components can have an enormous reach across an ecosystem,” said Brian Fox, co-founder and Chief Technology Officer of Sonatype, a software supply chain automation company. “When developers choose to publish their work, they are taking on an extraordinary responsibility, often unwittingly. They need to consider this when choosing how to secure their credentials because it’s not just themselves they put at risk; the risk is to the entire ecosystem should they be compromised.”
The Recent npm Troubles
Npm Inc., the company that runs the npm registry, announced in early June that it had reset the passwords and auth tokens of over 1,000 developers. The decision came after the company was notified by an independent researcher that many npm account credentials were available in data leaks from other websites.
It turns out, developers had used the same password for multiple online services and some of them had their user databases stolen and published online by hackers.
But password reuse was not the only problem. The independent researcher who alerted Npm was Nikita Skovoroda, a member of the Node.js Core Technical Committee. He later published an account of his research into the security of npm credentials on his GitHub page.
Skovoroda, who is known in the developer community as ChALkeR, claims that he managed to obtain valid passwords and authentication tokens for 16,427 npm accounts since May using several methods.
Some of the credentials had been included by the account owners themselves in their npm packages. Other credentials had been uploaded to public GitHub repositories, had been saved in public CI logs, had been pasted into GitHub Gist or something similar.
Some accounts had weak passwords that were easy to guess using standard brute-force techniques, but the largest number of them (12,710) had passwords that were available online as a result of third-party breaches.
The affected accounts were in direct control of 72,298 packages, or around 14 percent of the npm registry. However, the total number of packages potentially affected due to dependencies amounted to over half of the ecosystem, ChALkeR said in his detailed report.
To put the scale of the problem into perspective, forty affected accounts had publishing rights to packages totaling over 10 million downloads per month. Thirteen users had access to packages with more than 50 million downloads per month and four accounts were from the top 20 list. Some had shockingly insecure passwords.
“One of the passwords with access to publish koa [a popular framework] was literally ‘password’,” ChALkeR said, adding that 123 other accounts also used “password” as their passwords. Another 174 developers used the password “123,” 662 used “123456” and 1,409 used the same password as their usernames, he said.
Even after their passwords were reset, some users didn’t take the issue too seriously. According to the researcher, one user whose packages had more than 20 million downloads per month decided to “improve” their previously leaked password by only adding the ! character at the end. Meanwhile, one of the top-20 users set their old password back after it got reset, only for Npm to forcefully reset again.
To its credit, the company has taken preventive measures. It now automatically revokes credentials that are hard-coded inside packages and enforces password requirements that block the use of weak or common passwords.
Npm is also deprecating password-based authentication for some of its API endpoints in favor of bearer tokens that can more easily be revoked and has also implemented brute-force protection and other abuse monitoring systems.
It’s a Larger Problem
Bad password hygiene and hard-coded credentials are issues that have affected multiple technologies and developer communities in the past. In 2014, a researcher found almost 10,000 access keys for Amazon Web Services and Elastic Compute Cloud inside public projects on GitHub.
Then in 2015, a team of academic researchers from Germany found access keys for Backend-as-a-Service (BaaS) frameworks from providers like Parse, CloudMine or Amazon Web Services hard-coded into thousands of mobile applications. Those credentials provided access to 56 million data items stored in backend databases, including car accident information, user-specific location data, birthdays, contact information, telephone numbers, pictures, valid email addresses, purchase data, private messages, baby growth data and even whole server backups.
Last year, researchers from web security firm Detectify found over 1,500 Slack access tokens inside GitHub projects that provided access to Slack team accounts belonging to payment processors, ISPs, schools, advertising agencies, newspapers, healthcare providers and other companies that handle sensitive data. Some of those team accounts contained shared files with sensitive credentials, login information for CI platforms and other internal services and databases, private chat logs and more.
The weak password issue can easily be fixed and looks like npm has solved it, said Frans Rosén, security advisor at Detectify, adding that the problem of credentials being exposed through CI logs is also being addressed to some extent. “I know TravisCI, which has public CI-logs for open source projects made a change to their logs, being more strict on their token cleaning as they did miss a bunch for a long time. This was more in relation to GitHub tokens, but npm tokens were there as well.”
However, according to Rosén, some risks will always remain due to the complicated nested tree of dependencies between npm modules. This creates “a network of peers” that developers need to trust in their applications and any one of those peers can be a weak link.
And it’s not just the problem of leaked or weak credentials that developers have to worry about. Any compromise of their work computers could also be abused by attackers to make malicious modifications to their code.
In 2013, a group of hackers compromised a popular iOS development forum and infected its visitors’ computers with spying malware via a Java exploit that was unpatched at the time. That attack affected developers from many large companies, including Twitter, Facebook and Apple.
“The new reality is that developers themselves are on the frontlines of modern security attacks,” said Sonatype’s Brian Fox. “Their systems, if compromised could be unwittingly injecting malware into an otherwise approved and sanctioned release of their components.”
The large Central Repository for Java components that are hosted by Sonatype requires developers to use GPG keys to sign their releases. This adds another layer of defense against rogue modifications and a method to verify the authenticity of new component versions.
“This is an underutilized capability of the repository as most consumers don’t bother to validate,” Fox said. “However, it stands apart in the various component repositories that don’t even provide similar protections.”
Another security feature that repositories could benefit from is two-factor authentication. This mechanism requires users to authenticate with a one-time-use code in addition to their password, especially when attempting to sign in from new devices. These codes can be sent via SMS to the user’s registered phone number or can be generated through a mobile app.
With or without two-factor authentication, developers — and all users in general — should use different complex passwords for all of their online accounts and should change those passwords periodically. There’s no need to remember all of them, as there are many password management applications, including open-source ones like KeePass, that can be used to securely store them.
Free services like HaveIBeenPwned.com allow users to check if their accounts have been exposed as a result of a data breach. Users can register with their email addresses and receive notifications when those addresses appear in publicly leaked databases.
In the context of npm, it’s also recommended to rotate auth tokens periodically and to review the list of accounts with publishing access to your packages. Any inactive accounts or unnecessary permissions should be removed, as some of the affected users that ChALkeR contacted were not even aware that they had publishing rights to some packages.
Feature Image via Pixabay.