Cisco IOS HTTP Authorization Vulnerability

Karen Kent Frederick

Cisco IOS security is often overlooked as a critical aspect of overall information security. Many systems administrators are not aware that lax router and switch security may lead to major system compromises. In this article, I discuss Cisco IOS security and how following best security practices can prevent the success of many attacks. Much of my discussion focuses on the Cisco IOS HTTP Authorization Vulnerability, which could allow attackers to easily gain administrative-level access to vulnerable Cisco devices. I'll also show that environments that had implemented strong security measures for their Cisco devices were generally not susceptible to this vulnerability.

Cisco IOS HTTP Authorization Vulnerability

Cisco IOS (Internetworking Operating System) is the software used to configure and monitor many (but not all) Cisco routers, switches, and other devices. Administrators connect to Cisco devices using a variety of methods, such as telnet, modem lines, and local console access. Generally, these users are using the Cisco CLI (Command Line Interface) to interact with the Cisco device. An alternative to these methods is the Cisco IOS HTTP server, which has been included in more recent versions of the Cisco IOS software. It runs on the Cisco device that the administrator chooses, and it allows administrators to monitor or reconfigure a Cisco device remotely through a Web browser. Although many of the same functions can be performed using the CLI or the HTTP server, some users prefer the HTTP method because they find it to be easier or more convenient than the CLI.

In mid-2001, Cisco released a security advisory pertaining to a vulnerability related to their IOS HTTP server. This vulnerability (the Cisco IOS HTTP Authorization Vulnerability) affected various Cisco IOS releases from 11.3 through 12.2, running on dozens of models of Cisco routers and switches. The advisory stated that the vulnerability existed on such devices with the HTTP server enabled and with local authentication being used for HTTP users, which means that their usernames and passwords are on the local device, not in a remote authentication system such as RADIUS. By exploiting the vulnerability, an attacker could gain complete access to the Cisco device, with the ability to remotely execute commands on the device at level 15 (the enable level). This is the highest privilege level, which allows configuration changes to be made. Normally, you must use the enable password in order to work at this level, however, this vulnerability allows attackers to execute commands at the enable level without using the enable password.

This vulnerability is particularly dangerous not only because the attacker can gain full administrative access, but also because the vulnerability is extremely easy to exploit. Typically, you would expect to see the Cisco device's HTTP server accessed through URLs like the following:

http://10.1.2.3/level/15/exec/show/config

• The first part is the IP address of the Cisco device.
• The second item must always be level.
• The third part (the number 15 in this example) corresponds to the privilege level. Level 15, the enable level, is the highest of the 16 privilege levels; 0 is the lowest level, which provides very limited functionality. Any value between 00 and 15 is valid here.
• The fourth item is always exec.
• The rest of the URL is optional. If supplied, it should correspond to a command. In this case, the command-line equivalent of the command that is being sent in this URL is show config.

To exploit the vulnerability, the attacker supplies similar URLs to the Cisco device, except that she supplies privilege level values between 16 and 99. So an example of an exploit attempt is:

http://10.1.2.3/level/16/exec/show/config

It's important to note that this exploit will only work if local authentication is being used. If you are using a different authentication method for HTTP users, such as RADIUS or TACACS+, any attempt to exploit this vulnerability will fail and the attacker will be prompted to authenticate herself.

Published Exploits

Since this vulnerability is so easy to exploit, attackers could literally start compromising Cisco devices immediately after learning of its details, which were widely available. Within days of the Cisco security advisory, several people had written and published programs to find or attack vulnerable devices. Again, because the exploit is so simple, some of these programs required fewer than twenty lines of code and each program had a somewhat different purpose or methodology.

One published exploit allowed the attacker to scan a particular network block for vulnerable Cisco devices by trying every privilege level between 16 and 99 for each IP address and monitoring the HTTP response codes. Any device that returned a 200 code, indicating that the command was successful, had its IP address and vulnerable privilege level logged to a file. Another published exploit was more user friendly; it performed a similar scan but when it found a vulnerable device, it prompted the attacker to choose another action (such as altering the message of the day, displaying configuration information, or performing any IOS command as specified by the attacker).

