On Sun, Aug 31, 2025, 14:12 Dan Mahoney via NANOG <[email protected]> wrote:
> > > > On Aug 31, 2025, at 06:43, Tom Beecher <[email protected]> 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/[email protected]/message/OZEXJI3SK2IW45AWFIRQX7TLYXREK3UB/
