
GitHub stored a number of plaintext user credentials
Oh. My. God.
That is a major boo-boo.
Shame on you, GitHub. You knew better than that.
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 …
One of the first lessons junior devs get pummelled into them ( or they should if their mentors are worth their salt ) is never, ever put anything in a repo you don't want to share, even private repos. Then chuck in the fact that scanning public repos is one of the standard gathering exercises that even the most basic security course will teach you how to do.
These fact alone are standard practice and should have put Github on the offensive on all their activities.
One of the first lessons junior devs get pummelled into them ( or they should if their mentors are worth their salt ) is never, ever put anything in a repo you don't want to share, even private repos.
This is why I never swear in source code. There is a (probably apocryphal) story about a software developer who worked at a bank. While testing a mailshot he had a bit of a laugh to relieve the monotony. Unfortunately he forgot to tidy his code before he released it. Consequently the banks top 10% of clients got a letter starting:
Dear Rich Bastard,
....
…my approach of NOT EVER sharing credentials with a system I don't control.
The current "best" (or rather usual) practice for continuous deployment (CD) setups such as implemented via GitLab (I don't have experience with Travis or GitHub) revolve around giving the CD server credentials to the target system where the software is to be deployed.
No way Jose.
So I use a pull approach* (give the target servers credentials to the CD server), which negates many of the supposed advantages of the whole so called DevOps approach, aka house of cards.
* This doesn't prevent certain other attacks, such as tampering with the source code or the build system, for the parts that are built or archived on public servers.
Replying to my own comment…
I am of course not surprised by GitHub's fail. It's a given that the tokens are stored as plain text, otherwise they wouldn't be usable, though to be honest I would have expected them to store the (plain text) tokens in some form of encrypted vault, which reduces, but does not eliminate, the attack surface, especially while at rest.
Some context is worthy here. Github didn't write this code, npm did. Github acquired npm, and integrated npm's software into Githubs logging infrastructure.
npm's devs most likely wrote debug/info log statements that were only meant to be seen by the developer during tests/local development. npm's systems probably only logged at the higher log level, whilst github most likely logged at a lower log level.
It doesn't mean its not a fuckup, but I can see how it happened. Your boss buys a company, you have to integrate the sketchy software immediately otherwise service is disrupted. I bet they are reviewing every line that came from npm now..