Chapter 4: Profiling and Enumerating Cisco Networks

Target network enumeration and host fingerprinting are crucial parts of both legitimate penetration testing and a hacking attack. You cannot go on the offensive without detailed terrain mapping and target reconnaissance. A great deal of information on how to use common enumeration and fingerprinting tools such as ping, traceroute, whois, dig, host, and various portscanners ( especially Fyodor's Nmap) is already available in previous Hacking Exposed volumes and elsewhere. In this chapter and the following, we concentrate on something entirely different, including googling for router, firewall, and switch configuration files; Border Gateway Protocol (BGPv4) queries and autonomous systems enumeration; dissecting routing and certain data link protocols to gather data about the network; and precise fingerprinting of Cisco devices with various settings. This makes this chapter more of a research paper than a typical book section, since no one has put together the data presented here before now.

ONLINE SEARCHING AND "CISCO GOOGLEDORKS"

A unique difference between a Cisco router or switch and a traditional server or workstation is that the router or switch configuration file has it all in one place. Someone who managed to retrieve such a file has obtained nearly complete information about the device to which this file belongs. This information includes (but is not limited to) the following:

• Login and enable passwords, which can be plaintext, encrypted with Cisco service password-encryption password 7 (which takes a few seconds to cracksee Chapter 9), or Cisco implementation of the MD5 hash (more difficult to crack, but there are dictionary attacks and good old bruteforce)

• Legitimate login usernames

• Simple Network Management Protocol (SNMP) communities

• Addresses of Trivial File Transfer Protocol (TFTP), File Transfer Protocol (FTP), or Remote Copy Protocol (RCP) servers from which the router grabs its configuration files or operating system

• Whether a web server is running or not and its authentication type

• Interface types, IP addresses, and netmasks

• Network address translation (NAT) settings

• Access lists, packet filtering, and intrusion detection system (IDS) rules

• Logging settings, including the presence of log timestamps and IP addresses of remote syslog servers

• Static routes and routing protocols configuration, including routing updates authentication

• Other protocols supported by the router or switchfor example, Hot Standby Routing Protocol (HSRP)

• Services running on the router or switch

• Dialer maps and phone numbers the device can dial

• Voice over Internet Protocol (VoIP) settings

In the worst-case scenario, an attacker would be able to obtain or break the login and enable passwords and take over the device. In the best case, he or she would be able to find out the IP range of the network and identify potential vulnerabilities and misconfigurations on the routerfor example, letting through directed broadcast and strict/loose source IP options traffic or supporting Internet Control Message Protocol (ICMP) redirects. Both scenarios are rather unpleasant for the network's administration and allow an attacker to enumerate or even access the network resources without firing a single packet directly at the target from the cracker's host.

So, how do the complete or partial router and switch configuration files end up in the public domain, and how does one find them? Based on the works of Johnny Long, author of The Google Hacker's Guide , the term googledork has become a commonplace label for security-illiterate system administrators leaking out sensitive data that can be discovered using Google. Long's web site contains a single googledorks database entry for finding vulnerable Cisco routers, namely http://www.johnny.ihackstuff.com/index.php?module=prodreviews&func=showcontent&id=50 . We have used The Google Hacker's Guide and other of Long's works, such as his presentation at Black Hat 2004 (see http://www.johnny.ihackstuff.com/security/premium/BH2004FINAL.htm ), to search for data that allows the enumeration of networks with Cisco routers and switches deployed and, in some cases, retrieves router configuration files and passwords.

Basic Searching

Popularity:	10
Simplicity:	10
Impact:	7
Risk Rating:	9

We looked at strings specific for Cisco router configuration files. One such string is " no service single-slot-reload-enable ", which is supposed to disable single line card reloading for the line cards in Cisco 7500 series routers. Surprisingly, this string appears to be common in many router configuration files, not only Cisco 7500. At the moment of writing, this search gave us 1630 entries, the majority of which were router configuration files.

Of course, we want the files with router passwords. A search for something like " enable password " or even " enable secret 5 " (MD5 hash) or " enable secret 7 " (password 7 Cisco encryption) gives many configuration files and file fragments , but it also gives many "false positives"for example, descriptions of how to set up a password on a router. Thus, it makes sense to combine these strings with " no service single-slot-reload-enable "and, voila, 125 entries, with the majority of them being router configuration files. Of course, you can use a variety of router access passwords and relevant search strings, such as " ip ftp password 7 " and " key-string 7 " (keys for routing updates authentication). You are invited to find more interesting strings like this (hintdialer map passwords, VOIP credentials) and try them out in different combinations with other strings mentioned in this chapter.

Alternatively, you can look for well-known SNMP communities. While read-only (RO) SNMP communities are useful for device enumeration, the read-write (RW) communities found are just as good as a known enable password. The search strings to consider are " snmp-server community secret RW ", " snmp-server community private RW ", " snmp-server community public RW " (yes, there are "system administrators" who do that!), and their less exciting RO equivalents. You would get a few true gems and many false positives, and the search for Catalyst switches equivalents of these commands (for example, " snmp community read-write private ") would not be particularly fruitful.

How about looking for configuration files containing a defined password? The most common default Cisco router password is, surprisingly, " cisco, " So it makes perfect sense to look for strings such as " enable password cisco ", " enable secret 7 05080F1C2243 ", " ip ftp password 7 05080F1C2243 ", " key-string 7 05080F1C2243 ", or just the encrypted password (65 entries for " 05080F1C2243 " at the moment of writing).

You cannot search for the password MD5 hash generated by the enable secret command, since a protective mechanism randomizes hash generation each time it is done, even if the same password string is used.

Try out more common plaintext and encrypted passwords (generated by your router to be sure that the ciphertext is correct)for example " secret ", " password ", and " cisco1 ". Something as simple as plaintext " enable password cisco1 " gave us 75 Google entries as this sentence was written!

Any other interesting router configuration strings to search for? Sure! How about " ip host tftp "? This string would allow you to discover IP addresses of TFTP servers on which router configuration files and IOS images are stored. If the TFTP server is externally accessible (yes, we saw these on the Internet), an attacker would try to retrieve the configuration files from the server by logging in and guessing the config name . This is not difficult to do, since TFTP is a passwordless protocol. (Common conventions for Cisco router and switch configuration filenames are described in Chapter 6.)

Finally, here's a simple string that we really like: " Automatically created by Cisco ConfigMaker ". Cisco ConfigMaker is an easy-to-use Microsoft Windows application used to configure a small network of Cisco devices from a single PC without requiring knowledge of Cisco IOS commands. Thus, there is a high chance that its users can misconfigure a routerfor example, use easy-to-guess or plaintext passwords. " Automatically created by Cisco ConfigMaker " is a telltale string that indicates how the router config came into existence. The config header would look similar to this:

 ! ******************************************************************      ! Cisco1721.cfg Cisco router configuration file      ! Automatically created by Cisco ConfigMaker v2.6 Build 6      ! 29. september 2003, 04:39:12      !      ! Hostname: Cisco1721      ! Model: 1721      ! ****************************************************************** 

At the moment of writing, we have found 44 configuration files generated by Cisco ConfigMaker on the Internet.

Searching Using Google Operators

Attack 

Popularity:	9
Simplicity:	9
Impact:	9
Risk Rating:	9

The main problem with googling for plain strings from router or switch configuration files is the large amount of "false positives" such as manuals on how to configure a router. Defining a file type as .cfg helps us to separate the wheat from the chaff and center on the Cisco configuration files exclusively.

The most general search query of this type is filetype:cfg intext:router . This will discover a vast variety of interesting configuration files related to routers (not, obviously, Cisco routers). To zero in on what you really want, searches using queries such as filetype:cfg intext:Cisco , filetype:cfg intext:enable password , filetype:cfg intext:enable secret , filetype:cfg intext:Cisco intext: public@ (or any other common SNMP community), and filetype:cfg intext:Automatically created by Cisco ConfigMaker can be done and lead to a few dozen Cisco device configs found. However, a Cisco configuration filename doesn't have to end with .cfg . Of the other possible config extension searches, only the filetype: config intext:enable secret string search proved useful, discovering two Cisco router configuration files. The problem is that Google has a defined set of filename extensions you can search for using the filetype: operator , and common Cisco router config filename endings do not conform to this set.

To bypass this problem, we successfully used the inurl: operator searching for strings; here are some examples:

 inurl:router-confg      inurl:-cfg intext:"enable password"      inurl:-confg intext:enable password      inurl:-config intext:"enable password"      inurl:-cfg intext:"enable secret"      inurl:-confg intext:enable secret      inurl:-confg intext:"enable secret" 

The inurl: operator can also be used to find TFTP directories with Cisco configs shared from the misconfigured web server. While these are not that abundant on the Internet, we did get a few of them by looking for inurl:tftp intext:snmp-server , inurl:tftp intext:enable-password , and similar strings.

Finally, if you did try a general filetype:cfg intext:router search, you have probably noticed a large amount of mrtg.cfg and similar files. It appears that many system administrators freely present Multi Router Traffic Grapher (MRTG) data to the public domain, including MRTG configuration files. Of course, MRTG configuration files are not router or switch configs. Nevertheless, they do provide a wealth of useful fingerprinting data about routers and other hosts that the MRTG daemon monitors . For example, a typical mrtg.cfg file will disclose the following:

• Device type

• IOS or CatOS version

• Administrative contact and router location

• Device interfaces types, speed, IP and MAC addresses

• RO SNMP community on the device (usually "public")

This saves you a lot of time and effort needed to establish these parameters using traditional host fingerprinting tools. To look specifically for various MRTG files that contain Cisco-relevant information, use search strings such as inurl:mrtg intext: Cisco or inurl:mrtg intext:Cisco intext:public@ . Enjoy the colorful router/ switch traffic analysis and CPU load graphs together with other useful MRTG-related information mentioned above!

Googling for Enable

Attack 

Popularity:	5
Simplicity:	9
Impact:	10
Risk Rating:	8

This is the ultimate challenge. Can a hacker get enable on a Cisco router or switch just by using a web browser and omitting cracking passwords found in the public domain configuration files? The answer is "Yes, but only in a very few cases." Apparently, some Cisco routers and switches with misconfigured open administrative web servers dump you straight to enable. Admittedly, we saw only a couple of such devices, but things are changing and perhaps more of these could be found by the time this book hits the shelves (though, frankly, we hope there will be less). Earlier, as we discussed Johnny Long's web site, we mentioned a search string that could be used to find wide- open Cisco devices like that ( inurl: tech-support inurl:show Cisco ). Other possibilities that we have discovered, tested , and prefer to use are " Configure and monitor QoS through the web interface. ", allinurl: " /level/15/ " exec and intitle:/level/15/ exec /- . Happy Cisco googledorking!

Note 

We would be surprised if you managed to break into more than a dozen Cisco routers using Google, since the majority of Cisco configuration files found through Google are partially sanitized, contain expired passwords, contain private range (RFC 1918) IP addresses, or contain IPs well firewalled from outside access. Of course, the authors of this book do not endorse this kind of "Google script- kiddie " behavior. Nevertheless, this chapter is about Cisco devices, networks fingerprinting, and enumeration, and from this standpoint, the data you can obtain from a rather simple web search is invaluable.

Countermeasures: How Not to Become a Cisco Googledork

Countermeasure 

To provide appropriate countermeasures against the online creatures armed with Google, we must analyze how sensitive data, such as router configs, ends up in a public domain. A few avenues allow this to happen. One such avenue is newbie system administrators trying to get some help by publishing their routers' and switches' unsanitized or badly sanitized configs to newsgroups and advice boards such as http://www.experts-exchange.com/ . Think hard before deciding to post your router' or switch' configuration file to some technical help/discussion group or site. If you have no choice and still consider doing that, post only the relevant parts of the config, carefully removing all sensitive information before posting. This sensitive information is not restricted to usernames and passwordstake care to eliminate all SNMP communities, IP addresses, host and domain names , access lists, dial numbers, routing domains, and other sensitive information. Don't give away anything that can attract attackers to your network.

Some examples of badly sanitized Cisco configuration files we have seen posted to the Internet included cases of

• MD5 hash of the enable password left in the config, probably because it was considered to be uncrackable, but it fails to the dictionary attack using John the

  Ripper.

• The passwords are removed, but the RW SNMP community is still there.

• The passwords and SNMP communities are removed, but an IP of the externally accessible TFTP server is included.

• The passwords and SNMP communities are removed, but an IP of the externally accessible FTP server vulnerable to the buffer overflow attack is included.

Another bad security practice we have seen is ISPs providing full router configuration (passwords included!) as a form of customer support, helping inexperienced customers set up their border routers (usually low-end devices such as Cisco 700 and 800 series routers). Sometimes, companies or organizations do the same to help telecommuters configure the routers they use to connect to the central site. These configs are posted to the ISP, company, or organization web sites and are available for everyone to view.

Just how many users in these examples are security conscious and will change the passwords and usernames? An attacker can gather a lot about of information about the security measures implemented (or not implemented) in these configuration files. Is incoming broadcast address-directed traffic filtered to avoid Smurf-type denial-of-service (DoS) attacks? How about loose and strict source routing IP options' support? Is logging properly implemented? Are access lists available? The users are not going to introduce all these useful countermeasures unless they are provided in such sample configs or command sequences. In our humble opinion, these examples must be distributed to remote users on floppies or CDs when the routers are handed out, and even sending them to users by e-mail means less public data exposure, even though e-mail is still an insecure way of providing them.

Don't forget about the MRTG configuration files and web pages showing traffic analysis, router or switch interfaces, and other useful data. This information should be served on a need-to-know basis and available only for the system administrators who actually use it. Neither the outsiders nor the internal users should have access to the MRTG readings without a sound reason and security system administrator's approval.

As to the misconfigured web servers giving away sensitive Cisco configuration files, make sure that this never takes place and that only the public directories are exposed to the server visitors . The ways of doing that will depend on the web server type and go beyond the scope of this book. (See Hacking Exposed: Web Applications and more general Hacking Exposed series books.) Finally, while keeping your Cisco management web servers locked down and your TFTP servers protected is very relevant to what we have described above, this topic truly belongs in the chapters that follow and is discussed there.