Microsoft's GitHub account allegedly hacked, 500GB stolen
bleepingcomputer.com
bleepingcomputer.com
I believe that the stuff they're open sourcing go on GitHub, while the internal tools go on Azure DevOps. They also have their own VCS (Git alternative) called Team Foundation Version Control (TFVC), though I have no clue why they keep that thing around. They've also had Microsoft Visual SourceSafe, but even they themselves didn't really use that.
On a side note, they really suck at naming things.
Github Actions and Azure Devops Pipelines, for example, utilize the same infrastructure in my understanding.
While I prefer GitHub Actions in most respects, duplicated setup work and jobs are handled much better by the Azure version currently IMO.
This is some weird Microsoft thing. I think Windows 10 development is now handled by the "Azure" org[1]
[1]:https://www.zdnet.com/article/how-microsofts-azure-organizat...
Sure, dogfooding is good, but commercially sensitive repos would seemingly - to my naive view - be better on private servers?
More internal Microsoft code was being hosted by Github instead by Microsoft.
However, the Microsoft account on Github seems to only be public repositories, or repositories being prepped to be public. Actual internal stuff is hosted by one or more Github Enterprise accounts, the alleged hack does not claim they were hacked as well.
One, this doesn't address exactly how the repo was compromised. Likely one of the many folks with access had their credentials compromised, but until we know, there may be risk to other projects. Two, as the article mentions, it may not have had all passwords or API keys scrubbed.
Couldn't the "hacker" have simply generated a new GPG key and added it to the account he had control of?
This seems like a non-story.
That being said, Microsoft actually moved Windows to Git [2] years and years ago. Presumably they did the same with everything else. Team Foundation Server (TFS) supports Git, so they probably have the critical stuff on that TFS still, rather than GitHub. Especially since those repo's are huge.
[1] https://en.wikipedia.org/wiki/Microsoft_Visual_SourceSafe [2] https://arstechnica.com/information-technology/2017/02/micro...
Github ended up being the final piece they needed after years of effort. Most of what I said in the earlier comment was what I pieced together from multiple (ex-)Microsoft people who chose to talk about it, over years.
TFS afiact started as just a repo manager (in the sense, does what Github does) for VSS and Perforce, with more modern support for other things, including Microsoft's gargantuan Git monorepo... but a lot of people at Microsoft still like Github Enterprise better.
I imagine given this, whatever TFS does better, Github Enterprise will learn to do over the next few years. Microsoft is big on eating their own dogfood now, but they don't seem to want to do Google sillyness where they have 20 products that do the same thing and let them fight it out in FFA arena combat (even Lync is still Lync underneath, it just keeps getting new frontends).
mmm.. I know what you're saying but the change to Teams from a VOIP perspective substantially changed some of the under-the-hood stuff. They stood up a facade to offer luke-warm integration from SfB/Lync IP phones (authentication and basic calling, but that's about it). AFAIK this wasn't just a breaking change but a re-arch of some of the backend. Point being, they may be evolutions but the move to Teams is not just a new front-end. Substantial evolution has happened since we first installed server stacks to support Lync, even though we still see Lync fingerprints and junk dna everywhere.
At the time, most teams (that I encountered) used something called Source Depot. I was told that back in the day, MS licensed the source code from Perforce, forked it, and that became Source Depot. I do know there were some teams using TFS and I'm sure there were some smaller teams using Git too.
I'm not sure how the transition went, since I left before it started, but I would bet it's still at least somewhat ongoing. Some of the people on my team that had been at MS for awhile were EXTREMELY skeptical of change.
It was Source Depot, a fork of Perforce.
However, IIRC they moved to a git based Git Virtual File System for windows development a few years back..
Hows that coming along, I wonder.
Then macOS removed kernel extensions, so they came up with a different approach and released that too. Search "scalar" to see it.
VSS hasn't been used in a decade or more.
Other than private keys or sensitive info being left behind, doesn't appear to be severe. Looks nothing burger given the data until more is released.
> Microsoft employee Sam Smith replied to Under the Breach's tweet stating that he thought the leak was fake as "Msft has a “rule” that GitHub repos must be public within 30 days."
Curious, what does microsoft use internally? Instance of github enterprise? Azure devops?
I guess they have internal Git servers, since they develop VFS for Git[1] to handle large amount of files in git, but IIRC github isn't support it yet
First was our description of our JSON apis, which would eventually be sent to a public github.
The second was some internal documentation we had for our internal clients. I don't think there were any 'secrets' in there, but it would be documentation for the internal side for internal clients that no outsider could ever use.
That's not how "leaks" and "hacked" works the last time I checked.
Well, someone asked the other day whether or not private repositories on GitHub were safe: [0] I think you now have a concrete answer regardless if this is true or not. I have already made the case to privately self-host, especially if you're a large enterprise, but preferably on-site [1][2] to avoid these types of attacks and in the process to reduce costs like this as many were discussing in other HN discussion [3], but here we are.
If they can do it to Microsoft, they can do it to anyone else who has a GitHub account.
[0] https://news.ycombinator.com/item?id=23057769
[1] https://news.ycombinator.com/item?id=22960579
It happened to Cisco as well a while back, I have a copy of that source somewhere.
I don't know where you are but the bulk of the jurisdictions would not look favorable upon you. I agree that your loose interpretation of the law might work out in your favor. But just like downloading copyrighted material is illegal so is downloading copyrighted data from a source that you know does not have the option to legally give you a license to copy or use that data. So from one aspect of the law you are in the clear, from another this is an open-and-shut case of copyright violation and on top of that you will have to work real hard to prove that you weren't the one to steal it in the first place using the 'upload to someplace anonymous, then download it again' trick to whitewash the data.
Some risks are worth taking, this particular one I'd think long and hard about it if the counterparty is the proverbial 800 pound gorilla.
In terms of criminal law, it is favorable to me. Source: I was criminally accused and have a court judgement clearing me of wrongdoing for possessing information that was stolen by 3rd parties and published online before I obtained it.
>So from one aspect of the law you are in the clear, from another this is an open-and-shut case of copyright violation
I am satisfied that merely possessing stolen information and not distributing or profiting from it is not a copyright violation if the source code can even be copyrighted.
>But just like downloading copyrighted material is illegal so is downloading copyrighted data from a source that you know does not have the option to legally give you a license to copy or use that data
I have not agreed to be bound by any licenses from Cisco before downloading the data nor did I necessarily know what it was before downloading a zip from a file sharing site.
I'm happy to discuss this over email if you want me to reach out for debate.
Ultimately, your weakest point ends up being humans who are prone to mistakes. You can mitigate some of those mistakes with technology but you can't mitigate all of them. So SaaS may help shore up certain attack vectors but it may increase focus on the remaining vectors and may potentially make failure points more significant (more impact for a security breach from a large provider vs less impact of a security breach from systems of independent providers). Some of that can be mitigated with smart designs, but you lose some advantage of traditional "security through obscurity" which has some value (though it shouldn't be relied on as a failsafe).
Those are only somewhat aligned, as anyone with a dispute about terms of service can tell you.
> which can be a bit much for one person who's self-hosting
If your repo serves one person, why do you need your repo to be hosted in public at all? `git init` and a backup are all you need.
I don't think this is necessarily true. Microsoft's org, like any large org, has a large number of users with access. Its security is dependent on each one of those many accounts being secure.
A smaller org, or an individual, can secure their repositories much more easily as there's fewer entrypoints.
They haven't mentioned whether this hack was achieved by compromising individual account credentials, or by compromising the Github platform itself. If it's the latter, you may be right, but I suspect it's more likely the former.
How do we have a concrete answer if this is not true?
One can just encrypt the .git folder and wrap the git client to handle the encryption/decryption on use. It's always a question where and how well do you keep the keys.
You’re absolutely right about the deltas. Initially I had one secrets file per environment, but as my projects grew I ended up breaking them out to a file per environment-project. Both for storage reasons and because it’s difficult to modify one encrypted file from multiple branches without writing plaintext secrets to disk.
1: https://keybase.io/blog/encrypted-git-for-everyone
0: https://blog.zoom.us/wordpress/2020/05/07/zoom-acquires-keyb...
How many companies, in terms of Market Cap are currently relying on GitHub Private Repo for their source code?
And how does very large enterprise, or financial institution ( Which is like the foundation of modern day society ) handle their source code? I presume they wont use Github for anything important?
This, if true, is almost definitely a compromise and use of a single users' access credentials, which were then rotated (thus the attacked losing access).
I'm not saying that credential stuffing isn't a large-scale problem (I strongly believe that it is, and have even dedicated time to some potential solutions in the past), but jumping from "someone lost their credentials" to "omgz github can't be trusted!" is a bit of a disingenuous leap.
What makes you think you can do a better job than Microsoft or github?
Here's the security of the "cloud":
https://arstechnica.com/information-technology/2012/03/hacke...
Why on earth should a maintained server that just runs git over ssh be less secure?
regardless, I agree.
Or, in other words, if you want to keep something private, don't put it in the "cloud"!
The lesson I carry is that the more secret it something is, the closer to my brain it is. Top-secret = only in my head, little bit secret = encrypted on my harddrive, little less secret = encrypted in the cloud, not secret at all = just dumped in a Google Drive account
Then most people think more carefully about where they store it :)
"What's done in darkness will come to light" is an oft-used adage in English of Biblical origin. Many variations. I agree with it, too.
> In a directory listing and samples of other private repositories sent to BleepingComputer, the stolen data appears to be mostly code samples, test projects, an eBook, and other generic items.
> Microsoft employee Sam Smith replied to Under the Breach’s tweet stating that he thought the leak was fake as “Msft has a “rule” that GitHub repos must be public within 30 days.”
Does that mean MS bans the use of GitHub for permanently storing private repos?
There are hundreds of different kinds of credentials that can be hidden all throughout the history of a Git repo (in code, in logs, in comments, binary blobs, etc). If you don't have a very robust credential scanner operating continuously, and you have a large organization, you probably have active credentials hidden in your private repos.
It is a new and ever changing field, there are many cloud vendors and their product line and configurations change all the time - meaning it will take a lot of time until majority of IT specialists become familiar with configuring secure cloud and majority of users of those cloud services will not make security mistakes.
in cloud - it all new. people are still figuring out how to deploy their software so that it works both for users and developers. That's why on average onprem is more secure than cloud.
I feel like the hacks I hear about are pretty evenly distributed between cloud and on prem type setups... and most of the big ransomware attacks are almost exclusive to on prem.
Also firewalls/DMZ/IDS has nothing to do with a SaaS offering from GitHub. That on prem setup you mentioned would be practiced by GitHub.
My opinion of general on-prem security is that it's often haphazard and updates are almost never applied.
But also a lot of on prem security practices hamper developers and users. Because they rely on decades old outdated ways of working.
Also your comment makes no sense as this is likely to be a hack through stolen credentials.
> Also, the 2004 leaked Windows source code was not seen as legal risk for ReactOS, as the trade secret was considered indefensible in court due to broad spread.
This sounds like Microsoft can't benefit from a public leak.
In your first ReactOS example from 2006 it wasn't even Microsoft that discovered or claimed the problematic code violation. It doesn't look like Microsoft was involved at all.