Cooking up a half-baked bad idea involving ssh keys | Hacker News Reader

Cooking up a half-baked bad idea involving ssh keys

rachelbythebay.com

45 pointsonosendai46 comments

This is really silly. The end-game is a coarse geolocation? Most people use real names on Github, or freely discuss their locality on Reddit... You don't even need the ssh keys (or the honeypot!) to tie a username to a specific area.

Seriously, if you can design a honeypot that can convince programmers to log in with SSH, maybe you should just launch a Start-up.

>Most people use real names on Github, or freely discuss their locality on Reddit...

Maybe most, but not all. It isn't an issue for everyone, but that doesn't mean it isn't an issue at all.

>Seriously, if you can design a honeypot that can convince programmers to log in with SSH, maybe you should just launch a Start-up.

There is a big difference between a site that sparks intellectual curiosity and a site that inspires someone to actually pay money.

Yeah this is really silly. But it was obvious from the get-to when the writer didn't understand the "public" is "public key"

Ridiculous. You might as well "honeypot" the Internet by encouraging people to mail a letter to you. Now you have their mailing address because it's the return address on the envelope!!!

A lot of the comments here are along the lines of "My identity is public anyway."

That response is ridiculous. Should you have been operating under a pseudonym, this would be a way to tie that pseudonym to your real name.

I should be told that my public keys are made available by Github. Had I been, I wouldn't have had a public key on my account.

How can you tie a public key to a real name? What information does a public key leak?

By comparing the indexed public keys with github accounts. Should a user have both a pseudonymous account and an account tied to his or her real name, this would compromise the identity of the pseudonymous account.

Edit: To be clear, this would only work if the same public key was used for both accounts.

If the target used the same public key elsewhere, that ties two accounts to the same person, which may or may not help figure out who that person is.

Or you could have a separate public key that you use only for Github, e.g. by using IdentitiesOnly and IndentityFile settings in ~/.ssh/config.

If I ever knew this, I'd long forgotten it. Thank you.

Honestly, the fact that they're called "public keys" at all should clue you in to the fact that they can be made available. The concept doesn't work if they aren't made available.

Better idea: check which of those keys are in the Debian Weak SSH Keys list and own their GitHub accounts (or find if they have any servers and start SSHing into them).

Less nefariously: send them an email asking to regenerate the key.

Or, for the RSA keys your find, calculate the GCD of each key with all others and see if any badly generated private keys fall out.

GitHub already did that:

> Thanks to our new servers, known bad keys from Debian and Ubuntu are now blacklisted. We estimate that about 1000 keys in our database were impacted by this. If you get authentication errors using keys that worked a day ago, please double-check that they are not on our blacklist. If they are, you should ensure your software is updated and generate new keys. We’ve got a guide to help you out with this.

https://github.com/blog/500-state-of-the-hub-rackspace-day-0

This made me think - It would be kind of awesome to have contest or show of extremely convoluted Rube Goldberg style systems to obtain run of the mill targeting data.

My entry would be to mass import everyones commit logs and use a machine learning alg to find gaps that correspond to popular broadcast television shows.

My neighbour has a squeaky toilet roll dispenser in their bathroom, which I can hear through my bedroom wall. Thanks to this, I'm convinced I can sell my knowledge of poop-frequency to someone. A hardware store? Insurance company? I don't know, but there is profit to be made here.

All users' public ssh keys are also available through the API:

http://developer.github.com/v3/users/keys/

It seems mostly harmless, but I'm not sure I see the point of making this information available.

It sounds like a handy way to let everyone with push access to your project also have a login to a build VM you host.

Exactly. Travis CI uses this to let you ssh into your build VM.

One real (but unlikely) issue is if people are careless; comparing public keys could reveal identities that are normally hidden.

more efficient solution: read the public location info in people's github profiles.

Half-baked is right. If I can't trust my public key to be safely available to the public, I might as well just give up and go home.

There's perhaps a meta-hack here on how to get to HN front page (albeit on a sunday) with a fairly silly "hack" idea.

If the idea is to demonstrate leaky personally identifying material I'm surprised that your scraping of usernames results in only a list of usernames, and not a big database of different usernames, and fora, and projects, and interconnections.

That kind of data mining would probably be reasonably scary.

I'm not sure I understood the rest of it. The site rachelbythebay.com would have a public key for Bob from github, and try to get Bob to log in using his private key?

If I wanted to be part of the data-mining game, I would have stayed at Google when they set course for creeperville and engaged at warp 8. I don't, so this is just a half-baked bad idea.

