Many years ago I got a trial license key for something, Aspose components of some sorts I think, and without thinking of it, checked it in into public Github repo. Well, few days later Aspose's support sends me a nicely worded note saying that they noticed that it was there and invalidated it for me. Their description and instructions were very clear about why they did it and why I shouldn't have checked it in. I thought that was very proactive and excellent customer service.
I actually had something similar happen to me last month. I accidentally published a discord API key to GitHub and within minutes I got a nice message from “Safety Jim” to my personal discord account letting me know they’ve found my key on a public repo and have gone ahead and revoked it.
I felt like a bit of a dope but it was neat to have it happen to me. Lesson learned for sure.
GitHub PM here. Glad that was a good experience! We work with ~50 partners (details in the link below) to notify them when tokens for their service are exposed in public repos, so that they can notify you.
Great that they finally do that. I accidentally checked one into a public GitHub repo a long time ago and about 2 years later someone found it. The infinite spam wasn't even the worst part about this, bajillion emojis in every message just caused the Discord client to crash instantly upon opening, so I couldn't even figure out what's happening at first.
I’ve had this happen to me too! No less than a second after pushing to GitHub did I receive a message about publicizing my auth key. It was amazing, and I’m sure this saves a lot of stolen keys from people just getting into programming
In fact, you can apply as a Github "secret scanning partner" to have your own secret's format (regexp) be a part of this secret scanning, with a webhook to your servers whenever they find one, so that you can do the credential-invalidation on your own backend + send the kindly-worded email from your own domain.
Mind you, your secrets need to have a distinctive format in order for this to work. Probably a distinctive prefix is enough.
An Unethical Life Pro-Tip (that the word is already out on anyway, so I don't feel too bad):
• For about $500, you can use BigQuery to extract all matches of a particular regexp, from every file, in every commit, in every public Github repo.
Whether or not Github themselves use this to power their secret scanning, arbitrary third parties (benevolent or not) certainly can use it for such. And likely already do.
I worked for a big startup last year and was on a contract deadline for integrating a vendor framework into a React Native app.
It was taking too long to get a new temp demo license key and GitHub search with clever filters helped me track down a demo key that was recently uploaded to a test repo.
Hah. Yeah. Found a bunch of ssh keys, passwords, etc for Comcast years back which turned into a shitshow when I tried to report it. Once I found the right people to talk to things got better, but the entire experience was really reflective of how bad large orgs are with security.
A friend once told me he was having a hard time getting a client to take his security concerns seriously. So I went on github and found a commit in their repo that included a production password and sent it to him. Maybe took 5-10 minutes to find? Apparently once they found out about the commit, they panicked a bit and started taking his concerns more seriously.
Old school one when I was a security consultant for a bit (pre-automated pentest scammers). Medium size regulated fintech. Domain admin passwords and admin accounts were stuck on post it notes on a board in the machine room. If you went over the road to the college, asked to use the toilet, which they seemed fine with, and poked your 200mm lens out of the bathroom window you could snap them all.
Don't assume that level of competence improved with addition of technology.
Did some consulting for an org that did managed IT and found that they wrote on a white board all of their passwords. Wrote them an email basically telling them "hey maybe you should erase that". May or may not have billed them for the time it took to write that email.
They put a piece of paper over the passwords in response.
Yikes. It is sad to hear stories like that, where security is not a concern until panic sets in. :(
Yet another reason we need to adopt standards like security.txt and make it easy to report these things as it is to tell robots to ignore us with robots.txt. See securitytxt.org for more on the project.
It's tough. I'm our public security reporting email list.
We get a lot of things that boil down to "When I go to your website, I am able to see the content of your html files!" ... yes, reporter. That is what a web server does. It gives you HTML files. Congrats that you have figure out the dev console on your browser, but you're not a hacker. I'm trying to go with Hanlon's razor here and assume this is inexperienced people and not outright scams.
We don't get a lot of these, but they far outweigh actual credible reports. But we try our best and take everything seriously until it can get disproven. And it's exhausting. So I get it sometimes. Sometimes having a place for responsible disclosure just opens yourself up to doing more paperwork (verifying that the fake reports are fake). That said, we still do it.
I think the fundamental problem is, a lot of orgs just don't care about security, as it doesn't affect their bottom-line. Even breaches are only a temporary hit on the PR. Proper way to address that might just be legislation, with heavy fines based on total revenue.
That and also security is just hard to scale. That's why if it was mandated by legislation, companies would be forced to spend a comparable amount on scaling their security teams and efforts.
Most respectable services will have an abuse@ address you can contact. They should at least be able to get your issues where they need to go internally. I've had very good results for companies and networks in the US.
I've never had an outright bad experience reporting a security issue, but some companies definitely aren't geared up to handle reports. I found that an energy provider's API would give usage information for past addresses and eventually I think the right team got told, but it was a nightmare trying to find someone to actually report the issue to.
It's hit and miss. Sometimes they want to throw you under the bus. Sometimes they want you to sign affidavits. I've never been asked to sign an NDA or anything like that. Sometimes they threaten with criminal charges. DoJ recently released some guidance about good-faith security reporting, so it might be easier these days. Doubt that affects active litigation/prosecution or vindictive orgs, though.
Worked at a place where they liked to use encrypted Java prop files... with the passwords hard coded in the app (in the same repo). Those were internal repositories, though.
The access model on platforms like GitHub is flawed, a single account can be used for both professional and personal projects/repositories, leading to “fat finger” errors like this one here...
Oh yes this. It's so easy to critically fuck up an invite into an organisation. If you get typo the username you are potentially compromised. I've seen a couple of near misses on this already.
Note: the invite input box actually autocompletes ALL github usernames.
The fact that no one bats an eye that GitHub is used to store proprietary source code is so surprising to me.
Conversely if that is what it is meant for, why does it default to autocompleting to all users globally instead of my org (even on the enterprise version.) why hasn’t this been fixed for years.
Do you have a source that this is a "fat finger" error?
I've had contractors publish my code to public Github repos to showcase their work for their next job. Even after emailing them multiple times, I kept finding my code in github with companies emailing me asking for a referral to this person...
This. I used to use them, because I, too, have been burned by my own mistakes before. However, I had to stop using them as a plugin for GitHub because (at least when I was looking) there doesn't seem to be a way to exclude private repos from the reporting, and there were some false positives in private repos I don't want flagged. But I think the service is a good idea in general.
Ah. I can’t believe this still happens in this day of age. About a decade ago, I was working for a startup and we were getting dominated in our growing space by a much larger, well funded rival. Our competitive intelligence team browsed through their git, and the rival actually exposed access to their customer, pricing and sales agent database by leaving their credentials in one of their branches. The team went to our legal department asking if they can be protected by the company, and if they can use this intel. The team then worked with the product team to integrate all their pricing engines to our POS to undercut their pricing and sent marketing blasts to their leads with targeted marketing campaigns. Long story short that company is now defunct, and it definitely undermined their growth.
If you're in the US, that's 100% a crime. If they were responding to an unauthenticated API or web request that's one thing, but using a leaked password on a database is not legal at all.
> Git is an awesome version control system, used by over 93% of developers, and is at the heart of modern CI/CD pipelines. One of the benefits of Git is that everyone has a complete copy of the project they are working on.
I feel like this is copy-pasted from a pitch deck on why GitGuardian should be funded. Does anyone reading the article care about this anecdote? Like do people stop reading at "well I'm one of the 7% that doesn't" or think "wow a lot of people are using Git, I should buy their thing"?
Sorry for the meta comment, but it just stuck out as odd to me.
Well, GitGuardian is free for individual developers (20 K of them use it - n°1 app on GitHub market place) and for team below 25. So I guess the masses can enjoy secrets free code! https://github.com/marketplace/gitguardian
Most of these (even sometimes expensive) tools only look at repos and users who are associated with the company’s GitHub org, which barely solves the problem. The much harder problem is the number of corporate secrets that are on random repositories (personal dotfiles, automations, data science scripts, etc.) across GitHub with no strong relationship to the organization. Try using GitHub Code Search to find all the Fastly API tokens that have been leaked, for example, and I bet you’d find some wild stuff.
I felt like a bit of a dope but it was neat to have it happen to me. Lesson learned for sure.
https://docs.github.com/en/code-security/secret-scanning/sec...
Mind you, your secrets need to have a distinctive format in order for this to work. Probably a distinctive prefix is enough.
An Unethical Life Pro-Tip (that the word is already out on anyway, so I don't feel too bad):
• The content of Github public repos is all continuously loaded (by Github themselves) as a public dataset into BigQuery — https://console.cloud.google.com/marketplace/details/github/....
• For about $500, you can use BigQuery to extract all matches of a particular regexp, from every file, in every commit, in every public Github repo.
Whether or not Github themselves use this to power their secret scanning, arbitrary third parties (benevolent or not) certainly can use it for such. And likely already do.
It was taking too long to get a new temp demo license key and GitHub search with clever filters helped me track down a demo key that was recently uploaded to a test repo.
This is also why I use git-secrets in my repos.
https://github.com/awslabs/git-secrets
Deleted Comment
A friend once told me he was having a hard time getting a client to take his security concerns seriously. So I went on github and found a commit in their repo that included a production password and sent it to him. Maybe took 5-10 minutes to find? Apparently once they found out about the commit, they panicked a bit and started taking his concerns more seriously.
Old school one when I was a security consultant for a bit (pre-automated pentest scammers). Medium size regulated fintech. Domain admin passwords and admin accounts were stuck on post it notes on a board in the machine room. If you went over the road to the college, asked to use the toilet, which they seemed fine with, and poked your 200mm lens out of the bathroom window you could snap them all.
Don't assume that level of competence improved with addition of technology.
At least, until you have a network-attached webcam pointed at your whiteboard.
But the solution to the webcam problem is to write its access credentials on your whiteboard, thus forming a circular and perfectly secure loop.
Did some consulting for an org that did managed IT and found that they wrote on a white board all of their passwords. Wrote them an email basically telling them "hey maybe you should erase that". May or may not have billed them for the time it took to write that email.
They put a piece of paper over the passwords in response.
My current manager is delightfully paranoid about security, so maybe I'll do it again to see if he says anything.
Yet another reason we need to adopt standards like security.txt and make it easy to report these things as it is to tell robots to ignore us with robots.txt. See securitytxt.org for more on the project.
We get a lot of things that boil down to "When I go to your website, I am able to see the content of your html files!" ... yes, reporter. That is what a web server does. It gives you HTML files. Congrats that you have figure out the dev console on your browser, but you're not a hacker. I'm trying to go with Hanlon's razor here and assume this is inexperienced people and not outright scams.
We don't get a lot of these, but they far outweigh actual credible reports. But we try our best and take everything seriously until it can get disproven. And it's exhausting. So I get it sometimes. Sometimes having a place for responsible disclosure just opens yourself up to doing more paperwork (verifying that the fake reports are fake). That said, we still do it.
That and also security is just hard to scale. That's why if it was mandated by legislation, companies would be forced to spend a comparable amount on scaling their security teams and efforts.
Note: the invite input box actually autocompletes ALL github usernames.
If the target user hasn't added their corp email to their profile then they can't be part of the org.
I'm sorry, but that's wild. That's like, not even an easy engineering problem to solve necessarily, given their size!
Though it would still allow "collaborators" which don't have SSO requirement.
The fact that no one bats an eye that GitHub is used to store proprietary source code is so surprising to me. Conversely if that is what it is meant for, why does it default to autocompleting to all users globally instead of my org (even on the enterprise version.) why hasn’t this been fixed for years.
Deleted Comment
I've had contractors publish my code to public Github repos to showcase their work for their next job. Even after emailing them multiple times, I kept finding my code in github with companies emailing me asking for a referral to this person...
You cannot access org's repos without VPN
if you create a new repo by mistake outside your org, then uhh..., it's crazy?
it's like sending email with credentials to people outside your org
I feel like this is copy-pasted from a pitch deck on why GitGuardian should be funded. Does anyone reading the article care about this anecdote? Like do people stop reading at "well I'm one of the 7% that doesn't" or think "wow a lot of people are using Git, I should buy their thing"?
Sorry for the meta comment, but it just stuck out as odd to me.
https://gitleaks.io/products
We need to get PII as a liability on companies’ balance sheets to get them to take it seriously and to collect only the minim viable data.
> customer identification numbers and emails
to provide service? Seriously?