Live data from Hacker News

I scanned all of GitHub's "oops commits" for leaked secrets

trufflesecurity.com

81–90 of 117 posts

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#81
post #76
post #20

Earlier quoted context omitted.

The problem here is that GitHub keeps the ref logs even for commits that no longer exist. I don’t see how BFG helps here

it rewrites the history. Isn't that really enough? You can remove all the keys from the git history. and I agree , i forget the point about rotating the key which i do always in first .

It might remove it from your local repo, but not from GitHub, that's the point.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#82
post #8
post #7

An interesting look at one of the consequences of using git and public repo's. Does leave me wondering how long before someone has a setup which detects and tries to exploit these in real-time, which feels like it could be nasty. Also a challenge with these posts is they were unlikely to have been able to contact all the affected developers who have got exposed secrets, meaning that any that were uncontactable/non-re…

There are already people scanning git repos for Bitcoin/Ethereum/crypto keys and exploiting them immediately.

Not just Git either. Push a container to Docker Hub and you'll get instant downloads. Presumably people scanning containers for secrets.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#83
post #64
post #40

Earlier quoted context omitted.

If you rotated the secret, why do anything else? I don't think there is any potential further damage (except maybe reputational).

1. Not all secrets can be rotated. E.g. I can't just "rotate" my home address, which I prefer to be private. 2. Even for rotatable secrets, "I don't think there is any potential further damage" rests on the assumption that the secret is 100% invalidated everywhere. What if there are obscure and/or neglected systems, possibly outside of your control, that still accept that secret? No system is bug-free. If I can take…

> 1. Not all secrets can be rotated. E.g. I can't just "rotate" my home address, which I prefer to be private.

Reporter can sell their current house and move to another home as a workaround

Closing ticket as workaround provided.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#84

Earlier quoted context omitted.

Where is that linked from? I've been using GitHub for years and never heard of this page.

Between "Readme" and "0 stars" on https://github.com/SharonBrizinov/test-oops-commit/ Looking at some of my projects, it's entirely empty, or only has a few items, so I suspect it was introduced "recently" and doesn't have data from before then. Picking https://github.com/jellyfin/jellyfin/activity?sort=ASC as a busy example, Activity page has no data prior to 7th March 2023. So it has existed for 2 of GitHub's 17 ye…

Thank you. I think that section has consisted of links to READMEs and stuff for so long I just stopped paying attention to it.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#85
So the question is: after I orphaned a commit how do I _truly_ make sure it's not visible anywhere on github? Is there no way short of contacting customer support to GC a repo? Shouldn't this just basically be a button on the repo, in the "danger zone" area of the repo maintenance?

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#86

What I've never understood is, how is this an issue with private repos? Aside from open source projects I can't see the problem with accidentally doing this, even though it is a smell.

Different employees in the company have different permissions. If an employee with a lot of access commits a secret, then employees who shouldn't have that much access can take the secret and use it.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#87
post #53

Earlier quoted context omitted.

Anyone who puts weight on digging through a project to see if they've ever leaked a secret is guilty of encouraging an antipattern-- the guaranteed outcome is you'll have an organization petrified of shipping anything, in case someone interprets it as bad or a security risk, etc.

You can see it that way, however, there are automated tools to scan for secrets. Even github does it. In my opinion, this educates the developers to be more careful and slightly more security oriented, rather than afraid of shipping code. I would also like to remind that a leaked AWS secret can cost 100Ks of $ to an organization. And AWS won't help you there. It can literally break your company and get people unemplo…

While I am not suggesting that people should go out and leak their secret keys or push a buffer overflow, the fastest way to learn that you have this problem is by pushing that code to the internet on a project that isn't important. The AWS secret key thing doesn't hold up here, you just really shouldn't do it, but how about an ec2 ssh key or passwords in plaintext? How did I learn about parameterized queries for SQL injection and XML escape vulnerabilities? By waking up to a Russian dude attacking my Java myspace clone.

No amount of internal review and coding standards and etc will catch all of these things. You can only hope that you build the muscle memory to catch most of them, and that muscle memory is forged through being punched in the face

Lastly, any pompous corporate developer making 200k a year or more who claims they've never shipped a vuln and that they write perfect code the first time is just a liar.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#88
post #64
post #40

Earlier quoted context omitted.

If you rotated the secret, why do anything else? I don't think there is any potential further damage (except maybe reputational).

1. Not all secrets can be rotated. E.g. I can't just "rotate" my home address, which I prefer to be private. 2. Even for rotatable secrets, "I don't think there is any potential further damage" rests on the assumption that the secret is 100% invalidated everywhere. What if there are obscure and/or neglected systems, possibly outside of your control, that still accept that secret? No system is bug-free. If I can take…

Also avoids false positives in the future from automated scanners, bounty hunters etc. if you clean up now.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#89
post #53

Earlier quoted context omitted.

You can see it that way, however, there are automated tools to scan for secrets. Even github does it. In my opinion, this educates the developers to be more careful and slightly more security oriented, rather than afraid of shipping code. I would also like to remind that a leaked AWS secret can cost 100Ks of $ to an organization. And AWS won't help you there. It can literally break your company and get people unemplo…

While I am not suggesting that people should go out and leak their secret keys or push a buffer overflow, the fastest way to learn that you have this problem is by pushing that code to the internet on a project that isn't important. The AWS secret key thing doesn't hold up here, you just really shouldn't do it, but how about an ec2 ssh key or passwords in plaintext? How did I learn about parameterized queries for SQL…

> No amount of internal review and coding standards and etc will catch all of these things. You can only hope that you build the muscle memory to catch most of them, and that muscle memory is forged through being punched in the face

Everything you mentioned is security 101, widely known, and can be caught by standard tools. Shrugging that off as a learning experience does not really hold much water in a professional context.

Re: I scanned all of GitHub's "oops commits" for leaked secrets

#90
post #9

Git never forgets, this isn't really a shocking revelation.

Git does forget, it has a gc mechanism specifically for forgetting. GitHub can't use the native git gc, and apparently doesn't have their own fork-aware and weird-cross-repo-merge-aware gc, so they might just not have built a way to track which commits are dangling. But that's not obvious at all.

Ah right, so forking the codebase, then deleting the original repo forces git to forget all copies. Gotcha thanks for the enlightenment.
Post reply on HN