This article is more than 1 year old

GitHub saved plaintext passwords of npm users in log files, post mortem reveals

Unrelated to the OAuth token attack, but still troubling as org reveals details of around 100,000 users were grabbed by the baddies

GitHub has revealed it stored a "number of plaintext user credentials for the npm registry" in internal logs following the integration of the JavaScript package registry into GitHub's logging systems.

The information came to light when the company today published the results of its investigation into April's unrelated OAuth token theft attack, where it described how an attacker grabbed data including the details of approximately 100,000 npm users.

The code shack went on to assure users that the relevant log files had not been leaked in any data breach; that it had improved the log cleanup; and that it removed the logs in question "prior to the attack on npm."

GitHub already sent out notifications for "known victims of third-party OAuth token theft" in April but today said it planned to "directly notify affected users of the plaintext passwords and GitHub Personal Access Tokens based on our available logs."

Credentials in plaintext, eh? How very last century.

The number of users affected and how long the plaintext storage took place was not mentioned, but we've asked Github for more information. GitHub completed its acquisition of NPM Inc on 15 April 2020. Techies have already taken to the Hacker News messaging board to detail emails they received from npm.

According to the postmortem report:

Following an internal discovery and additional 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.

It added:

While this logging of credentials goes against our security best practices, GitHub or npm did not experience a compromise or data breach that would have exposed these logs containing plaintext credentials.

What information was involved?

Internal finding of plaintext credentials in logs: npm access tokens and a small number of plaintext passwords used in attempts to sign in to npm accounts, as well as some GitHub Personal Access Tokens sent to npm services.

As for the attack first disclosed in April, at the root of the problem, according to GitHub, were stolen OAuth user tokens issued to two GitHub.com integrators; Heroku and Travis CI. So far, so well known – The Register put together some of the puzzle pieces in April.

Salesforce-owned Heroku noted that some of its private repos were accessed on April 9 before slamming the brakes on GitHub integration. That integration was restored earlier this week, according to the company's status page.

While Travis CI didn't think any customer data had been siphoned at the time, it still reissued all private customer keys and tokens for GitHub integration.

The attacker was able to use the stolen OAuth tokens to gain access to npm's AWS infrastructure. With that access, a backup of skimdb.npmjs.com from April 7, 2021 was grabbed. This contained an archive of user information from 2015 (npm usernames, password hashes and email addresses for approximately 100k users) and all private npm package manifests and package metadata as of April 7, 2021.

Private packages from two organizations where also pulled down, although GitHub did not name names.

While the data contained information such as READMEs, maintainer emails and version histories, it did not include actual package artifacts.

However, the hashed passwords do present a problem since the hashes were generated using PBKDF2 or salted SHA1 algorithms, according to GitHub. Things were tightened up using bcrypt from 2017. The passwords have been reset, and users can expect notifications to turn up at some point.

GitHub celebrated the publication of its findings by doing that most secure of things: falling over so users couldn't get access this morning. The majority of its services had a wobble from 0754 UTC. The incident was resolved just before 0900 UTC, according to the source shack's service status page. ®

More about

More about

More about

TIP US OFF

Send us news


Other stories you might like