Google Search: Inurl:server Filetype:key “-----BEGIN RSA PRIVATE KEY-----”

Google Search: Inurl:server Filetype:key “-----BEGIN RSA PRIVATE KEY-----”(google.co.uk)

172 points by andygambles 8 years ago | 56 comments

demarq 8 years ago |

Hmmm my idea would be

"Hello from github,

We detected that you uploaded credentials to NAME_OF_REPO. We strongly advise against this as it allows attackers to easily gain unauthorized access to your software and infrastructure.

Have a look at this blog where we discuss alternatives"

EDIT: Just to be clear, I'm not suggesting a ban at all, just a friendly email in response to commits that introduce credentials to public repos

Bromskloss 8 years ago | |

"Hello! This is Github. Look what we found on your server! HAHAHA!"

rangibaby 8 years ago | |

Is there a disadvantage to banning private keys in public repos?

Artemis2 8 years ago | | |

I personally upload private keys in repos for some test scenarios and examples (dummy private keys of course). I often don’t want to write a test harness to generate the data for each run. Sue me!

demarq 8 years ago | | |

Yes, business wise github is a git hosting site. If they started implementing rules on how you structure your application customers would get frustrated and move away.

Just to be clear, I'm not suggesting a ban at all, just a friendly email in response to commits that introduce credentials to public repos

jcranmer 8 years ago | | |

People already mentioned the major use case of testing, but building a blacklist of keys (e.g., the Debian OpenSSL there-are-only-64K-keys fiasco) is a plausible option as well.

tyingq 8 years ago | | |

A fair amount of the google hits are for test certs that allow the test suite for the software to run.

kemitche 8 years ago | | |

Test keys, example keys for documentation, etc.

I'd be all for an optional, branch protection-like feature though.

ATsch 8 years ago | | |

Well, misdetection and examples for one.

demarq 8 years ago | |

Now I think about it there are companies better placed to do this, code climate, codacy et al.

nthcolumn 8 years ago | |