Because this vulnerability can provide full device access to an attacker, the attacker can do anything she chooses to the device -- cause a denial of service, or reconfigure it. Attackers can alter the ACLs to allow other types of traffic through to set up more attacks. Perhaps you use the same passwords on multiple devices, so compromising one device and getting its passwords can quickly compromise other devices as well, or the device might be used to gain reconnaissance information about other devices, again to set up future attacks.

Eliminating the Vulnerability

This vulnerability depended on three conditions: a susceptible IOS version, an enabled HTTP server on the device, and local authentication in use for HTTP users. By eliminating any of the three of these conditions, the vulnerability is eliminated, and these exploit attempts will fail. (There is an exception to this -- in Cisco IOS version 12.2(2)T with IPv6 enabled, its HTTP server cannot be disabled.) However, all three of these items already present other security weaknesses, so it may be prudent to eliminate two or all three of the conditions.

Cisco advises that one way to eliminate the vulnerability is to stop using local authentication for HTTP users. Alternatives such as Terminal Access Controller Access Control System (TACACS+) or RADIUS should be used instead for HTTP authentication. Information on how to implement TACACS+ is available at http://www.cisco.com/warp/public/480/tacplus.shtml.

Another way to eliminate the vulnerability is to upgrade to a newer IOS version that is not vulnerable. The appropriate IOS version depends on what device you're using, so check the latest information on the Cisco site to know which version to use. However, before upgrading, don't forget to make sure that you have sufficient resources in your device, such as enough memory, to handle the new IOS version.

A third way to eliminate the vulnerability is to disable the HTTP server, which can be done by issuing the command no ip http server. The HTTP server is only one of several methods that can be used to view and modify Cisco IOS configurations. If none of your administrators use the HTTP server, it should definitely be disabled. If you are using a vulnerable IOS version and are using local authentication for HTTP, you should immediately disable the HTTP server and use other methods for configuring the device until you can upgrade IOS or change the authentication method.

Improving Your Cisco IOS Device Security

Good Cisco IOS security practices are very similar to that of servers and workstations. The details are certainly different, but the underlying principles are all the same -- after all, Cisco IOS is an operating system. Here are several actions that you can take to strengthen your Cisco IOS security:

1. Subscribe to Cisco security mailing lists and promptly read all Cisco security advisories that pertain to devices and models in your environment. Security advisories are mailed to Cisco's cust-security-announce mailing list, and they are also posted to http://www.cisco.com/warp/public/707/advisory.html.

