Live data from Hacker News

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

trufflesecurity.com

11–20 of 117 posts

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

#11
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.

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

#12

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.

this is specifically deleted commits, which even if locally are deleted, are not so on GH, hence why he was able to find deleted .envs etc.

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

#13
post #6

Maybe a default secure delete option could be made a lower bar event? Checkout to event, commit in clean state with prior log history, overlay the state after the elision and replace git repo? When I had to retain log and elide state I did things like this in RCS. Getting date/time info right was tricky.

If you push a secret publicly, you should consider it leaked. On GitHub, you have 5 minutes on a non-watched repository (due to the delay) and less than 30 seconds on a watched repository to revoke it before it's been cloned and archived by a third-party. Whether that party is malicious or not, rewriting the Git history will not change anything that the secret is leaked. And you can already rewrite the Git History and garbage collect commits that aren't part of the tree anymore on most providers.

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

#14
post #6

Maybe a default secure delete option could be made a lower bar event? Checkout to event, commit in clean state with prior log history, overlay the state after the elision and replace git repo? When I had to retain log and elide state I did things like this in RCS. Getting date/time info right was tricky.

If something got out to the internet, you won't get it back. There is little point in rewriting repo history if you have already made a secret public. Just change the secret as soon as you can.

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

#15
post #13
post #6

Maybe a default secure delete option could be made a lower bar event? Checkout to event, commit in clean state with prior log history, overlay the state after the elision and replace git repo? When I had to retain log and elide state I did things like this in RCS. Getting date/time info right was tricky.

If you push a secret publicly, you should consider it leaked. On GitHub, you have 5 minutes on a non-watched repository (due to the delay) and less than 30 seconds on a watched repository to revoke it before it's been cloned and archived by a third-party. Whether that party is malicious or not, rewriting the Git history will not change anything that the secret is leaked. And you can already rewrite the Git History an…

Yes I can see my off-line experience doesn't apply. Thanks.

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

#16

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.

"70% of secrets leaked in 2022 remain valid today"[1] is a quote that should help understand the situation.

[1] https://blog.gitguardian.com/the-state-of-secrets-sprawl-202...

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

#17
post #14
post #6

Maybe a default secure delete option could be made a lower bar event? Checkout to event, commit in clean state with prior log history, overlay the state after the elision and replace git repo? When I had to retain log and elide state I did things like this in RCS. Getting date/time info right was tricky.

If something got out to the internet, you won't get it back. There is little point in rewriting repo history if you have already made a secret public. Just change the secret as soon as you can.

The person who leaked it and the person/team that can rotate it might be in different silos or timezones etc. Rewriting the history is prudent but not sufficient.

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

#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.

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

#19
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.

How to make git an elephant: https://donatstudios.com/yagni-git-gc

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

#20
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

Post reply on HN