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/