Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Anyone can access deleted and private repository data on GitHub

trufflesecurity.com

Post reply on HN
Print view View original

371–380 of 394 posts

Re: Anyone can access deleted and private repository data on GitHub

#371

Post by quectophoton »

mmsc wrote: post #26

>This is such an enormous attack vector for all organizations that use GitHub that we’re introducing a new term: Cross Fork Object Reference (CFOR) Have we stopped naming vulnerabilities cute and fuzzy names and started inventing class names instead? Does this have a logo? Has this issue been identified anywhere else?

Best I could come up with after thinking for a moment is "AGHAST": "Astonishing GitHub Availability (of) Source Trees".

But I'm still not entirely satisfied with the word choice.

Re: Anyone can access deleted and private repository data on GitHub

#373

Post by K0balt »

yencabulator wrote: post #360
K0balt wrote: post #284

Earlier quoted context omitted.

The property (“bug”) in question is an inherent and intentional property of meekly-tree type storage systems such as git. Calling this a bug is like reporting that telnet sends information unencrypted. The actual bug is in the way that their UX paradigm sets user expectations.

Don't blame Git for Github decisions. Github chooses to store all "Github forks" in the same repository, and allow accessing things in that repository even when they are not reachable by the refs in the namespace of one "fork". That is purely a Github decision.

They could have split forks off into new repos, but then they wouldn’t be forks, in the repository sense. It was never hard to just copy a repo instead of forking it. The UX just leads people into holding it wrong.

Re: Anyone can access deleted and private repository data on GitHub

#374

Post by thrdbndndn »

Dylan16807 wrote: post #366
thrdbndndn wrote: post #219

I cannot access the commit https://github.com/trufflesecurity/trufflehog/commit/7bc0b shown in one of the pictures in the article (right before "Where do you get these hash values") despite this repo is even public. What gives?

It's probably either that they took the picture a while ago, or they were going character by character and accidentally screenshot with one too few. All of these are valid right now, and the first one is the one they show: https://github.com/trufflesecurity/trufflehog/commit/7bc0b2 https://github.com/trufflesecurity/trufflehog/commit/7bc0b4 https://github.com/trufflesecurity/trufflehog/commit/7bc0b8 https://github.co…

Thanks! Yeah probably the latter. The chance of they having 4 commits sharing the same first 5 letters after the fact is unlikely with mere 3k commits. So it's more plausible that they searched around their commit hashes and used the most duplicated prefix as an example at the time.

Re: Anyone can access deleted and private repository data on GitHub

#375

Post by raesene9 »

tptacek wrote: post #339
raesene9 wrote: post #298

Earlier quoted context omitted.

In my (admittedly limited) experience, whilst payouts for bugs might be seen as a positive internally, payments for bad architecture/configuration choices are less so (perhaps as they're difficult to fix, so it's politically not expedient to raise them internally). To provide one example I reported to a large cloud provider that their managed Kubernetes system exposed the Insecure port to the container network, meani…

Repeating myself: this almost certainly has nothing at all to do with the money they'd have to give you (I assure you, if there's even a whiff of legitimacy to your report, the people managing the bounty would probably strongly prefer to pay you just to get you off their backs) and everything to do with the warped incentives of paying out stuff like this. People forget that the whole point of a bug bounty is that the…

Yep that's the point I was making, they don't want to pay out on architecture/configuration changes if making those would be expensive/difficult.

That doesn't mean the report isn't legitimate (being cluster-admin with no authentication is generally considered not to be a good security idea, in fact it's about as bad as it could get without putting the insecure port on the Internet), but that bug bounties aren't architected to accept that kind of issue. The challenge with this is it means that bug bounty researchers won't look for that kind of (legitimate) security issue as they get to know the programs often won't pay out.

Personally, I don't ever report bug bounties for the money reward, but so I don't get shouted at by companies when I write a blog or do a talk that covers the issues :) In this case I was a bit annoyed that they combined telling me it wasn't a bug, with asking me not to mention it publicly for 6+ months (IIRC they credited me like years after the fact).

Re: Anyone can access deleted and private repository data on GitHub

#376

Post by account42 »

sgc wrote: post #323
account42 wrote: post #308

Earlier quoted context omitted.

> People's entire livelihoods are at stake No they aren't.

Sure they are. If somebody has a proprietary product that they happened to organize as a fork of an open source base at some point, it is exposed. The git organization aside, that is a very common business model.

Companies may think that their proprietary code being leaked is a serious threat to their business but that is almost never the case. No one is going to care about your shitty codebase.

Re: Anyone can access deleted and private repository data on GitHub

#377

Post by 93po »

account42 wrote: post #292
93po wrote: post #37

Earlier quoted context omitted.

companies vary wildly in their honesty and cooperation with bug bounties and develop reputations as a result. if they have a shit reputation, people stop doing free work for them and instead focus on more honest companies

Not all free work is wanted. Discouraging frivolous reports is exactly what is being accomplished by not paying for them.

there are endless examples of reports that, by the judgement of the community, are entirely valid and unknown security concerns and fit within the guidelines of a company's bug bounty program, and do not ever result in payment

Re: Anyone can access deleted and private repository data on GitHub

#378

Post by MatthewWilkes »

andersa wrote: post #4

I reported this on their HackerOne many years ago (2018 it seems) and they said it was working as intended. Conclusion: don't use private forks. Copy the repository instead. Here is their full response from back then: > Thanks for the submission! We have reviewed your report and validated your findings. After internally assessing the finding we have determined it is a known low risk issue. We may make this functional…

Same, September 2018 for me.

> After some internal discussion, we have determined this is a known low risk issue. We may make this functionality more strict in the future, but don't have anything to announce now. As a result, this is not eligible for reward under the Bug Bounty program. Below is a reference to our instructions for users to remove sensitive data from a repository. https://help.github.com/articles/removing-sensitive-data-fro...

Re: Anyone can access deleted and private repository data on GitHub

#380

Post by Shocka1 »

Already__Taken wrote: post #356
hmottestad wrote: post #11

The biggest gotcha here is probably that if you start of with a private repo and a private fork, making the repo public also makes the fork "public". GitHub may very well say that this is working as intended, but if it truly is then you should be forced to make both the repo and fork public at the same time. Essentially "Making repo R public will make the following forks public as well 'My Fork', 'Super secret fork',…

it's a bit of that you have to know the sha, and that's quite unique. it's apparently unique enough for Google photos to "private" share without logins

You only need the short SHA, which is 4 characters. Brute force ends up becoming very easy with 65k possibilities.
Post reply on HN