7 ms·
View leaked secrets in Git live
- adamparsons 7y agoThis is highly amusing. One of the first things it found was a publicly accessible oracle db. Second thing it found was someone attempting to make an authoritative repo on standards for django, which included this all-too-familiar line in settings.py # SECURITY WARNING: keep the secret key used in production secret! SECRET_KEY = '(d5%@h=u0m2a5-$4f^n(d%4mkt-@f1%h#3n64%+wmhf(kmx)ga'
- cbkeller 7y agoLeaving the tab open for a half hour turned up about five of those, a google oauth key, and what seemed to be an SSL certificate private key, among others.
- tialaramex 7y agoIf you find "real" SSL private keys (from the Web PKI, ie they would be trusted by something like a web browser out of the box) you should be able to get a CA to revoke any certificates issued for that key by proving you know the key. The usual format of private keys makes it mechanically trivial to get the corresponding public key back and then you can ask a public monitor like crt.sh to determine if that key is seen in any certificates. Once you identify one or more certificates, you can ask the issuer to revoke them, offering proof you know the private key as the reason. For Let's Encrypt or any CA offering the ACME protocol you can use the ACME protocol to do this without involving any humans (the Certbot software for example has a "revoke" keyword that can do this). Other CAs should have at least an email address manned 24/7 to respond to problems, which can explain how they'd prefer you prove you know the key. Or if you're just bored of this and want them to shut up and fix it, you could just email them the private key, whereupon now _they_ know the key for someone else's certificate they issued and that's prohibited by the rules they're working under so it's now their problem.
- souterrain 7y agoSounds like a value-add for a CA. “We’ve seen your private key in public, we’re revoking your certificate for you. You’re most welcome.”
- usr1106 7y agoAnd we sell you a new one :)
- Doxin 7y agoTo be fair, you should be using a separate settings file for production anyways and having a secret key defined for development is incredibly convenient. Personally I tend to set the secret key to something obviously insecure though so people don't get the idea that it's okay to use the same key in production.
- dancek 7y agoBlog post about shhgit: https://darkport.co.uk/blog/ahh-shhgit!/ https://darkport.co.uk/blog/ahh-shhgit!/
- solidasparagus 7y agoI have to say I'm not a huge fan of making secret theft more convenient. I don't see many positive uses for this website...
- fastball 7y agoRaise awareness that developers need to stop doing this.
- ahje 7y agoThis. It's the same reason full disclosure works; it forces people to do better.
- solidasparagus 7y agoIt doesn't feel like full disclosure is really the right policy here. It almost certainly makes more sense to give the person some time to clean up the secret before publicizing the secrets.
- akerl_ 7y agoAttackers can (and are) already pulling the same data sources that power this. Whether or not this site delays/obfuscates the exposed secrets, that doesn’t stop attackers.
- eitland 7y agoMany people feel full disclosure is never the right policy, and if we listened to them I'm afraid we would be worse off. It has done a lot of good though even though I prefer something like project zero where vendors a given some limited time before the information gets disclosed. As for this, I'm afraid one of the first results will be that the repo services shuts down the firehose access, which I think is bad. (I think I can see a number of other ways to improve the security that would work better than that.)
- 7y ago
- jsilence 7y agoWhat are recommended tools for team wide secret management?
- endymi0n 7y agoWe‘re using gopass ( https://www.gopass.pw https://www.gopass.pw )
- janikvonrotz 7y agoBtw. this is a go implementation of pass https://www.passwordstore.org/ https://www.passwordstore.org/
- rapnie 7y agoThe git repo [0] says "All Rights Reverse Engineered" at the bottom. Is that just a joke, or has it actual meaning? [0] https://git.zx2c4.com/password-store/ https://git.zx2c4.com/password-store/
- janikvonrotz 7y agoFor small teams use keybase https://keybase.io/ https://keybase.io/ for gpg key management and pass https://www.passwordstore.org/ https://www.passwordstore.org/ to manage secrets.
- Kovah 7y agoI can recommend using Ansible Vaults, and 1Password in addition to that. Ansible is quite helpful because all project secrets are stored in the local vault which is actually version controlled. The password for the vault can be found in 1Password.
- tialaramex 7y agoAlthough suggestions in this sub-thread are good, prioritise reducing shared secrets first. You can't eliminate them from most projects today, but try not to have more than you need. Use public key crypto in more places so that systems can ask "Was one of these authorised public keys able to authenticate?" (that list of keys isn't a secret) rather than "Was one of these secret passwords used?" For something like all of the engineering group need access to the same test account in your production system: Consider whether some customers might want to share access to an account too ("Disney Global Team" definitely wants this and even "Sally Smith" might if Sally's entourage of agents, managers and assistants are handling a famous person's "personal" account) -- and so add a feature for each of those engineers to have their own login credentials for the account instead of a shared secret, then it reduces to a secret management problem for individual engineers. While considering secret management also give a thought to HR termination checklists. Maybe sharing a single password is easier than building new shared account features for the product, but what happens when somebody leaves for their dream job? Gonna just trust that they won't tell? That's not a sustainable plan.
- happppy 7y agoGot this message in alert Failed to retrieve signatures! Reloading...
- sleavey 7y agoMe too. I lock down Firefox pretty hard so it's probably some cookie or JavaScript being blocked.
- alacombe 7y agoI can't run this in the background more than 5 minutes without getting high CPU usage and and unresponsive tab :-(
- wczekalski 7y agoThis tool should create issues in relevant repos unless the repo whitelists itself explicitly. Or alternatively just create one master issue per repo (should there be more violations in the future)
- shaki-dora 7y agoI believe GitHub strongly discourages automatic issues and PRs.
- ryannevius 7y agoThe tool has a flag icon which will open a new issue in the repo. I've seen a few false positives while watching, so auto-opening issues would be an issue.
- wczekalski 7y agoI feel like it's better to err on the safe side.
- dwild 7y agoYou don't want to flood github with wrong issue, that's a good way to lose the right to open issue altogether.
- djvdorp 7y agoRather link: https://darkport.co.uk/blog/ahh-shhgit!/ https://darkport.co.uk/blog/ahh-shhgit!/ The service is currently overloaded.
- slawwwc 7y agoNice tool. Is there a similar tool that you can use privately to notify you before you commit sensitive data to git?
- spydum 7y agoLike git-secrets? It’s mentioned on the site.
- darkport 7y agoAuthor here. I released the tool a few weeks back and since downsized the EC2 instance. So this post pretty much killed the box. I've just up-sized it again but it's still running fairly slowly due to high load. It typically finds around 5 secrets/a second. Corresponding blog post here: https://darkport.co.uk/blog/ahh-shhgit!/ https://darkport.co.uk/blog/ahh-shhgit!/ and you can run your own instance here: https://github.com/eth0izzle/shhgit https://github.com/eth0izzle/shhgit
- thepoet 7y agoWe created a static version of this (almost similar to shodan but for keys) using publicly accessible Github dump hosted on Google Cloud in 2017. We then hosted the processed data, website and our search infra on AWS. AWS security team reached out to us for a potential “collaboration” and asked us to send all AWS keys that we discovered and we sent them the whole list. As a tiny startup, we were elated. Few days later they call us and threaten with a cease and desist notice if we do not take down the website. Remember we are not targeting AWS keys, neither are we in violation of any licensing agreements with respect to the data. We refused to shut it down. They then ask us to stop hosting it on AWS or “anywhere” else since we were using AWS credits to host the product or they will shut our account. When their this strategy did not work out, they contacted someone at Stripe who had given us the AWS credits, who then asked us to take it down or face consequences. We eventually had to shut it down since we did not have a lot of money to fight these people. It was a stressful week for us where we learnt that corporates can lie and bully you to get whatever they want and then can shut you down. Unless you have the means to fight back. Does not matter where you live.
- verroq 7y agoI know this sounds a bit mean but what did you expect to happen when you host a page of leaked aws keys?
- thepoet 7y agoIt included high entropy strings including keys from 30+ API and service providers, one of which was AWS. We did not target AWS specifically. None of the other services complained. In fact, a customer service widget company even took our help and thanked us. AWS tricked us in taking our findings and then changed their tone.