When I configured this Cisco router (IOS version 15.0(1)M5) with dynamic dns, it failed to properly update its public IP address on the dynamic dns site. Turning on debugging (debug ip ddns update) revealed an authentication issue:
*Jan 20 22:53:55.591: HTTPDNSUPD: DATA START badauth
A simple test confirmed what I suspected: IOS truncates the password. In can’t be longer than 15 characters.
Here’s the config of my test, with username test and a 20 character password:
And here’s what the web server receives:
The password received by the webserver is 0123456789abcde. In other words, IOS has truncated the password to the first 15 characters and included it in headers of the http(s) GET request that updates the dynamic dns info.
It’s possible that the username also gets truncated to 15 characters, however I’ve not tested this.
The Cisco bug ID is CSCtx50249.
Do you need to analyze a Cisco IOS Core Dump?
“But that doesn’t explain how to analyze a core dump“, you say? Correct, unfortunately. That’s all you get with SOPA/PIPA enacted.
“But SOPA blackout day” was yesterday, you say? Correct. But I’m not following the crowd
Did you ever had to identify a Cisco IOS image when you couldn’t rely on the filename?
Look for strings starting with CW_ between strings CW_BEGIN and CW_END in the image file, for example like this:
You will find strings like CW_IMAGE, CW_FAMILY, CW_FEATURE, CW_VERSION, CW_MEDIA, CW_SYSDESCR and CW_MAGIC between strings CW_BEGIN and CW_END.
In this example, the IOS version is 12.4(6)T5 (CW_VERSION) and it is designed to run on 870 routers (CW_FAMILY).
The nice thing about these CW_ strings is that you will also find them in a core dump (in the data region), thus allowing you to identify the IOS version that was running on a router when the core dump was produced (provided the image runs from RAM, indicated by a letter m in the filename).
And they are also present in the uncompressed image (compressed image files are identified by a letter z in the filename).
Soon I will release a tool to validate IOS image files, you can use it to extract these CW_ strings too.
I’m sure some of you verify SSH fingerprints before you use a SSH server for the first time. You obtain the fingerprint via another channel, and you compare it with the fingerprint your SSH client presents you.
But have you done this with Cisco devices too? Recently I tried to obtain the SSH fingerprint of a Cisco router while connected via the serial console. Turns out there is no CLI command to display the fingerprint (well, at least I didn’t find one). What you can do, is dump the public key with command “show crypto key mypubkey rsa”.
So I developed a small Python program that calculates a SSH fingerprint from the public key. You store the public key in hex format in a file and use that with this new tool.
To calculate the fingerprint, I extract the modulus and exponent from the public key, store them in another format (ssh-rsa) and calculate the MD5 hash.
So now I can connect to a router via the serial console while there’s no “man in the middle”, obtain the public key and calculate the fingerprint. Next when I connect to the same router over SSH, I can validate the fingerprint my SSH client presents me. It’s too bad Cisco provides no feature to get the fingerprint directly.