Re: beware: being old sucks

[brent saner via NANOG <nanog () lists nanog org>]

On Sun, Aug 31, 2025, 14:12 Dan Mahoney via NANOG <nanog () lists nanog org>
wrote:

> > On Aug 31, 2025, at 06:43, Tom Beecher <beecher () beecher cc> wrote:
> >
> > Dan-
> >
> > This paragraph is important to unpack.
> >
> > [snip]
> > Close , but not quite. The fingerprints are used *to identify which
> public key to use* for the challenge/response.
> > The actual public key is still stored and used for the auth process; it
> can't work otherwise. Just because the CLI only shows you the fingerprints
> doesn't mean anything.
>
> I do not believe that to be the case.

Aye; in a *proper* SSH implementation it would be a fast *identification*
for a  lookup of a key.

But that doesn't seem to be what's happening here, as you've pointed out,
which is pretty significant, because...


> If it were, why does copying the same hash to a different router/switch
> cause it to let you in?  (I tested this, and say as much.)

This happens. Which seems to be a suretell sign that IOS appears to
indeed be authenticating only on the *MD5 fingerprint* of the key.
Which would reduce an RSA 1024 key's strength, *laughably weak* in today's
standards, to a fixed space of *only 16  bytes/128 bits* (the length of an
MD5 hash) instead of 128 bytes/1024 bits.
That's a difference of *1048576* combinations versus *16384*. The
difference, of course, is more stark with stronger keys (for instance, RSA
4096: 16777216 vs 16384)

MD5 is very broken. To my knowledge there hasn't been a preimage attack
found on MD5 (that's public) but it is theorized[0]. However, If IOS
accepts an arbitrary public key blob of *any* length and does no length
validation, that's a pop- you'd just need a *collision* for that, not a
preimage. If that's the case, all the attacker needs to do is hack together
a(n admittedly very broken) RSA implementation on their end. *Collisions* in
MD5 are very easy and can take seconds. *Preimage* is where it's (for now)
theoretical.

I haven't done much peeking into the SSH protocol itself -- I'm *much* more
familiar with the keys[1] -- but I suspect this isn't the only deviation
from RFC 4253 et. al. IOS makes.


> I call out RFC 4252 section 7 here for a reason, it specifies that what’s
> transmitted is referred to as a “binary blob”, which is later broken down
> into the components in 4253 Section 6.6.  What’s transmitted for RSA keys
> is the modulus (i.e your semiprime) and e (your exponent), which is
> effectively the entire public key, less the comment field.

*Technically* the ordering is e/n in the public key and n/e in the private
key for RSA, at least in the OpenSSHv1 private key format. I forget which
order the older style ASN.1/PEM has for the private.


> And because it needs to be an md5 hash of the product of two prime
> numbers, it’s not like one can just pad random binary data in there to
> affect the hash.

They don't HAVE to be prime... ;) They SHOULD be, but if someone were
crafting a key for an exploint, they don't care. (And servers don't care
either; I don't think I know of any that do any sieves during the key auth.)


> I say that much in the paper, but I call out what could have been done
> differently, as well:
>
> * Vendor could have stored the whole key, and not just given you the
> illusion it was being stored.
> * Vendor could have placed limitations on allowable key length.
> * Vendor could have updated the signature alg.
> * Vendor could have advised the use of a key only for this purpose.
>
> Is it likely that someone’s still using a weak key from that long ago?
> God I hope not, but we’re still using 8 inch floppies in our nuclear
> arsenal and still have ATMs running WIndows XP, so I wouldn’t be shocked if
> some key were buried in some provisioning system somewhere.

I guarantee someone somewhere is using a Debian-borked SSH key still.


> Anyway, my point was that in light of Randy’s recently posted
> vulnerabilites, that any key that you might have used for pubkey auth into
> *any* device here should probably be retired, and that if for some reason
> pubkey is part of your workflow, you should probably generate and use a key
> *only* for that purpose, and not your general purpose id_rsa.pub.  At the
> very least, one should think about how this is different from every other
> system out there.

I'd argue the *key* is fine; it's moreso how IOS does the key auth that
needs to be fixed. Regen'ing a key doesn't help terribly much here if the
key verification process on the SSH server itself is broken, unfortunately.

[0] https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability has the
sources, I don't think they're published online.
[1] With published notes! https://sshref.dev/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/OZEXJI3SK2IW45AWFIRQX7TLYXREK3UB/