SANS Penetration Testing

Invasion of the Network Snatchers: Part 2

[Editor's Note: In this follow-up article, Tim Medin continues the discussion of pen testing network devices via the Simple Network Management Protocol (SNMP). He provides really helpful hints and tidbits throughout! Please check it out. -Ed.]

By Tim Medin

In our last episode, we attacked network gear via SNMP. We scanned for SNMP-accessible devices. Then, we developed a good, fine-tuned word-list dictionary and used it to guess a valid read-write community string (the "password" that allows access via SNMP). With this community string, we were able to retrieve the configuration from a Cisco device. We have a running configuration... now what? First: PASSWORDS!

With cipher-text password representations in the configuration file, the obvious approach is to crack them to determine the clear-text passwords. But how does Cisco store passwords?

Cisco stores passwords in four ways:

Type 0: This is an unencrypted password, there is no need to crack it.

Type 7: This password is stored with reversible encryption using the Vigenere cipher and the key dsfd;kfoA,.iyewrkldJKDHSUBsgvca69834ncxv9873254k;fg87. There are many online tools to reverse this password, or you can use a local cracker such as ciscocrack by THC. All of these tools will quickly give you the cleartext password by simply reversing the cipher operation.

Type 5: This is a properly hashed and salted MD5 hash and is currently the most secure storage mechanism on Cisco devices. This password type can be attacked with John the Ripper using the raw-md5 format.

Type 4: This is a SHA256 hash, but it is not salted and it only uses one iteration (check out this advisory for details). Sadly, this format is the reason that Type 5 has been deprecated. Newer versions will support Type 4 but not Type 5, thus eliminating salts and making for a less secure approach. This password type is not currently crackable by the stable versions of John the Ripper, but the bleeding-jumbo does support the format.

To extract passwords from the config file we can use grep, like this:

$ grep 'secret\|password\|line\|login\|encryption'

service password-encryption
enable secret 5 $1$X6A6$YyErWuzmkKA9jMm7jURrp2
enable password 7 03275A053F00347E4B081D311F1B18
username billybob password 7 13080E020A1F17
username sallysue secret 5 $1$K9rk$XtLt7Paa9qdW.wJuQB0kR/
line con 0
password 7 0110090A48040A0A314D5D1A0E0A0516
line vty 0 4
login local

You'll notice the configuration above contains "secret" and "password" lines. The "secret" items are stored in a one-way hash format, while the "password" items are stored in a reversible (Type 7) format. "Passwords" are stored this way so they can be used with protocols that require the original password, such as CHAP and ARAP. If both the enable secret and the enable password have been set, the enable secret takes precedence and the enable password will be ignored.

The configuration can also contain local users (see the username lines). If the "line" is setup to use "login local", then the device will require a valid username/password combination for authentication. If the "line" is configured with "login", then it will use the associated line password.

In the example above, the console port (con 0) would require the password "consolepassword" and a Telnet, SSH, or HTTP(S) connection would require authentication via billybob or sallysue and the associated password. But what if the device used TACACS or Radius and we didn't have admin credentials, or what if the device was setup properly with this configuration?

username toughtommy secret 5 $1$7aYI$Lt3sh3UJM20CGfuhnHuXd0
line vty 0 4
login local

This will require that we use Tommy's username and password, but he used a really good password. His password isn't going to crack in our lifetimes. We need another way.

In the last episode, we used SNMP to tell the device to send its configuration to us. We can do something similar to upload a new configuration. The extremely flexible Cain tool on Windows allows us to upload (or download) the configuration from Cisco devices. To invoke this Cain functionality, first click the CCDU (Cisco Config Downloader/Uploader) button on the row of tabs. Then click the + button and enter the target IP address of thee router or other SNMP-managed device and community string. Finally, click OK to download the file. At this point, you have the file and you can view it or edit it for re-upload. It really is that straight-forward with Cain.

To open the file from Cain in a text editor, right click on the file in the center Cain panel and click View. This will open the file in your preferred editor. You can then edit the file to create new configurations to create users, change ACLs, enable services, setup a VPN, or whatever you want, but BE CAREFUL! While you are editing the config file locally, you will later upload this to the router, and will apply the new configuration. If you mess this up, you could take down the network. If the device is using TACACS or Radius, you will see "login authentication somename" so you will need to remove that item to login locally. My edits usually include something like this:

line vty 0 4
no login authentication someword
login local
username tinytim privilege 15 secret MyReallyGreatPassword

This configuration will remove the external authentication and create my account that will drop me straight to the enable (privileged) prompt. Note, this is a secret so it will be hashed once the device receives it, but it will travel to the device in the unencrypted form across TFTP. After uploading and applying this config, we can login to the device, preferably via SSH (or... shudder... telnet if we have to). I'll usually disable logging, if it is allowed by the rules of engagement, by prefixing each of the log related commands with "no" to remove them.

With privilege 15, we will be dropped into the higher privileged Enable Mode prompt immediately upon login. This allows us to make any changes we want. Depending on the device and its location, I like to do one of two things: setup a VPN connection or modify the VLANs to put myself on another network.

At this point, I highly suggest that you get some experience with Cisco devices or find a partner who has that experience. You can do some really cool stuff with the network, but you can also do some really bad stuff. I suggest setting up a lab with come Cisco devices you've purchased from Ebay or virtual devices using the dynagen/dynamips virtual network device environment. Some attacks at this stage take a long description to safely identify and setup. However, changing your VLAN is pretty simple and is less likely to cause damage, so let's delve into that.

First, look closely at the configuration for VLANs with descriptions, VLANs with IP address, interfaces with interesting descriptions and the associated VLAN, and the first and last ports (admins usually keep those for special functions). In our case, let's say we find the following interesting information:

interface vlan 4094
ip address

This is a VLAN on our device with an IP address. It is likely a network management subnet that is completely unmonitored and unfiltered. We can see the devices that are on the same network by pinging the devices on the network. In our case ping reveals something on (likely the upstream router) and nothing at We can use one of those IP addresses for our attacking system when we switch networks. To switch networks we need to find our network port and then move it to the new VLAN.

switch1# show mac address-table | i 00:11:22:33:44:55  # i is short for include, similiar to grep
Vlan Mac Address Port Type
-------- --------------------- ---------- ----------
284 00:11:22:33:44:55 gi8 dynamic
switch1# conf t # enter configuration mode
switch1(config)# int gi8 # configure the port we are connected to
switch1(config-if)# switchport access vlan 4094 # switch my vlan

At this point, we are on the same segment as the switch itself. This will likely allow us access portions of the network that we were unable to access as a normal user with a normal system. We can then change our IP address to and start poking the network. Most of the defenses are protecting traffic into the network management network, not out of it. Have fun!

-Tim Medin
Counter Hack

P.S. If you'd like to learn more about penetration testing in-depth, you can join me as I teach the SANS SEC560: Network Penetration Testing and Ethical Hacking at SANS Boston 2013 | Boston, MA | Mon Aug 5 - Sat Aug 10, 2013. It's going to be a rocking good time, and I'd be happy to see you there!

Post a Comment


* Indicates a required field.