2. Be aware that many Cisco passwords are passed between users and the Cisco device in cleartext. Telnet is an obvious example, but many people are not aware that when you are using the HTTP server the password (often at the enable level) is passed in cleartext in each URL. (The password is base64 encoded, which is far different from encrypted; it's trivial to decode it.) Be cautious about using any connection methods that send passwords in cleartext on networks that may be sniffed, particularly public networks. Even on internal networks, there may still be a substantial risk because users could be running their own sniffing software, or Trojans could be monitoring traffic and collecting passwords.

3. Use different passwords for different functions and on different Cisco devices. For example, the enable password should not be the same as the HTTP password because the HTTP password is transmitted in cleartext. Also, if you use the same passwords on every router and an attacker obtains one password, he will be able to log in to every router. It's also a good practice to change passwords regularly.

4. It's vital that you do proper logging on your Cisco devices. AAA logging will record such things as logins, privilege levels, and HTTP accesses. This information is extremely valuable for incident handling purposes when a vulnerability is being exploited, because it provides a record of how the device was exploited and what the nature of the exploit was.

5. Restrict network connectivity to Cisco devices. For example, an external user shouldn't have any legitimate reason to initiate a telnet connection to one of your internal routers. By configuring your firewalls and router ACLs to prevent direct connections to these devices, you can prevent the exploit of some vulnerabilities. Note that your Internet router may remain unprotected by this; perhaps your ISP can block connections directly to it. Also remember that there are many different connection methods, so you're safest blocking access to the Cisco device IPs instead of blocking by individual services, such as telnet. It's also a good idea to use ip access-class to specify which IP addresses can make a connection with each VTY.

6. Secure each access method for connecting to Cisco devices, which includes restricting physical access to routers and switches, as well as limiting modem and serial line access and network-based methods such as telnet, rlogin, and ssh. Each VTY or TTY should either require authentication or should be configured to prevent logins. Also, each VTY should be configured using transport input to specify which access methods are permitted to connect to it.

7. Disable all unnecessary services. Depending on the IOS version and device model, various services may be enabled that you're not even aware of. The small services (i.e., echo, chargen, and discard) are rarely used legitimately but can be used in attacks. These can be disabled through the no service tcp-small-servers and no service udp-small-servers commands. Finger should normally be disabled as well; other services such as the Cisco Discovery Protocol (CDP), HTTP, the Network Time Protocol (NTP), and SNMP should be disabled if not used, or otherwise configured in a secure manner. Also, if you only want a service to be available on some interfaces, make sure to disable it from the other interfaces.

Implementing just one or two of these items is not recommended -- it's best to implement them all (if possible in your environment). A fundamental security concept is that of a layered defense. If a device is only protected by one security mechanism, its defenses are quite weak. By implementing multiple security mechanisms, you increase the amount of protection and decrease the likelihood that a vulnerability can be exploited. In a layered defense, you would use router ACLs and firewall rules to block access to a device. You'd harden the device by following good Cisco IOS security practices, such as removing unnecessary services. Also, you'd maintain the device's security by keeping it currently patched (particularly with security-related patches) and by auditing its configuration periodically. A great source of information on protecting your devices is "Improving Security on Cisco Routers", available at http://www.cisco.com/warp/public/707/21.html.

Besides limiting access to Cisco devices and configuring them to limit exposure to vulnerabilities, another important security measure that can help to protect your systems is network intrusion detection. It is highly useful to identify attackers probing for vulnerabilities or attempting to exploit things. Because of the severity of the Cisco IOS HTTP Authorization Vulnerability, some intrusion detection companies released signatures within hours of the Cisco security advisory, which sent administrators an alert when an attacker attempted to exploit this vulnerability. In some cases, the signatures also attempted to determine whether the attack had been successful. So in an environment with current and robust intrusion detection technologies deployed, successful attack attempts could have been reported to systems administrators within seconds of occurring. See the "Other Cisco IOS Vulnerabilities" sidebar for other security-related vulnerabilities.

Conclusion

In this article, I've taken a close look at the Cisco IOS HTTP Authorization Vulnerability, under what conditions it occurs, and how it can easily be exploited. More importantly, I've focused on the methods that can be used to eliminate the vulnerability. By following good Cisco IOS security practices, as well as implementing a good network intrusion detection solution, you can greatly reduce the risk that your Cisco devices will be exploited now or in the future. If you approach Cisco IOS security with the same mindset you use when protecting a critical server, you can improve the overall security of your network infrastructure.

References

Cisco IOS Security Information:

Improving Security on Cisco Routers --
http://www.cisco.com/warp/public/707/21.html

Cisco Product Security Incident Response --
http://www.cisco.com/warp/public/707/sec_incident_response.shtml

HTTP Security --
http://www.cisco.com/univercd/cc/td/doc/product/software/ios112/httpsec.htm

Cisco IOS Security Configuration Guide --
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scdoverv.htm

Increasing Security on IP Networks --
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs003.htm

Cisco IOS HTTP Authorization Vulnerability:

Cisco Security Advisory: IOS HTTP Authorization Vulnerability --
http://www.cisco.com/warp/public/707/IOS-httplevel-pub.html

CVE Candidate CAN-2001-0537 --
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0537

Other Cisco IOS Vulnerabilities:

Cisco Security Advisory: Multiple SSH Vulnerabilities --
http://www.cisco.com/warp/public/707/SSH-multiple-pub.html

Cisco Security Advisory: Cisco IOS PPTP Vulnerability --
http://www.cisco.com/warp/public/707/PPTP-vulnerability-pub.html

Cisco Security Advisory: Cisco 6400 NRP2 Telnet Vulnerability --
http://www.cisco.com/warp/public/707/6400-nrp2-telnet-vuln-pub.shtml

Security Advisory: IOS Reload after Scanning Vulnerability --
http://www.cisco.com/warp/public/707/ios-tcp-scanner-reload-pub.shtml

Karen Kent Frederick is a senior security engineer on the Rapid Response Team at NFR Security, where she specializes in intrusion detection signature development. She is also one of the authors of "Intrusion Signatures and Analysis". Karen can be contacted at: kkent@bigfoot.com.