Regarding Pubkey Enumeration

[Nico Kadel-Garcia]

On Mon, Jan 23, 2012 at 7:32 AM, Aris Adamantiadis <aris at 0xbadc0de.be> wrote:
> Le 21/01/12 01:13, Ángel González a écrit :
>> Suppose that there is a page critizising a technologic company, which
>> suspects
>> it's run by one of its multiple employees. The company could test the
>> server with
>> the public keys of their employees until it finds one that matches. Even
>> if he used
>> a different public key, the company server could fetch keys not copied
>> to it from the
>> user agents to find it out (this assumes the username is known and
>> IdentitiesOnly
>> wasn't set).
>
> I don't understand the big deal with that "attack" (which as Damien told
> was already obvious to anyone having SSH experience). The scenario
> you're providing is far, far etched and gives no advantages to other
> techniques (like studying the network usage logs of that employee,
> seeing that he often connects to remotes hosts in SSH).
> You would only catch the guys who don't connect from their office, but
> still have their ssh public key on their company computer (why ?)

Hardly. Logs that are sophisticated enough, and go back far enough, to
pin SSH traffic to a particular external host from a particular
identifiable client are awkward to maintain. They're also unreliable
in a DHCP based network setup, since especially for laptops that go
home, the IP addresses are likely to change from day to day for
employee machines and would have to be cross-correlated with the DHCP
logs.

> When you're in a pentest environment, and all you have is a public key,
> a user name and an IP address + a hint that the three match together,
> you're not *that* much advanced. Passwords can be bruteforced, not
> private keys.

Many private keys are poorly passphrase protected. Since the default
behavior of ssh-keygen allows passphrase free keys, there are one
*hell* of a lot of people who don't bother and make the common
assumption "if someone has access to my network, I have much bigger
problems" and refuse to provide any passphrase protection. (I've been
encountering that problem since the original ssh-1 was published, and
it's particularly egregious for Subversion svn+ssh users.)

Every time I audit for passphrase free keys, I tend to catch at least
20% of the private keys being used without passphrase, even in NFS
based environments. It's an ongoing problem. Even among those that are
protected, far too many have the same password as the login password,
which is often accessible by other means. (I just went through that
problem with someone storing their username and password in autofs
mounting tables for CIFS.)

> Moreover, I find strange that nobody ever complained that openssh client
> leaks the whole list of your available public keys to every server you
> try to connect to, even if you don't complete authentication.

Does it? I thought it went down the list one at a time, hadn't looked
at that chunk of the code in..... well, it's been a long time.

Potential confusion about which key to use is why I like to use the
'Host" option in $HOME/.ssh/config. It lets me select a login key
versus a Subversion svn+ssh access key, for example, for specific
servers.