I know you mean well but no charge should be introduced to mitigate against this stupidity. You are (probably correctly) assuming that the data in question is genuine. Nonetheless it is none of our business. rm -rf /* does not contain a warning message and that is the way it should be.

kevhito 8 years ago | | |

Misleading? Because "rm -rf /" does give a warning. From info rm:

  `--preserve-root'
       Fail upon any attempt to remove the root directory, `/', when used
       with the `--recursive' option.  This is the default behavior.

graystevens 8 years ago |

The wonders of the "Googledork". There is a lot of information out there which definitely shouldn't be public: https://www.exploit-db.com/google-hacking-database/

athenot 8 years ago |

It's worth pointing out that some of these are configuation examples, illustrations of how to set something up. (Though of course that carries the risk that less thorough users just copy-paste that into production and call it a day.)

FilterSweep 8 years ago | |

Came here to say this, I have a public "example" repository my clients use for reference that has a "fake" public/private key pair.

gargravarr 8 years ago |

One of the more amusing patterns I spotted in the URLs is where an alarming amount of the filesystem appears to be exposed, e.g.:

www.dulceswilly.com/mysql/BHP_sym/root/usr/local/etc/apache22/server.key

If I was on a non-company IP, I'd be tempted to poke around and see what else is visible...

ryanlol 8 years ago | |

These are already hacked systems where someone has been trying to perform a "symlink attack" to access other users files with the httpds permissions.

edward 8 years ago | |

mysql root password: http://www.dulceswilly.com/mysql/BHP_sym/root/root/.my.cnf

ndury 8 years ago | | |

Too late, "professional" hackers from indonesia already done the job.

Front page reads:

PELITABANGSA .CA [ INDONESIA CYBER ATTACK AND MALWARE ANALYST ]

kuschku 8 years ago |

You should check out how many services have their entire git repo of their service openly accessible (this allows getting the data out of the git objects, as well as the history).

Quite often you can go to domain.tld/.git/ and find the files if you know their names. Even major sites - The Hill only fixed it in the past few days.

gargravarr 8 years ago | |

One of the first things I implemented when setting up a company's webserver was to make .git and below return 404. Making those folders visible is a silly idea on SVN, let alone Git.

gurkendoktor 8 years ago | |

I've also fallen into this trap, thinking that Apache wouldn't serve up any dotfiles. Wouldn't that be a saner default?

akerro 8 years ago | | |

For nginx:

  # block .files
  location ~ /\. {
    deny  all;
  }
  # allow Lets encrypt
  location ~ /.well-known {
    root YOUR LE DIRECTORY
    allow all;
  }

avenoir 8 years ago | |

intext:"index of /.git" reveals a ton of those.

dsacco 8 years ago |

I was a little surprised to see an Apple domain in there, but I can't really tell what the private key was for (could have been a test or an example). It looks like it's either an outdated result or an Apple engineer quickly saw this and fixed it because the page 404s now.

joshuatalb 8 years ago | |

Assuming we're talking about the same link here, I can still access it:

https://opensource.apple.com/source/tcl/tcl-87/tcl_ext/tclli...

blubb-fish 8 years ago |

that yields just 7 pages (10 items each) so it's probably pretty irrelevant.

but of course you are welcome to share your run of the mill anecdotes about some intern once accidentally publishing passwords - etc. :)

camiller 8 years ago | |

For me the top of the first page said about 1160 results. Still a surprisingly small number of hits.

zeep 8 years ago | | |

That's because Google always inflates result numbers, until you get to the last page... for me, that last page is 5 and there is 46 results.

dzhiurgis 8 years ago |

Slightly related question about API keys that rely on referer (say Google Vision) - what stops me using curl to spoof referer and rake in thousands in someone’s bill (15 cents per 1k recognitions)?

I assume there’s some IP based quota, but I haven’t seen a knob for that on GCP at least.

zitterbewegung 8 years ago | |

This should be enforced on your server and you shouldn’t have clients directly connecting to a service like Google Vision. I have a system that uses AWS lambda so that I don’t have to distribute my 3rd party API keys but I still have to add rate limiting.

dzhiurgis 8 years ago | | |

You are missing my point entirely.

spydum 8 years ago | |

typically APIs can implement rate limits at various levels. Your IP may get throttled when they see it trip over an individual referrers quota.

clarkey252 8 years ago |

Can someone explain why the inurl:server is used? Wouldn't this also work without that (and reveal more results where the keyfile has been renamed)

andygambles 8 years ago | |

I used inurl:server to restrict the results to mainly just server.key files so revealing the private keys of HTTPS websites.

Of course you can remove it. Just means more results to wade through.

dangerface 8 years ago | |

More results does not necessarily mean better results. They probably got more specific to remove references to documentation and such.

Another interesting thing about google is that this search may return results that are not found without the inurl:server

gargravarr 8 years ago | |

At a guess, this is to filter out SSH keys, which have an identical private key format, and we well know already how many of those get committed to GitHub. I think this is to highlight where the server's HTTPS key is visible.

nullandvoid 8 years ago | |

I'm curious also as i'm getting 5x the amount of results excluding the inurl name filter

andygambles 8 years ago |

Some of the results are web servers leaking the private keys of the website or in some cases mail servers.

devy 8 years ago |

The sixth link from the Google result, https://jpl-vmdb03.inetuhosted.net/sjsuvc.drivingcreative.co...,

Is that the JPL I thought it was?

ktta 8 years ago | |

If you mean Jet Propulsion Lab, then no way. I'm sure they're better than that.

The IP block is managed by INetU Inc, which was apparently a cloud hosting company now owned by Canadian telecommunications company Shaw Communications.

https://whois.arin.net/rest/poc/II25-ARIN

https://www.crunchbase.com/organization/inetu-managed-hostin...

https://www.crunchbase.com/organization/shaw-communications

luord 8 years ago |

This I pure paranoia fuel. I don't think I've done this (or what someone else mentioned about leaving the .git folder open in the server) but I'll double check anyway.

stonewhite 8 years ago |

I am definitely making this a part of regular security scan.

dingo_bat 8 years ago |

It took me about 15 seconds to understand. WTF! Why are people uploading their private keys to github?!

cr0sh 8 years ago | |

Most of the ones I saw in github looked to be test or demo keys; not anything real.

The better question are those actual non-github sites that have them exposed (though others here have noted that those sites may already be hacked).

bonoetmalo 8 years ago |

Google lost its mind when I clicked this link. Signed me out, turned on SafeSearch and threw up some privacy notice dialog at the top of the page.

blojayble 8 years ago | |

Because it's google.co.uk, not the one you usually use.

bonoetmalo 8 years ago | | |

Interesting. Weird response to something that doesn't seem that rare, like someone linking you to the mobile version of a page, just linking you to a different Google culture.