Banished from Priv15

I was recently called into a new customer’s network to help recover some passwords on some Cisco switches and to map out the network structure. Unfortunately nobody had any idea of the last time the switches had had their configs saved or even when the last time the switches had been power cycled. From what I can gather the previous IT guy didnt leave any information for those who followed.

TIP: Dont do this. It just makes people curse your name!

The problem here was that this network was carrying somewhat sensitive information and any “unplanned outages” would need to be minimised to an appropriate outage window. We did some physical tracing of the equipment connectivity and determined an eligible switch that only had a couple of nodes plugged into it, and no other switches hanging off it (as best we could tell). We scheduled an outage (thankfully it turns out that the middle of the day was actually the best time to do this), and just as we were about to start the first recovery one of the onsite guys found a USB key that just happened to have a very old backup copy of one of the configs. And just my luck the “line vty” password was in clear text! It cant hurt to try this password on the console can it?

WHAM! Unprivileged access. That was almost too easy 😉 A quick check around some of the other switches confirmed the same password on all of them. So I now at least had some form of access to the switches. I still needed to reset the enable secret entry which would require a reboot of the switch to perform, but maybe I would be able to gather some more information about the running state of these switches before a reboot. Maybe I could save myself from all sorts of hell if the configs weren’t saved after the last set changes,.

Now I, like Im sure many of you, spend most of my time on network devices barking my commands from the Ivory Towers of Priv15 land. I’m used to typing commands and having the router or switch go out of its way to provide me with any decadent output I requested! How much could I learn about these switches from the land of the plebs (What is this “>” prompt I see before me?). So I investigate…

“show tech” – OK, so I expected this one to fail, but I had to be sure 🙂

“show run” – This was another I expected to be slammed shut in my face!

“show cdp neighbor” – Not likely, but maybe? – NO CDP FOR YOU!

“show ip int brief” – Yes! First success, and now I know about any active primary IP addresses on this switch (TIP: “show ip int | inc Vlan|Int” provides a really handy output)

“show vlan” – Yes!

“show interface” – Yes

“show interface summary” – A given after the previous entry worked. A good overview though.

“show interface trunk” – Yes, and know I can re-create switch trunks with a little more confidence.

“show interface switchport” – Oh, now this is a good one. Lots of information about each and every port on the switch should I need to rebuild the configs

“show mac address-table” – Handy to know how many devices were coming in over a given interface before the reboot to cross check

“show ip arp” – Much like the previous MAC table

“show ip route” – What sort of routing table layout does this device have? What sources of routes? Static and Connected – any dynamic routes?

“show version” – Now I know how long the device has been online, what version it is running, and any changes to the config-register.

“dir flash: “ – No… but

“show flash:” – This gave me the exact same output that I would have gotten from “dir flash:”, so Im not sure why its not allowed by default.

From the “show flash” and the uptime value from the “show version” output, I was able to reasonably estimate when the config was last saved. Mind you when your switches dont have the clocks set and they think it is 1994 and the file modified date was 1996, you can rest assured the config most likely hasnt been saved since the last reboot!

So I felt pretty happy with myself about being able to get as much information as I reasonably could about these switches. When speaking to Ivan over at IOS Hints, he said that the fact I was able to get that much information from the devices might be worth noting for other people, and possibly used as part of your security measures for increasing the privilege levels required to run these commands on your production equipment if you are so concerned.

My tests here are just a few of the many commands available to non-privileged users, and I would be happy to hear from anyone else with some useful additions to the lists I put together here.

As always comments, flames, fanmail welcome!