CISCO APPLIANCES AND NETWORKS: AN ATTACKER S PERSPECTIVE

CISCO APPLIANCES AND NETWORKS: AN ATTACKER'S PERSPECTIVE

How easy is it to hack into that Cisco box and get away with it? The answer depends on the point of view. From the standpoint of a script kiddie , it's dead easy (see Chapter 6). A cracker who doesn't care where the box is and what function it performs can enable dozens, if not hundreds, of routers and switches in a few days and get many hundreds of unprivileged user accounts on Cisco equipment. The latter may not be particularly exciting, but it is sufficient to launch a massive DDoS pingflood.

An attacker on a typical 512/256 Kbps Asymmetric DSL (ADSL) link can scan a /8 network (255.0.0.0 in CIDR notation) for port 23 and login passwords such as cisco (see Chapter 6 for more of the typical passwords to use) in about two days. Such a scan will hand the cracker around 500 to 1000 unprivileged user accounts. Further manual or script-based password guessing is going to be successful about 10 percent of the time. That amounts to 50 to 100 enabled devices in three days, or 200 to 300 enabled hosts in a week! The majority of these breached hosts will be modest Cisco 800, 1600, 1700, and 2500 routers, but quite a lot of midrange devices (such as 2600 and 3600 routers, 2900 Catalysts) and some true gems (like Cisco 7000 and 7200; Catalysts 5000, 5500, and 6500; and, sadly enough, AS 5300 or even higher) can also be successfully attacked .

Now imagine a more sophisticated attacker who would also scan for default and common Cisco SNMP communities, Trivial File Transfer Protocol (TFTP) servers with possible Cisco configuration files stored, and known vulnerabilities that lead to enable. With enough determination, such an attacker can, indeed, "own a continent " (without even knowing the difference between a stack and a heap). If the cracker is familiar with programming or at least shell scripting, the efficiency of scanning and exploitation can be significantly increased through automation and basic logic (for example, do not check default SNMP communities on a device with the enable password already guessed).

Talking about continents (or at least large parts of them), the United States and the European Union appear to be less susceptible to this type of onslaught, while the developing areas of the world (such as Africa or Central, East, and Southeast Asia) appear to be more vulnerable. A likely explanation for this difference is a "brain drain," with more experienced and security-knowledgeable professionals heading West. For example, South America is largely insusceptible to basic Cisco vulnerability scanning, but a few regions that experience significant brain drain to the United States are softer targets. In addition, a politically motivated hacktivist can easily determine which IP ranges belong to the countries of interest using whois and a variety of BGP queries (see Chapter 4 for more details). Then, scans and further attacks can be launched against a selected country. Hopefully, with time, the process of globalization will even out these issues.

