npm Users and Internal data Affected by Stolen OAuth Attack Campaign

The security incident, which was disclosed by GitHub on April 12, related to an unidentified attacker leveraging stolen OAuth user tokens issued to two third-party OAuth integrators, Heroku and Travis-CI, to download data from dozens of organizations, including NPM.

Today, GitHub has shared the details citing to this security incident affecting the npm organization. After investigation, GitHub mentioned that using stolen OAuth user tokens originating from two third-party integrators, Heroku and Travis CI, the attacker was able to escalate access to npm infrastructure and obtain the backup of skimdb.npmjs.com containing data from April 7, 2021, from npm cloud storage along with the following information — 

• An archive of user information from 2015. This contained npm usernames, password hashes, and email addresses for roughly 100k npm users.
• All private npm package manifests and packages metadata as of April 7, 2021.
• A series of CSVs containing an archive of all names and version numbers (semVer) of published versions of all npm private packages as of April 10, 2022.
• Private packages from two organizations.

After analysis of log & event and package hash verification, GitHub confirmed that hackers did not modify any published packages in the registry or publish any new versions to existing packages.

On further investigation unrelated to the OAuth token attack, GitHub discovered a number of plaintext user credentials for the npm registry that were captured in internal logs following the integration of npm into GitHub logging systems. 

Currently, this issue was mitigated and logs containing the plaintext credentials were purged prior to the attack on npm.

Access to npm Internal Data and User's Details

GitHub noted that during their investigation they learned hackers were able to access internal npm data and npm customer information. Using OAuth user tokens for GitHub.com, the actor was able to exfiltrate a set of private npm repositories, some of which included secrets such as AWS access keys.

With one of these AWS access keys, the actor was able to gain access to npm’s AWS infrastructure. After accessing the npm's AWS infrastructure, the hacker exfiltrate an older backup of the skimdb.npmjs.com mirror, which included metadata and package manifests for all public and private packages in the npm registry as of April 7, 2021. This exfiltrated data includes READMEs, package version histories, maintainer email addresses, and package install scripts, but does NOT include the actual package artifacts.

This database backup also contained an archive of npm user information from 2015. We identified that approximately 100k npm user login details, including account names, email addresses, and password hashes, were part of this archive. The password hashes in this archived data were generated using PBKDF2 or salted SHA1 algorithms previously used by the npm registry. 

These weak hashing algorithms have not been used to store npm user passwords since the npm registry began using bcrypt in 2017. Passwords belonging to the impacted users have been reset and we are in the process of notifying these users via email directly.

For the security concerns, the npm registry has enabled email verification on all accounts that do not have 2FA enabled. With this additional protection, it would not be possible to compromise any npm account without access to the account’s associated email address (or, a second factor if 2FA is enabled).

Furthermore, the hacker has also accessed S3 buckets storing packages for the npm registry. In this hack incident hacker also exfiltrated a small subset of private package contents belonging to two specific organizations.

GitHub didn't disclose the name of the affected organizations, but the company notified these two impacted customers of their exposure directly.

On the advisory, GitHub says — 

"Over the next few days, we will directly notify those with exposed private package manifests, metadata, and private package names and versions."

"If you did not receive any of these emails from us, we do not have evidence that your data was accessed by the attacker."

"Our initial and current investigation has concluded that only internal GitHub employees had access to this data at the time of exposure. While this involved no known compromise, user privacy and security are essential for maintaining trust, and we want to remain transparent even about events like these that go against security best practices. It is in that spirit that we’re providing the information below." — GitHub added.