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

Hmmm my idea would be<p>&quot;Hello from github,<p>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.<p>Have a look at this blog where we discuss alternatives&quot;<p>EDIT: Just to be clear, I&#x27;m not suggesting a ban at all, just a friendly email in response to commits that introduce credentials to public repos

The wonders of the &quot;Googledork&quot;. There is a lot of information out there which definitely shouldn&#x27;t be public: <a href="https:&#x2F;&#x2F;www.exploit-db.com&#x2F;google-hacking-database&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.exploit-db.com&#x2F;google-hacking-database&#x2F;</a>

It&#x27;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.)

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.:<p>www.dulceswilly.com&#x2F;mysql&#x2F;BHP_sym&#x2F;root&#x2F;usr&#x2F;local&#x2F;etc&#x2F;apache22&#x2F;server.key<p>If I was on a non-company IP, I&#x27;d be tempted to poke around and see what else is visible...

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).<p>Quite often you can go to domain.tld&#x2F;.git&#x2F; and find the files if you know their names. Even major sites - The Hill only fixed it in the past few days.

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

that yields just 7 pages (10 items each) so it&#x27;s probably pretty irrelevant.<p>but of course you are welcome to share your run of the mill anecdotes about some intern once accidentally publishing passwords - etc. :)

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)?<p>I assume there’s some IP based quota, but I haven’t seen a knob for that on GCP at least.

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

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

The sixth link from the Google result, <a href="https:&#x2F;&#x2F;jpl-vmdb03.inetuhosted.net&#x2F;sjsuvc.drivingcreative.com&#x2F;server.key" rel="nofollow">https:&#x2F;&#x2F;jpl-vmdb03.inetuhosted.net&#x2F;sjsuvc.drivingcreative.co...</a>,<p>Is that the JPL I thought it was?

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

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

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

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.