Dan Mahoney, System Admin
2013-May-24 00:19 UTC
Utility to scan for unpassworded SSH privkeys?
Hey all, Let's make an assumption: 1) I am a root user on a system. 2) I don't want said system being used as a jumping-off point if either a user account or the root account is compromised. Given an unencrypted private key, plus a known_hosts file, plus bash_history, it's a pretty easy avenue of attack once you're in the front door. And it's happened before*. Thus, what I'd like to do is (in the spirit of crack's "nastygram" script), trawl through user .ssh directories and warn users with insecure keys (or warn root). I'm shocked I can't find something that does this with a basic google search. Debian offers their ssh-vulnkey tool, but that checks for something different (weak RNG-seeded keys). Has anyone come across something like this? Better still, written it? It seems to me that something like this should be in /contrib, but that's just me. My ears are open. -Dan *(http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-security-breach-via-stolen-ssh-key) http://threatpost.com/apache-site-hacked-through-ssh-key-compromise-082809/ -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---------------------------
Effectively nobody passphrases their ssh keys. They're used as a way to *suppress* password entry in the real world -- use this, and things just work rather than poking you each time. Sent from my iPhone On May 23, 2013, at 5:19 PM, "Dan Mahoney, System Admin" <danm at prime.gushi.org> wrote:> Hey all, > > Let's make an assumption: > > 1) I am a root user on a system. > > 2) I don't want said system being used as a jumping-off point if either a user account or the root account is compromised. > > Given an unencrypted private key, plus a known_hosts file, plus bash_history, it's a pretty easy avenue of attack once you're in the front door. And it's happened before*. > > Thus, what I'd like to do is (in the spirit of crack's "nastygram" script), trawl through user .ssh directories and warn users with insecure keys (or warn root). > > I'm shocked I can't find something that does this with a basic google search. Debian offers their ssh-vulnkey tool, but that checks for something different (weak RNG-seeded keys). > > Has anyone come across something like this? Better still, written it? > > It seems to me that something like this should be in /contrib, but that's just me. > > My ears are open. > > -Dan > > *(http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-security-breach-via-stolen-ssh-key) > http://threatpost.com/apache-site-hacked-through-ssh-key-compromise-082809/ > > -- > > --------Dan Mahoney-------- > Techie, Sysadmin, WebGeek > Gushi on efnet/undernet IRC > ICQ: 13735144 AIM: LarpGM > Site: http://www.gushi.org > --------------------------- > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
On Thu, May 23, 2013 at 05:19:52PM -0700, Dan Mahoney, System Admin wrote:> Thus, what I'd like to do is (in the spirit of crack's "nastygram" > script), trawl through user .ssh directories and warn users with > insecure keys (or warn root).The key files are PEM format PKCS#8 and you can use openssl to test whether or not the private keys need a passphrase: $ openssl rsa -in id_rsa_nopass -passin pass: -noout 2>/dev/null ; echo $? 0 $ openssl rsa -in id_rsa_pass -passin pass: -noout 2>/dev/null ; echo $? 1 You can't tell by inspection of the authorized_keys file (it wasn't clear if that's what you wanted). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On May 23, 2013, at 7:19 PM, "Dan Mahoney, System Admin" <danm at prime.gushi.org> wrote:> Hey all, > > Let's make an assumption: > > 1) I am a root user on a system. > > 2) I don't want said system being used as a jumping-off point if either a user account or the root account is compromised. > > Given an unencrypted private key, plus a known_hosts file, plus bash_history, it's a pretty easy avenue of attack once you're in the front door. And it's happened before*. > > Thus, what I'd like to do is (in the spirit of crack's "nastygram" script), trawl through user .ssh directories and warn users with insecure keys (or warn root). > > I'm shocked I can't find something that does this with a basic google search. Debian offers their ssh-vulnkey tool, but that checks for something different (weak RNG-seeded keys). > > Has anyone come across something like this? Better still, written it? > > It seems to me that something like this should be in /contrib, but that's just me. > > My ears are open.Three comments: 1. Set this in /etc/ssh/ssh_config and advocate people use it. HashKnownHosts Indicates that ssh(1) should hash host names and addresses when they are added to ~/.ssh/known_hosts. These hashed names may be used normally by ssh(1) and sshd(8), but they do not reveal iden- tifying information should the file's contents be disclosed. The default is ``no''. Note that existing names and addresses in known hosts files will not be converted automatically, but may be manually hashed using ssh-keygen(1). This stops your "known host" issues. 2. Discourage people from leaving PRIVATE KEYS on your server. The only place they should live is on the user's laptop (hopefully password protected) and encourage good ssh-agent usage (something I always advocate to my users and do myself). This stops people from breaking one ssh account, finding a local exploit and stealing other keys to other people's sites. 3. Encourage (disable offending accounts) people using in their ~/.ssh/authorized_keys files for *EACH* key they place. from="pattern-list" Specifies that in addition to public key authentication, either the canonical name of the remote host or its IP address must be present in the comma-separated list of patterns. See PATTERNS in ssh_config(5) for more information on patterns. In addition to the wildcard matching that may be applied to host- names or addresses, a from stanza may match IP addresses using CIDR address/masklen notation. The purpose of this option is to optionally increase security: public key authentication by itself does not trust the network or name servers or anything (but the key); however, if somebody somehow steals the key, the key permits an intruder to log in from anywhere in the world. This additional option makes using a stolen key more difficult (name servers and/or routers would have to be compromised in addition to just the key). This helps protect against "wandering private key syndrome." As it is locked down a bit more. Personally if I were going to allow my system to be a general shell server for even close friends. I'd have cron jobs disabling, deleting, or otherwise ensuring the the last two are respected. And it would be clearly posted. *shrug* But frankly, I advocate the above three items for years. - Ben
I could be mistaken, but I think Damien was referring to the difficulty of attempting to require encryption on, and passphrases for keys. Regardless of what defaults keygen has, a user could easily decrypt the key, and store it insecurely. Not that this is okay, but that you can only enforce that a key is stored securely at the client, which you can never really trust. So you are always at the mercy of users doing the right thing. It's roughly the same issue as people putting passwords on post-it notes. Sent from my Verizon Wireless 4G LTE Smartphone -------- Original message -------- From: Nico Kadel-Garcia <nkadel at gmail.com> Date: 05/24/2013 10:33 PM (GMT-08:00) To: Damien Miller <djm at mindrot.org> Cc: Jamie Beverly <jamie.beverly at yahoo.com>,Dan Kaminsky <dan at doxpara.com>,"Dan Mahoney, System Admin" <danm at prime.gushi.org>,openssh-unix-dev at mindrot.org Subject: Re: Utility to scan for unpassworded SSH privkeys? On Sat, May 25, 2013 at 12:36 AM, Damien Miller <djm at mindrot.org> wrote:> On Fri, 24 May 2013, Nico Kadel-Garcia wrote: > >> This is not a new flaw. It dates right back to the original SSH-1 and >> SSH-2, which were forked to create OpenSSH. It's also why the highly >> vaunted security of OpenBSD is fairly pointless, when such gaping >> configuration holes are the *default* configuration. ssh-keygen >> creates passphrase frees by default if you simply hit "Enter" a few >> times, and there is no way I've ever seen for ssh_config to reject >> them by default when loading local keys or loading them into an >> ssh-agent. > > If you think it through, what you are asking for is basically impossible > outside of a hugely restricted enviornment (trivial evasion: upload a > custom ssh client that ignores your proposed restriction), and if you > happen to have a hugely restricted environment then you don't need it > to begin with.Damien, I'm sorry, but this is *precisely* the "if you don't trust your environment, you shouldn't be using it" attitude that leads to grossly dangerous default security practices. It's the approach that leads to people having passphrase keys, by default. Even when someone has a secure local physical environment, I find they often model exactly this behavior for people in much less secure environments who have not been better educated. It's also still a dangerous approach for "secure" environments because the passphrase keys are on the local disk, on shared home directories, on backups, or on rooted systems. And I've encountered far, far, far too many admins who use passphrase free keys for remote access to *other* systems, including allegedly "secure" exposed external servers, without bothering with any of the filtering necessary to restrict such risks. I even keep catching Linux and yes, OpenBSD "architects" doing this kind of "keep passphrase free root keys to remote servers lying around"? in NFS accessible homedirs, portable computes, backup tapes, and even sent via email. I've caught roughly..... 20 system admins doing this in the last couple of years, including entire *departments* who "trust the people the work with" and can't be bothered to protect their keys in NFS based envornments, and are *never educated* by their system architects. The attitude of "if I can break your window, you shouldn't be even bothered to lock your car" is an unfortunately common one in the security world. Security can be strongly improved by using layers: improving the defaults to use a m ore secure behavior is a simple step, much as an occasional audit of SSH keys in $HOME/.ssh/ in NFS or other shared environments is invaluable.
On Sat, May 25, 2013 at 6:03 PM, Dan Mahoney <danm at prime.gushi.org> wrote:> Responses inline. > > On May 25, 2013, at 8:06, Nico Kadel-Garcia <nkadel at gmail.com> wrote: > >> On Sat, May 25, 2013 at 7:33 AM, Damien Miller <djm at mindrot.org> wrote: >>> On Sat, 25 May 2013, Nico Kadel-Garcia wrote: >>> >>> Scanning for passwordless keys on a filesystem is fortunately very >>> simple, and does have a real benefit. >> >> Except that it can't scan filesystems on people's disconnected >> laptops, or their local machines that they propage their keys from but >> are in the backup system, nor does it scale well for large >> environments, nor environments that use NFSv4 with Kerberized access, >> nor environments that auto-mount home directories, nor does it >> eliminate the old keys from the backup system, etc., etc. And note >> that a file system scan is next to useless for auto-mounted home >> directories in most NFS automount configurations, since the wildcard >> based mounting of home directories provides no direct hint of what the >> mountpoints might be. > > I'm pretty sure I can run over my NFS server with "find" and "exec" and do what I need to, for any number of users. Which is kind of what any potential person to compromise the system will do anyway.This works only if you have good command access to the NFS server itself. In EMC or NetApp or many larger environments, an admin running a security probe only *rarely* has such access.>> You get the idea. It's possible for users who are being cunning > > ...interesting term considering the problem I initially posited (users being ignorant). Being both cunning and ignorant is a rare occurrence. Or at least I used to think. I've been proven wrong before.It's an incredible education problem.> On the other hand, If you manage to have my machine be an attack vector, because your unencrypted key on your compromised/stolen laptop agent-forwarded through my system, I'll probably forgive you. And be impressed.Through yours? The risk would be mostly if I'm also an admin on your system. And shared admin environments are quite common in large conputing environments, and in univiersities and research environments.> For what it's worth, I'm not against a patch-set that enables ssh-keygen to NOT generate a passwordless key, period. (If you generate one elsewhere and upload it, I can't really help that, but I can scan for it). I'm not even against a patch-set that runs it through some sorts of quality-meters (cracklib? Is that still a thing?) > > On a more evil side, it would be cool if sshd could look for key-based logins that are happening too quickly (indicating no password is being typed), but which do not also attempt to forward an agent -- yes, it's still possible ssh-agent is being used, and just not forwarding, but that's half the point of the agent. There's a possible research paper there for someone, most likely.That.... oooohhh, i *like* it. Not necessarily fail, but simply sending a message to syslog would be helpful for security auditing. It would need to be optional: there are setups like git and Subversion where ssh-agent shouldn't really be forwarded. And forwarding is off by default in ssh_config, so it's of limited use in default environments.> At any rate, I've found what I'm interested in. When I get something nice written up, I may offer it up to stick in /contrib, because I feel such a thing is important. At the very least, I'll push it to a blog. > > All the best. > > -DanIf you can bundle it nicely, how about posting it to github.com ?