What are the risks for a cracker running massive scans searching for undefended Cisco appliances? The cracker is likely to land on the DShield offenders list ( http://www.dshield.org ) and can lose their ISP account, but some newbie crackers will find that acceptable or even ego- boosting . More experienced attackers will run the scans from some remote machine they broke into beforehand or via a neighboring wireless. A rotatable 20-up dBi directional or semidirectional antenna on the roof or balcony can do wonders. Of course, both techniques ( hopping through "rooted" hosts and abusing wireless LANs) can be combined if the cracker is sufficiently experienced and reasonably paranoid . Finally, in a doomsday scenario, both automated scanning and exploitation functions can be handed to a worm that will report the results to overseas hosts controlled by the cracker. By using such methods , the risks of being caught and prosecuted are significantly reduced, while the damage that could be done is multiplied.

Everything described so far represents an approach based on massive " low-hanging fruit" scanning. Such opportunity is available to attackers with a medium or even a low level of experience and skill. The reason for its existence, as you have probably already guessed, is the "eternal wetware flaw"security negligence, laziness , and ignorance of system administrators combined with the human resources mismanagement by their bosses. What about a determined hacker looking to exploit a specific Cisco appliance without obvious human factorlinked security problems? How about finding new 0-day vulnerabilities in these devices? Can it be successful? The answer is a definite yes.

Figure 3-1 represents the steady growth of security vulnerabilities in Cisco appliances and software reported to the Bugtraq mailing list since 1999. The year 2002 was marked by a splash of reported flaws (to which the authors have contributed three modest DoS conditions). The year 2003 was relatively calm, but in 2004 the amount of reported vulnerabilities exceeded the 2003 report's count five months before the year's end.

Figure 3-1: Bugtraq Cisco vulnerabilities count

As you can see, dozens of new Cisco vulnerabilities are reported every year, and this number is on the increase. This shatters the myth that closed source software is too difficult to analyze and exploit and should thus be considered safe. That said, the need to reverse engineer the binary application does raise the bar for potential attackers, and the majority of the flaws reported are DoS conditions found by accident rather than code disassembly. Alas, the world does not lack reverse engineers , and once a flaw is found and an exploit is written, it is easier to preserve it from the public eye if the exploited software is closed source.

Phenoelit ( http://www.phenoelit.de/ ), headed by Felix, also known as FX, has performed a titanic work of finding new vulnerabilities and writing working IOS exploits. The results of Phenoelit research are available to the public and are regularly presented at DEFCON and other hacking conferences. Throughout this book, we use Phenoelit's research data and tools, such as IRPAS. However, we assume that even without any public information releases, Black Hat hacker groups or even foreign government organizations would be working on exploiting Cisco appliances.

Considering the role Cisco devices play in the modern network's infrastructureincluding the Internet's backbonethe stakes are too high to be ignored. Thus, a clear explanation of IOS and other Cisco-specific operating systems' reverse engineering and practical exploitation is crucial for anyone whose system can be affected by Cisco security issues. Chapters 8 and 10 of this book strive to provide such an explanation in legal margins.

The assumptions we make here are based on the idea that the source code will never be leaked to outsiders and reverse engineering will be an absolute requirement for exploit development. But this may not always be the case. For example, on May 13, 2004, a Russian information security site, SecurityLab, reported that the source code of IOS versions 12.3 and 12.3t was stolen after the internal Cisco network was breached. The amount of stolen code was claimed to be around 800MB in archive. The initial source of information about the incident was someone called franz at #darknet@EFnet. To prove the leak, franz has distributed a small (about 2.5MB) part of the stolen code. SecurityLab has published 100 first lines from two files distributed by franz as proof of the story at http://www.securitylab.ru/45223.html and http://www.securitylab.ru/45222.html . As you can see, these lines were removed upon Cisco Systems' insistence. While at the time of writing, no public domain exploits exist based on the stolen code, there is no guarantee that they won't appear in the future and that future code leaks will not take place. This incident, as well as reverse engineering research, underlines that proper security should be based on secure programming and code security reviews and not code obscurity.

After all, not all Cisco device software is closed source. The amount of Cisco appliances running some form of Linux is increasing every year. Examples of such appliances were mentioned in Chapter 2 and include Cisco Guard XT 5650 and certain blades such as the IDSM-2. The flaws applicable to Linux on other platforms will apply to such devices just as well; a cracker will have to adjust the memory offsets in the existing exploit to match the new target, which is a common practice.

One of the strong sides of Linux, security-wise, is the speed with which updates and fixes are generated by the open source community. We can only hope that Linux-based Cisco appliances receive timely security updates. Somewhat damaging this hope, the IDSM-2 upgraded old Red Hat 6.2 to a newer (but still obsolete) 7.3, running 2.4.26 kernel only in the summer of 2004 (per Cisco's web site), and it can become a suitable hacker target, as discussed in Chapter 2.

Another UNIX-like system employed by some Cisco appliances, such as 4200 series IDS sensors, is Sun Solaris. While Solaris is not an open source system, at the moment of writing the possibility of Sun opening its operation system code is up in the air. Open source or not, Solaris has got its hefty share of security vulnerabilities that would be just as applicable to Cisco devices running the system (replace the shell code [if needed] to correspond to the attacked platform's CPU architecture, adjust the memory offsets, and go).

Finally, many Cisco applications run on Windows workstations. Hacking into a central CiscoWorks management station and retrieving the attacked network router's credentials from it is probably the most efficient way of taking over multiple Cisco routers or other devices in a short period of time. Ironically, this can be accomplished with a Trojan and a bit of social engineering, exactly like a great deal of successful "lame" attacks against Windows hosts that happen every day.

In addition, any attacker should always keep in perspective general multiplatform vulnerabilities applicable to Cisco devices. Examples of such vulnerabilities at the time of writing include OpenSSL ASN.1 Parsing Vulnerabilities (Bugtraq ID 8732) and Multiple Vendor TCP Sequence Number Approximation Vulnerability (Bugtraq ID 10183). Unfortunately, we see a general trend of routers and switches being updated less frequently and meticulously as compared to servers and even user desktops. You can still encounter Cisco routers running version 11 or even earlier IOS versions in the wild, some of this due to improper reboots resulting in use of the older hardwired code from the router's ROM. While the servers and workstations on a tested network may not be vulnerable to the multiplatform flaw for eons, try to attack the routers or switches using the same security hole and you may well succeed.

Attacking Network Protocols

We have outlined a malicious hacker's perspective of breaking into various Cisco devices the easy or the hard way. Let's look at the network protocols rather than the devices themselves . Cisco has developed a variety of proprietary protocols with open specifications that play an important role in modern networking. Examples of such protocols on Layer 2 include the following:

• Layer 2 Tunneling Protocol (L2TP)

• Layer 2 Forwarding (L2F)

• Generic Routing Encapsulation (GRE)

• Cisco Discovery Protocol (CDP)

• Extensible Authentication Protocol-Lightweight Extensible Authentication Protocol (EAP-LEAP)

Examples on Layer 3 include

• Hot Standby Routing Protocol (HSRP)

• Interior Gateway Routing Protocol (IGRP)

• Enhanced Interior Gateway Routing Protocol (EIGRP)

Many of these protocols were pioneering at the time of their development and gave Cisco Systems an edge over the competitors that could not provide similar functionality. It is understandable, then, that such protocols may have not been designed with security in mind, since providing the novel functionality and making it usable was the designer's primary concern. Thus, some of these protocols are exploitable or, at least, can be used for device fingerprinting (CDP). For example, HSRP uses a cleartext transmitted password for updates authentication. By forging HSRP updates, an attacker can cause DoS or even redirect traffic on a local network segment. GRE tunnels can be tricked to allow connections to internal hosts with private IP addresses from the outside.

EAP-LEAP is actually a security protocol, now a common part of 802.1x portbased authentication standard implementations . It relies on Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) for user authentication and was successfully exploited with Joshua Wright presenting the exploitation step-by-step at DEFCON 11 and releasing Asleap-imp, a tool to crack EAP-LEAP passwords on wireless networks, half a year later. A few similar tools such as THC-leapcrack were later released to the public domain (leap being released to the Packetstorm web site before asleap-imp). Note that the attacks on the Cisco protocols mentioned, as well as appropriate countermeasures, are described in Chapters 12 and 13.

As to the security of EIGRP, this routing protocol implements MD5 hash-based routing updates authentication, and not using it is a system administrator's, not a protocol designer's, fault. Nevertheless, Phenoelit has uncovered a flaw in Cisco IOS EIGRP implementation that causes an ARP storm on the network segment attacked with spoofed EIGRP neighbor announcements and we have continued the trend. Authenticating EIGRP updates and matching expected neighbors using extended access lists mitigates the problem but only partially. See Chapter 14 to learn more about this and similar attacks.

Hiding Tracks and Forensics on Routers and Switches

To conclude this section, we should discuss hiding tracks and forensics on Cisco routers and switches. Unfortunately for the security community, unless centralized logging is implemented, an attacker can easily wipe out all traces of her presence on a Cisco box with a few simple commands (see Chapter 10). Even if centralized logging is implemented, it is done over a traditional syslog, meaning that User Datagram Protocol (UDP) is used and the logging updates are neither encrypted nor authenticated. This allows crackers to tamper with logs in transit and try to crash or even exploit the core syslog server. For the logs to be valid, they should possess proper timestamps. Experienced attackers know that and will turn off timestamps upon penetration. They can also turn off Network Time Protocol (NTP) if used or send fake NTP updates. Make sure that when you use NTP on your Cisco router or switch, hash-based updates authentication is applied and access lists are written to prevent NTP traffic from unauthorized hosts. Those who are truly security- concerned can use an IPSec or a Point-to-Point Tunneling Protocol (PPTP)based VPN to protect syslog and NTP traffic modification between the router and appropriate servers and avoid unauthorized updates, including those with spoofed source IPs.

The ease with which crackers can remove router and switch logs makes hopping from one Cisco box to another, before reaching the actual target, a very attractive method to hide the attacker's tracks. Selecting hops to be positioned in distant countries, especially those with different or even opposite political and legal systems, turns any trace-back attempt into a nightmare. Some countries, for example Brazil, have very lax cybercrime laws (at the time of writing, anyway). Thus, trying to collaborate with local law enforcement agencies there is not expected to be fruitful, as they are unlikely to have an authority to seize and investigate the hosts used by attackers in the process of reaching their targets. Considerate attackers would also encrypt their traffic between hops on the way to the target machine. To do so, they can do any of the following:

• Use SSH if supported

• Upgrade the IOS or CatOS on the owned hosts to include SSH support

• Use IPSec

• Use PPTP

After the hop hosts are used, a wily attacker can resort to erasing Flash and NVRAM on these machines to present additional challenges to the forensic team. The main obstacle for using the "router-hopping" methodology to avoid being caught is an unacceptable delay. While, in theory, the more hops the attacker can use the better for him, in reality, if more than three or four hops are passed, the console will lag and executing commands on the hacked box may become too sluggish to be practical or enjoyable.

The incident response on a Cisco device is limited to accessing the device through the console port (be prepared to go to ROMMON mode, if the password is changed by crackers, but otherwise do not reboot the router!), analyzing logs (if not deleted or tampered with), recording actual and router time ( show clock detail ), and running a variety of show commands and recording their output. To our knowledge, no specific software package on the market performs forensic investigation of Cisco routers and switches.

The IOS show commands suggested for forensics use are listed here:

 show version               show interfaces      show running-config        show tcp brief all      show startup-config        show ip sockets      show reload                show ip nat translations verbose      show ip route              show ip cache flow      show ip arp                show ip cef      show users                 show snmp user      show logging               show snmp group      show ip interface 

Diffing the configuration files, including comparison of running and startup configs (which can be automated using SNMP and the Compare Configuration Files tool of the SolarWinds suite) as well as startup config and its copy stored in a secure location else-where, is vital for determining any unauthorized changes. Always have a copy of your startup config and keep it in a secured backup host apart from the File Transfer Protocol (FTP) or Trivial File Transfer Protocol (TFTP) servers used for saving the router's config file. One day it may come in very handy!

Tip 

Study Chapter 10 to see what kind of alterations the attackers are likely to introduce to the router or switch configuration files. These are the signatures you should look for when investigating the configs of compromised Cisco devices.

Of course, a careful attacker will also run show users from time to time, and if a system administrator's login is detected , the attacker will undo all the changes to the router configuration files and immediately log out. If the copy running-config startup-config command wasn't used, the fastest and most convenient way to do both is by rebooting the router. On Catalyst switches running CatOS, the changes are automatically logged into the startup-config; thus a series of clear commands will be needed to undo the configuration changes before running away.