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

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

trufflesecurity.com

Post reply on HN
Print view View original

71–80 of 117 posts

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

#71

Post by lqet »

UnreachableCode wrote: post #27

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.

Many years ago at my first job after university, I accidentally committed a private key into our internal Git repository. We removed it, because we could not completely rule out the possibility that this repository would be made public to a customer, or to the world, in the future. I think we used filter-repo to get the key out of everywhere.

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

#72

Post by xlii »

Probably worth mentioning that force is a ref-related activity not a snapshot related activity. Garbage collection might remove unreferenced commits.

This should be done through history rewrites but as other commenters mention - GitHub has its own rights (and GitHub != git).

I’d recommend looking at simpler alternatives. IMO Jujutsu is mature enough for daily usages, and Fossil is a neat alternative if one wants to drop GitHub completely (albeit not very easy to use).

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

#73

Post by raesene9 »

matsemann wrote: post #11
raesene9 wrote: 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 hundred of setups like that already. If you push an AWS key or similar publicly you may have a bitcoin miner or botnet running on your cloud in matter of minutes.

The point here being the blog is about looking for oops commits to spot keys that would otherwise not necessarily be picked up automatically...

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

#74

Post by v3ss0n »

GrandaPanda wrote: post #28
v3ss0n wrote: post #18

Daily reminder: - Once it is on the internet - it is always there so Rotate the key/secrets FIRST. - Never think secrets are gone because of you have recommited . - Deleting a commit is not enough , use BFG Cleaner - https://rtyley.github.io/bfg-repo-cleaner/ , and force commit to change history. Edit- Forget to add most important thing - rotating the key.

Had it correct in the first two points, then contradicted yourself with the last. Rotate your secrets.

Yeah good point. Rotating secrets is a point i forget to add.

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

#75

Post by raesene9 »

hboon wrote: post #8
raesene9 wrote: 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.

There's a lot of secret classes that aren't necessarily automatically scanned for. The Oops commit is a good signal that something shouldn't have been committed, even if automated scanners don't get it.

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

#76

Post by v3ss0n »

hnlmorg wrote: post #20
v3ss0n wrote: post #18

Daily reminder: - Once it is on the internet - it is always there so Rotate the key/secrets FIRST. - Never think secrets are gone because of you have recommited . - Deleting a commit is not enough , use BFG Cleaner - https://rtyley.github.io/bfg-repo-cleaner/ , and force commit to change history. Edit- Forget to add most important thing - rotating the key.

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 .

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

#77

Post by xlii »

Arainach wrote: post #48
ramon156 wrote: post #43

Earlier quoted context omitted.

If I'm honest, I don't know how much this happens at work, and even if it does it's not the end of the world. Just scratch the commit from existence. In my head, the people who accidentally share secrets are also the people who couldn't setup trufflehog with a precommit.

This isn't true in practice. Even among well educated high performing professionals, mistakes happen. Checklists save lives - in medicine, in aircraft maintenance, in all fields. People who believe they know what they're doing get overconfident, move fast, and make mistakes. Seasoned woodworkers lose fingers. Experienced doctors lose patients to preventable mistakes. Senior developers wipe the prod database or make a…

Aye.

I made shameful mistake of submitting private key (development one so harmless) only because it wasn’t gitignored and prehook script crashed without deleting it). More of a political/audit problem than a real one.

I guess I’m old enough to remember Murphy Laws and the one saying "safety system upon failure will bring protected system down first".

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

#78

Post by bashwizard »

NoahZuniga wrote: post #2

I find it hard to believe that they could have made $25k with this. There are companies that scan all commits on gh for secrets, using similar techniques for finding secrets in files.

I'm surprised that it's not more. I couple of years ago I spent a few months basically github dorking for leaked api keys and made more than that.

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

#79

Post by emmelaich »

Pwhy1 wrote: post #21

Maybe I missed it but the article doesn't mention the even easier way to see this: the activity tab. It has everything. Any force push to hide ugly prototype code is kept forever which annoys me. I wish we were able to remove stuff from there but the only way to do it is to email support it seems? Here it is for the test repo mentioned https://github.com/SharonBrizinov/test-oops-commit/activity

I guess it's possible to delete these forever as by deleting the entire repo and re uploading. As long as there are no forks.

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

#80

Post by emmelaich »

Cthulhu_ wrote: post #37
edverma2 wrote: post #23

All devs should run open-source trufflehog as a precommit hook for all repositories on their local system. It’s not a foolproof solution, but it’s a small time investment to get set up and gives me reasonable assurance that I will not accidentally commit a secret. I’m unsure why this is not more widely considered standard practice.

Pre-commit hooks are client-side only and opt-in; I've always been a big proponent of pre-commit hooks, as the sooner you find an issue the cheaper it is to fix, but over time pre-commit hooks that e.g. run unit tests tend to take longer and longer, and some people want to do rapid-fire commits instead of being a bit more thoughtful about it.

One good (and obviously bad) thing about Subversion was the ability to change history. As admin I was asked numerous times to change a commit message. To point to the correct Jira issue, for instance.

Also easier to enforce pre-commit, since it was done server side.

Post reply on HN