Seriously though, remember the whole "We found X... is this your Twitter account?" thing which appeared on the search results for some people back in 2011? Are they still that brazen about the internal shadow profiles?

Is it trivially possible to determine the public key based on an SSH authentication attempt (without knowing the private key)? If not, then does it not make it less secure to broadcast it?

While maybe this is "okay" for github to publish, they run a security-sensitive service and hidden API surprises like this could give some folks the impression that they don't take security seriously enough.

So, half-baked ideas are the topic, right?

Turn the idea on its head: Find a way to use SSH based authentication for services and allow people to connect with their GitHub account, find a clever way to map AuthorizedKeysFile (via fuse or something) to https://github.com/%u.key (yeah, won't directly work that way of course).

I think you could hack this up in an afternoon with PAM, but is PAM even distributed with modern Linux distributions? I thought I read somewhere that its un-loved and doomed.

PAM is indeed still how authentication on Linux works.

Some Linuxes. Slackware doesn't use it. I think Debian Stable still does. AKAICT, most people hate it.

Distro, do you even PAM ?

You're right. Slackware doesn't. They're notable for that, and I don't think any other mainstream distribution (if Slackware even counts as that) excludes it.

At least in the multi-user environments I manage, PAM works well, and we maintain some custom PAM modules to do things like handle unpaid accounts with warnings then lockout.

It's a little complex but I don't know of any viable alternative -- setting up Kerberos on Slackware is a big pain last I checked. Maybe not relevant to single user machines, but that's not the context we're talking about here.

I thought the point of public keys was to BE public.

I'm pretty sure you can find my location from any number of other things, such as geotagged photos I post, so this doesn't seem like such a terrible intrusion. Not to mention that "log in to this server, we already have your public key set up and ready" isn't exactly inviting.

So combine it with a man-in-the-middle attack to make the victim think he's logging into a known server (hmm, they changed the server key, ok).

Disclaimer: I don't really know what I'm talking about.

A simpler method and probably just as effective is to ask ... I'm in Boalsburg, PA. The reality is that you can't do much with my public key other than giving me permissions, which I'm free to use or ignore. If I lose my private keys, I'm going to be scrambling!

You can try factoring it.

If you collect a large amount of keys you can use algorithms to find common divisors anywhere in the set, and so make it easier to find easily factorable keys out of a big population.

is that true? are there efficient factoring algorithms that scale better than linearly when given many products?

i realise that just enumerating products would scale well, but is that how efficient factoring schemes work?

or am i misunderstanding?

It relies on there being common factors somewhere between any keys in a big set. That should only happen through a very small chance or through random-generation weaknesses. The point is that it's easy to spot it if there are keys with those weaknesses. This CCC talk is related to this: http://events.ccc.de/congress/2012/Fahrplan/events/5275.en.h...

Since ssh keys are user-submitted, we will have diversity and a chance of some subset of keys which weren't generated safely.

EDITED TO ADD: Bad CCC site, it doesn't link to the FactHacks slides: http://www.hyperelliptic.org/tanja/vortraege/facthacks-29C3....

oh thanks for the edit - also found this https://www.youtube.com/watch?v=IuSnY_O8DqQ and am watching now.

and the above tactic starts at 11m in. huh; and it's just euclid - a non-unity gcd means two keys (products) have a shared prime (and you get one of the primes).

edit: also, "batch number field sieve" is the answer to my original question.

I went digging to figure out how I came up with this loopy notion, and it brought me right back to HN. It looks like the seed was planted back on the 4th when I saw this post:

https://news.ycombinator.com/item?id=5495982

Basically, I saw that and went "wait, how does it get the key?", went digging, and found the keys endpoint. The rest evolved from there.

This doesn't make any sense. You could just mail out links to each person and get the same data (IP, geolocation). Usernames themselves leak much more info.

This post has received quite a lot of negativity but I think there's an interesting idea behind it. Whilst it may not be a privacy or security risk, imagine how creepy it would be to connect to a server to see a project or whatever, only to be greeted by your name, job, location, etc. Until you figured out how it was done, it would be quite concerning.

There are people who re-use their github key?

I don't think there are that many anonymous githubs accounts out there. Feel free to prove me wrong though.

Github's key system has you upload a public key. If I already have an SSH key generated, I'm more likely to use that than to generate a new key, set up my .ssh/config file to conditionally use that key when connecting to github.com, etc.

I tend to use a key per machine for ease of revocation, so yes.

The real trick would be to convince them to log into your server using ssh -A and then pwn their github accounts. :)

Reply on news.ycombinator.com