[lug] root password

Rob Nagler nagler at bivio.biz
Thu Aug 3 13:03:11 MDT 2006

David L. Anselmi writes:
> No, actually.  If this were true SSH and everything else that uses the 
> RSA/DSA algorithms would be cracked.

You're right.  I meant to say your private keys stored in ~/.ssh/id_*.
You have known_hosts which is where you have gone with ssh, and if you
don't use passwords anywhere, then ~/.ssh/id* has to be where the keys
are, or rather:

    find ~ -mode 600

in the rare event you've stored your private keys somewhere else.

Either way, you've got a small number of files to find, and they can
be found very quickly.  You don't need root access for this exploit,
if your account has been cracked.

You do need root access to crack passwords in /etc/shadow.  It's
infeasible to go through PAM on the local machine to crack MD5.
There's simply not enough time nor compute power.

> It's much easier to crack your password after compromising the remote 
> machine than it is to crack your private key (stored on your 
> laptop)--that's why turning off password authentication is a good
> thing.

I don't think the logic adds up.  I also am not very practiced at this
type of logic so if you don't mind (I'm not trying to be pedantic),
I'm going to reduce your English to a bit of quasi-math.  My model
for security assumes there are walls with locks.  To go through a wall
(access level), you need to find one lock that lets you in.

The "after compromising" means in this model that a "Lock(0:1)" (lock
opens access from access 0 to access 1) has been broken.  You then
need to go through Lock(1:2) to get to root, unless your remote
exploit is a root exploit, which, hopefully, will be rare, that is, if
you hack Apache, it's most likely not a root exploit.  On most
"normally" secure Linux boxes, you need to crack sshd or the kernel IP
routines (ping, for example) to get a root exploit.  However, there is
a possibility for Lock(0:2) which will let you through two walls at
once.  Here's my quasi-equation for the probability of a crack, where
Crack() is the probability function:

CrackA = (Crack(Lock(0:1)) * Crack(Lock(1:2)) + Crack(Lock(0:2))) * Crack(MD5)

To crack your key with a remote exploit, you need:

CrackB = (Crack(Lock(0:1)) + Crack(Lock(0:2))) * Crack(3DES)

That is, you need only crack a single user account or have a root
exploit, to gain access to ~/.ssh/id*.  Private keys are always
encrypted 3DES.  If you assume Crack(3DES) and Crack(MD5) are
equivalent, you can see that CrackA is lower than CrackB, because of
the addition of the Crack(Lock(1:2)) (probabilities ranging from 0 to

There's no guarantee that if you execute CrackA that you can get to
other machines.  If you use a different password on every machine,
CrackA is probably worthless except that you can login normally to the
"open" host without going through Lock(0:1) or Lock(0:2).  Here's the
equation to get to another "inside" (and probably more valuable)

CrackA' = CrackA * (Crack(Lock(0:1) + Crack(Lock(0:2)))

or you could say:

CrackA' = Crack(Lock(0:3))

I mean here that you get to level 3 (the more valuable host on the
inside) with CrackA'.

In the event of CrackB', you have all the necessary information to go
directly to the remote machine.  It's actually worse than that,
because of ssh-agent.  If you are running ssh-agent, then you don't
need to Crack(3DES), i.e., there's a Lock(1:3)':

CrackB' = (Crack(Lock(0:1)) + Crack(Lock(0:2)))
    * (Crack(3DES) + Crack(Lock(1:3)'))

This increases your chances of getting through wall 3 over CrackA'.

Without knowing the values of the various Crack() calls, I'm pretty
sure it can be shown that CrackB' > CrackA' if you run ssh-agent.
And, even if you don't run ssh-agent, you will type a password when
running ssh to decrypt the private key.  Therefore Lock(2:3) is
technically equivalent in CrackA' and CrackB' cases, that is, all you
have to do is put a fake ssh in the cracked account user's path to
gain access to the password to get into the more valuable host.

The above is over-simplified, because it leaves out the concept of
unique passwords/keys for every machine.  The point is that if you
leave a key lying around, it can be cracked more easily than if no key
exists, even if the key itself is very securely encrypted.

Bruce Schneier talks about the known_hosts exploit a bit in:


It's covered in greater detail here:


The bit that's relevant to this dicussion is in here:

    C4 -- Offline dictionary attacks

    After obtaining the password file on a compromised 
    host, an attacker can test candidate passwords against 
    the password file or try to decrypt identity key files in 
    user home directories. While it is likely that an attacker 
    who could access the password file could compromise 
    this account without the password, chances are that the 
    user employs this password to authenticate to other hosts 
    as well. Such offline dictionary attacks also differ from 
    their online counterparts in that the attacker need not 
    run the authentication protocol. This is advantageous 
    because executing a network protocol increases the risk 
    that alarms will be activated and introduces a network 
    delay for each password tested. Once a user?s creden- 
    tials have been compromised, the attacker can use them 
    to gain access to other hosts on which they are accepted.

What I'm advocating is not storing keys, and using a different
password for each access level (wall).  This eliminates the assumption
made that "chances are that the user employes this password to
authenticate to other hosts as well."

By employing a different password (or key), not stored locally, a
breached wall doesn't yield enough information useful for offline
attack.  They may crack all the passwords on the machine, but they
already have access to the machine for which the passwords give you

An offline attack is the only way to feasibly crack modern encryption

There are many online attacks, and one hopes that machines with
valuable data run less software.  Laptops are more easily crackable
than servers, because they are client machines, and run all sorts of
highly vulnerable software, like Firefox, Word, etc.  The probability
of a security hole goes up with the number of processes running on the
machine.  Therefore, you shouldn't keep any keys on a laptop that give
you access to more privileged machines.

You can't stop a worm which sniffs passwords (or passphrases of keys),
but you can stop an offline attack on your credentials by not storing
them online.

> Like you said, security is tricky.

So is email. ;-)  I hope this one is not as convoluded as the last


More information about the LUG mailing list