by Rik Farrow
While most attacks target servers, routers are vulnerable too
In late January 2001, a mistake made while changing the configuration of a router in Microsoft's network denied access to all of the networks run by Microsoft: Microsoft.com, MSN.com, Hotmail.com, MSNBC.com, and others. It took 22 hours for Microsoft's network technicians to track down the mistake and fix it. Meanwhile, attackers and the curious (like myself) had investigated the cause of the outage and deduced that a Denial of Service (DoS) attack against the problem router would have also deny access to any Microsoft-sponsered site. Over the next day-and-a-half, DoS attacks did indeed block access.
Microsoft had made two key errors, one in how its handles changes in router configuration, and another in how it designed its network. The first error points to an often ignored area in network security--the routers that bind together the myriad of networks that comprise the Internet, as well as any large, internal network.
Some routers run specially designed operating systems, and others run stripped-down versions of UNIX. In either case, the operating systems and configuration management of these routers may be vulnerable to attack. Attacks against the routing infrastructure as well have long been predicted, but have yet to materialize. This article looks at router security, makes recommendations for hardening your routers, and takes a forward look at potential attacks on the routing infrastructure.
Configuring routers is one of networkings most difficult tasks. Routers, once UNIX systems dedicated to forwarding packets between systems, have grown in flexibility and complexity, making the task of correct configuration a tricky proposition. The complexity is very probably what bit Microsoft.
The problem started when a technician changed the configuration of the router on the border to the internal network that housed all four of its DNS servers. The technician was probably satisfied that the change made had not had a deleterious effect on the performance of the router--packets could still reach the DNS servers, and from inside Microsoft's networks, things still worked properly.
But from outside of Microsoft's networks, traffic to the subnet containing the DNS servers was not getting through. Unable to resolve names, like www.microsoft.com or hotmail.com, millions of users were suddenly unable to reach any of Microsoft's public sites. The sites themselves were still accessible, but only if you used the IP address itself, instead of the DNS name for the site.
What might have saved Microsoft from its day long recovery period would have been a version control system for router configuration. Version control systems keep track of changes made in software or configuration files, and make it easier to restore a past (and working) version, as well as to quickly determine which items in the configuration have changed. A quick check of CVS, or simply restoring the last saved configuration for the troublesome router, would have fixed the problem.
Microsoft's other issue had to do with design. All of Microsoft's DNS servers were on the same subnet, 207.46.138.0, something easily discovered with DNS tools like nslookup. The DoS attack that occurred after the router mistake was fixed was almost too predictable. Microsoft handled this problem by subcontracting with Akamai to provide an additional nameserver for its networks. Microsoft's own name servers still reside on the same subnet.
Besides the configuration mistake, routers are subject to many other potential problems. Routers are accessible over the network, most commonly via TELNET and often via HTTP. If an attacker can successfully log into a router, or issue commands via the Web server interface, he or she can change routes and deny access to hosts or networks served by that router. Routers always support passwords that prevent unauthorized people from changing configuration, but the passwords themselves are not enough.
Both TELNET and HTTP do not use encryption, so passwords can be sniffed and reused. Routers also come with default passwords that are easily guessed, and must be changed. Some routers support additional authentication techniques, like one-time-passwords, and you should use these whenever possible. You might also be able to use Kerberized TELNET or SSH for your access to the router, which provides stronger authentication and encryption while configuring the router.
There are other tricks you can use as well. Access control lists can be assigned to all interfaces of the router so that only TCP connections from a short list of IP addresses are permitted access to the TELNET port. If you are not using the HTTP server (or any other service available on the router), disable it. Remember that routers run operating systems, and that any open port represents a service that may provide access to the router's operating system. You can port scan any of the IP addresses assigned to a router's interfaces using a tool like nmap, looking for enabled services.
One of the more insidious ways to control a router is through SNMP. SNMP uses community strings to identify sets of variables, and common community strings include public for read-only variables and private or write for read-write variables. In February 2000, someone posted a tool to SecurityFocus's Bugtraq forum that writes to the SNMP variable used to start downloading a Cisco or Ascend router's configuration to an arbitrary TFTP server. A second command could be used to reload the configuration from the same server, along with any changes. The April 1999 Network Defense column discusses the many weaknesses in SNMP.
Defense against SNMP includes using access control lists to limit access to the SNMP agent to specific IP source addresses. And Cisco has modified their version of SNMP (and called it v2) to support authentication through message signing. At the very least, change your community strings, block access to UDP port 161, and use whatever mechanisms your router vendor supports to protect against SNMP abuse. Or, better yet, disable SNMP if you are not using it.
Some attacks can overwhelm a router. For instance, if someone within your network launches mstream, a DoS tool used to flood a target network, it can also fill caches used in some router configurations to speed routing decisions. Mstream spoofs source addresses, and the cache treats each source and destination address pair as a cache entry, so the cache can quickly be filled with garbage entries. Of course, if you have employed filtering against source address spoofing at all layers of your network (RFC2267), you will be immune to this attack, as well as being a better Internet neighbor.
Sometimes, a router can be used to mitigate a DoS attack, through mechanisms like traffic shaping or custom queueing. But the DoS flood may prevent access over the network to the very router you need to configure to block the attack. The ideal solution is to have a separate control network for managing routers "out-of-band", but few organizations have the resources to do this. More commonly, the console ports of routers at remote locations are connected to modems set to auto-answer, providing an out-of-band method for configuring the router. Modems are easily discovered by war-dialers, so if you choose to use a modem on a console port, use a pair of encrypting modems or some other method of protecting access.
While the simplest attacks against routers involve DoS or configuration changes, another potential attack is to use routing protocols to send bogus information to the router. If the router accepts the bogus information, it will change its routing tables, perhaps making some or all of the networks it serves unreachable. In an attack described by Steve Bellovin in 1989, modifying routing information can also be used to redirect traffic through a network controlled by the attacker, allowing the attacker to sniff passwords, or intercept and change data.
Again, router manufacturers provide mechanisms to help thwart the threats to your routing fabric. The most commonly used interior routing protocols, OSPF (Open Shortest Path First) and RIP v2 (Routing Information Protocol), support methods for authenticating routing updates. You can also prevent routing information from being shared with neighboring networks, which actually makes sense, as the routes to your networks are, in most cases, static, and do not require dynamic updating. Sharing your routing information leaks information about the configuration of your networks. Accepting routing information from other networks risks disrupting your internal routing.
If you are an ISP, or have connections to multiple ISPs, then you are using BGP4, the Border Gateway Protocol version 4. BGP4 is the exterior gateway protocol that distributes routing information throughout the Internet. Instead of transmitting routes to specific network addresses, BGP4 exchanges information about aggregates of network address between Autonomous Systems, networks under a single, consolidated, technical control. You don't need BGP4 to talk to the Internet, as a default route to your ISP works for most sites--unless you have redundant links to multiple ISPs.
BGP4 has its own, so far, theoretical security problems. Routers using BGP maintain TCP connections to their peers (neighbors), and constantly exchange keep alive messages or updates. If this connection is broken, through an error or an attack, the router then discards all the routing information it had received from its peer, and passes this change in the routing fabric along to its peers. If the break in communication between affected peers lasts long enough, huge sections of the Internet could become unreachable.
The BGP4 attack scenario has long been a favorite topic for anyone who claims to be able to "bring down the entire Internet". BGP4 does include support for authentication in the protocol headers, and extensions designed to make any attack more difficult, such as tweaks to TCP to make sending RESETs to shutdown connections between peers next to impossible. The fact that we haven't yet seen such attacks suggests that no one has yet discovered a working exploit against BGP4.
What is much more likely is that a successful attack against BGP4 would affect only a portion of the Internet, and that the network providers that run the Internet would be highly motivated to fix such a problem as fast as possible. If an exploit currently exists, the parties who know about the details are holding the attack in reserve until some critical moment when it might have maximum impact.
DNS and routing are the core technologies that make it possible to use the Internet. In Microsoft's case, having placed redundant DNS servers on different networks would have prevented several, very embarrassing, days of outages.
You will, hopefully, learn from Microsoft's mistakes by maintaining careful records about changes to the configuration of any of your routers, and by providing backup DNS servers that do not share the same subnet. You will also want to protect your routers, as an attacker can quickly deny access to your network by taking over your router. In an event in the fall of 2000, an attacker changed the password in a router, preventing the owner of the router from remotely restoring the configuration and damaging the router (http://www.denverpost.com/business/biz1012d.htm).
Don't become another embarrassing network statistic. Guard your routers and keep your routes to yourself unless you are a network provider. And remember that a little redundancy can go a long way toward having a reliable Internet presence.
Cisco's suggestions for securing your routers and switches: http://www.cisco.com/warp/public/707/21.html
Palm-based password cracker for Cisco passwords (other than with
the use of enable secret):
http://www.atstake.com/research/tools/index.html#password_auditing
University of Michigan proposed study of attacks on the routing infrastructure: http://www.darpa.mil/ito/psum1999/H558-0.html
IETF draft (expired) on security issues with BGP4: http://www.globecom.net/ietf/draft/draft-murphy-bgp-secr-02.html
RFCs defining BGB: http://www.faqs.org/rfcs/rfc1105.html, rfc1267, rfc1654, rcf1771.
Steve Bellovin's prescient 1989 ACM paper about weaknesses in the TCP/IP protocol, including routing attacks: http://www.ja.net/CERT/Bellovin/TCP-IP_Security_Problems.html