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.
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..
A GitHub bug could have been exploited earlier this year by connected third-party apps to hijack victims' source-code repositories.
For almost a week in late February and early March, rogue applications could have generated scoped installation tokens with elevated permissions, allowing them to gain otherwise unauthorized write or administrative access to developers' repos. For example, if an app was granted read-only access to an organization or individual's code repo, the app could effortlessly escalate that to read-write access.
This security blunder has since been addressed and before any miscreants abused the flaw to, for instance, alter code and steal secrets and credentials, according to Microsoft's GitHub, which assured The Register it's "committed to investigating reported security issues."
Microsoft's GitHub on Tuesday released its Copilot AI programming assistance tool into the wild after a year-long free technical trial.
And now that GitHub Copilot is generally available, developers will have to start paying for it.
Or most of them will. Verified students and maintainers of popular open-source projects may continue using Copilot at no charge.
Slowly but surely, software package registries are adopting multi-factor authentication (MFA) to reduce the risk of hijacked accounts, a source of potential software supply chain attacks.
This week, RubyGems, the package registry serving the Ruby development community, said it has begun showing warnings through its command line tool to those maintainers of the hundred most popular RubyGems packages who have failed to adopt MFA.
"Account takeovers are the second most common attack on software supply chains," explained Betty Li, a member of the Ruby community and senior front end developer at Shopify, in a blog post. "The countermeasure against this type of attack is simple: enabling MFA. Doing so can prevent 99.9 percent of account takeover attacks."
On December 15, Microsoft's GitHub plans to turn out the lights on Atom, its open-source text editor that has inspired and influenced widely used commercial apps, such as Microsoft Visual Studio Code, Slack, and GitHub Desktop.
The social code biz said it's doing so to focus on cloud-based software.
"While that goal of growing the software creator community remains, we’ve decided to retire Atom in order to further our commitment to bringing fast and reliable software development to the cloud via Microsoft Visual Studio Code and GitHub Codespaces," GitHub explained on Wednesday.
Following the recent disclosure of a technique for hijacking certain NPM packages, security engineer Danish Tariq has proposed a defensive strategy for those looking to assess whether their web apps include dependencies tied to subvertable email domains.
NPM, acquired by Microsoft's GitHub in March 2020, operates the NPM Registry, an online repository of code libraries that web developers include in their applications. It currently hosts almost two million packages and serves more than 174 billion downloads per month.
The attack described earlier this month by security consultant Lance Vick involves identifying NPM packages managed by email accounts tied to expired domains. By registering the expired domain, the attacker then gains control of any email addresses associated with that domain.
"I just noticed 'foreach' on NPM is controlled by a single maintainer," wrote Vick in a Twitter post on Monday. "I also noticed they let their domain expire, so I bought it before someone else did. I now control 'foreach' on npm, and the 36,826 projects that depend on it."
That's not quite the full story – he probably could have taken control but didn't. Vick acquired the lapsed domain that had been used by the maintainer to create an NPM account and is associated with the "foreach" package on NPM. But he said he didn't follow through with resetting the password on the email account tied to the "foreach" package, which is fetched nearly six million times a week.
Malicious packages in the NPM Registry that security researchers for weeks believed were being used to stage supply-chain attacks against prominent industrial companies in Germany turned out to be part of a penetration test run by a cybersecurity company.
More recently, software maker JFrog and cybersecurity firm ReversingLabs this week released their own findings about the multiple malicious libraries in the NPM Registry that all used the same payload and belonged to the same malware family as the one analyzed by Snyk. The goal appeared to be to launch dependency-confusion attacks in which applications within German companies end up using, through a misconfiguration or something like that, malicious npm modules rather than legitimate packages with similar or plausible names. If successful, developers within specific corporations would be fooled into introducing backdoors into their code bases.
Analysis GitHub says it has identified and alerted developers who have had their private repositories accessed and downloaded via stolen authentication tokens.
In this multifaceted fiasco, Microsoft-owned GitHub insisted its security was not breached. Instead, we're told, "compromised OAuth user tokens from Heroku and Travis-CI-maintained OAuth applications were stolen and abused to download private repositories belonging to dozens of victim organizations that were using these apps."
Salesforce-owned Heroku confirmed someone compromised an OAuth token – presumably an internal staffer's token – to get into Heroku's GitHub account and rifle through, and potentially update, users' GitHub repositories "using OAuth tokens issued to Heroku’s OAuth integration dashboard hosted on GitHub."
GitHub has announced that it will require two factor authentication for users who contribute code on its service.
"The software supply chain starts with the developer," wrote GitHub chief security officer Mike Hanley on the company blog. "Developer accounts are frequent targets for social engineering and account takeover, and protecting developers from these types of attacks is the first and most critical step toward securing the supply chain."
Readers will doubtless recall that attacks on development supply chains have recently proven extremely nasty. Exhibit A: the Russian operatives that slipped malware into SolarWinds' Orion monitoring tool. That malware made it into over 18,000 companies, around 100 of which were infected and attacked. GitHub has also had its own problems, such as when access to npm was compromised.
Efforts by Salesforce-owned cloud platform Heroku to manage a recent security incident are turning into a bit of a disaster, according to some users.
Heroku has run security incident notifications for 18 days and appears to have upset several of its customers due to a perceived lack of openness and communication.
Biting the hand that feeds IT © 1998–2022