Comment by ajross
2 years ago
Most of this report is just noise. GitHub repos are public. Public stuff can be shared. Public stuff shared previously and then deleted is "still available", but it was shared previously and not really subject to security analysis.
The one thing they seem to be able to show is that commits in private branches show up in the parent repository if you know the SHAs. And that seems like a real vulnerability. But AFAICT it also requires that you know the commit IDs, which is not something you can get via brute forcing the API. You'd have to combine this with a secondary hole (like the ability to generate a git log, or exploiting a tool that lists its commit via ID in its own metadata, etc...).
Not nothing, but not "anyone can access private data on GitHub" as advertised.
> it also requires that you know the commit IDs, which is not something you can get via brute forcing the API
Well, GitHub accepts abbreviations down to as short as four hex digits... as long as there's no collision with another commit, that's certainly feasible. Even if there is collision, once you have the first four characters you can just do a breadth-first search
There's a whole section here about how to brute force the hashs. You don't even need the full hash... just a shortened version using the first few chars.
I'm dubious. Searching for globally unique commit IDs is still a least a million+ request operation. That's easy enough in a cryptographic sense but the attack in question requires banging a web UI, which is 100% for sure going to hit some abuse detector. I really don't think you can do this in practice, and the article certainly doesn't demonstrate it.
They released a tool to do this in a followup post: https://trufflesecurity.com/blog/trufflehog-now-finds-all-de...