Like This Blog 0

Added by Mark Jacob March 31, 2014

In a previous blog, I discussed OSPF authentication. In that blog, I covered the configuration of simple password protection. At the end of that blog I mentioned that the password when using this method is sent across the wire in clear text. Let us use that fact to our advantage as we delve into part two of discovering secret OSPF information in Cisco routers. Part 1 covered how to obtain the area ID from a neighboring router. This blog will explore the ease with which a simple password can be pulled off the wire, without so much as a packet sniffer in sight. Let’s begin by observing the network diagram.

LEFT router has simple password authentication configured on F0/0. The objective is to log in to the console of RIGHT router and determine the password in use, configure our side to match, and create an adjacency between the two routers. We will have administrative power on RIGHT, but we are not permitted to access LEFT router. Let’s begin.

First, let’s see how close we are to success in our current configuration.

So we are already running OSPF – that’s one less thing to cross off our list. Let’s check the status of this OSPF process.

One of the pieces of information that was given to us is that LEFT router is already running simple (plain-text) authentication. We see from the above output that RIGHT router is not participating in authentication and the status in Inactive. Let’s see what it takes to snag that secret password while accessing only RIGHT router. The first step is to configure an extended access-list that watches for the information we want, which is hello packets (addressed to the multicast address 224.0.0.5). It looks like this:

Now to craft the debug command which will expose the information we seek. The command is debug ip packet detail 150 dump

Focus your attention on the received (rcvd) hello packet. Within the raw dump to the screen is the plain-text password we seek. (It is on two lines, so follow the word-wrap to get it all.) We believe the password is secretid. Let’s try configuring it on our side. If it is correct, our neighbor relationship should spring up shortly after we configure it.

How about that? No WireShark and we captured everything we needed to get our router to speak the correct password on its OSPF interface. Not so difficult at all. It also shows the importance of avoiding plain-text password authentication and using the stronger md5 option supported by OSPF.

Some of the debug tricks are pretty cool and occasionally can come in handy on your certification exams by allowing you to extract seemingly secret information. Just think, someday you can be a great debugger! While that may not sound so impressive, the result most certainly is!

Until next time, debug away…when it is safe to do so, of course.

Mark Jacob
Cisco Instructor – Interface Technical Training
Phoenix, AZ