by Rik Farrow
In 1998, the L0pht, a now defunct hacker research group, claimed in testimony before the US congress, that they could shut down access to the Internet in 30 minutes. Similar claims have surfaced over the years, but, so far, nothing has happened.
There have been disruptive denial of service attacks, and the potential exists for a massive DoS attack that could cripple Internet connectivity for some period of time. But what the L0pht was talking about was an attack on the routing infrastructure of the Internet, BGP (Border Gateway Protocol).
Recently, a couple of Cisco researchers decided to take a serious look at BGP. They stress-tested seven different BGP implementations in efforts to see just how robust BGP and its TCP/IP underpinnings would be under simulated attacks. And what they found looked good for BGP, but bad for the Internet, as the biggest danger comes from misconfigured routers.
Just how real was the analysis of BGP, when you consider it was performed by router vendor employees? Does this mean that we don't need Secure BGP (S-BGP), or Secure Origin-BGP (soBGP) to increase the confidence we can have in the routing information distributed by BGP? Both S-BGP and soBGP provide mechanisms to authenticate the source, and integrity, of routing information, but at a price. Meanwhile, the Internet remains at risk not from exotic attacks, but from ISPs who ignore best configuration practices (BCP).
Sean Convery and Matthew Franz decided to take a deeper look at the fear, uncertainly, and doubt (FUD) that has surrounded BGP for many years. These fears lead to the application of a security "bandaid" to TCP, MD5 authentication for BGP connections, in 1998, but little has happened since, outside of suggestions to add digital signatures to routing updates.
Convery and Franz began (see Resources) by creating an attack
tree. Researchers use attack trees to help visualize all the
methods that could be used in an attempt to reach a particular
goal. When disrupting BGP is the goal, there are two main
pathways to getting there. The first is to disturb the communication
between two BGP peers (see the March 2003 Network Defense,
www.spirit.com/Network/net0103.html)
by shutting down the TCP connection that these routers maintain.
When this TCP connection goes down, for whatever reason, each
router assumes that communication to the other router has been
lost, and will send out BGP messages to their other peers
withdrawing all the routes that pass through the now unreachable
router. The second pathway would be to insert spoofed routing
information. Convery and Franz focused on the first pathway.
Convery and Franz began by attempting to connect to the BGP service port, 179/TCP, from a non-configured peer. In four out of the seven BGP implementations, the connection was rejected. In the other three, acknowledgments (SYN-ACK packets) were sent back. But attempting to actually begin a BGP transaction (an OPEN) failed in every case, six with resets, and one with an error message. These results are very positive, because you only want configured BGP peers to exchange BGP information. Convery and Franz also attempted opening a BGP session with a configured peer, but using wrong AS number, and failed every time. The Autonomous System (AS) number identifies a group of routers under the control of a single administrative authority, and BGP relies on AS numbers when exchanging updates, and calculating routes.
Next, they tried various denial of service attacks. In each of these attacks, packets with spoofed source addresses were sent to each implementation to test the robustness of the TCP/IP stack. Convery and Franz used Naptha, a DoS tool, to send SYN-floods, ACK floods, and FIN floods to the implementations under test. In three of the seven implementations, they found degradation in performance, because the IP stack under test would respond by sending back SYN-ACKs (acknowledgements) back to IP addresses that they would never complete a connection with. While this is standard behaviour for an IP stack, it actually works against a targeted router by forcing it to waste resources (CPU cycles and memory) by responding to spoofed packets.
The various floods did not result in any of the seven implementations losing their TCP connections with their configured peers. Convery and Franz then attempted a different technique to break those connections-- reset floods. TCP reset packets, those with the RST flag set in the TCP header, signal an unrecoverable error to the receipient of those packets. If you perform a TCP port scan of a system, and sniff the response, you will see RSTs sent in response to closed ports, standard behaviour for TCP. It is also possible to force an established TCP connection to be reset by sending a spoofed RST packet. The spoofer has a problem, though, in that the RST packet must contain at least four bytes of information that will be difficult to guess. The RST packet must include not only the correct source and destination IP addresses and port addresses, but the correct sequence number as well.
For an attacker who can sniff the communications between routers, there is no need to guess the sequence number. The sequence number can be sniffed, and there are tools, such as tcpkill or ettercap, that can do this simply. But most BGP speaking routers are connected over links that provide little opportunity for sniffing (for example, fiber, ATM, or T1 connections), so the attacker must send any RSTs completely blind. If the attacker knows the port addresses used by both peers, the attacker still might need to send billions of packets before one with the right sequence number would be received. Using their own tool, they found they could send 62,500 packets per second, and were able to reset a connection once every nine hours on the average. That packet rate would in itself represent a DoS attack on some networks. And the success rate for this attack is abysmal, as the peering routers immediately reconnect. The researchers concluded that this attack would need to be combined with a SYN flood, so that once the connection is broken, it would be difficult to re-establish it. Of course, that just adds more spurious traffic, over long periods of time, that would very possibly be noticed.
All of the tested BGP implementations can be configured to include MD5 authentication in every TCP header. A special TCP option appends a 16 byte MD5 digest over some of the header information as well as the data, and a secret value. Without the secret value, the MD5 digest will be incorrect, and the connection would be dropped. Convery and Franz used John the Ripper, a password cracking tool, to generate all possible six character passwords using a particular character set, then processed those passwords with their own testing tool, bgpcrack. By using the password as the secret, and recalculating the MD5 digest over several sniffed BGP packets, they were able to crack a test password, D0M1N0, in three and a half hours. The researchers suggest using much stronger passwords to prevent attacks where BGP connections can be sniffed.
In another test of the MD5 authentication system, the researchers sent spoofed packets with incorrect MD5 authentication. Some implementations checked the MD5 digest before processing TCP packets that would have been rejected because they came from a non-configured peer. Processing these MD5 signed packets produced a 70% performance hit that could be eliminated by silently dropping packets from non-configured IP source addresses.
So far, all the tests described involve the TCP/IP stack that supports BGP. In the next series of tests, Convery and Franz attacked BGP itself. First, using a configured peer, they flooded a BGP router with routes. Convery and Franz actually demonstrated this during their presentation at BlackHat 2003, causing a small Cisco router to reset its connection and lose its routing table after exhausting the amount of memory available. Other implementations had similar failure mechanisms when flooded with routes from a configured peer. Note that the attack must come from an exploited router for it to get this far.
Next, they performed TCP hijacking to insert spoofed routes. In TCP hijacking, the hijacker must be able to sniff the connection, because, as with the RST attacks, the header information, including the sequence number, must all be correct. If an update request could be inserted, the targeted router would add the attacker's routes (barring route filtering). But the spoofed router would begin an ACK storm.
ACK storms occur when either side of a TCP connection receives an acknowledgement for data it didn't send--which happens when a TCP connection is hijacked, and data is injected. What Convery and Franz noted was that the ACK storm could continue as long as 5 minutes, during which time the phony routes would be propogated by the targeted router. This attack not only requires sniffing, but MD5 authentication must either be disabled, or the attacker must have cracked the MD5 secret.
The researchers completed their tests of BGP implementations with fuzzing. Fuzzing means to send random inputs to a software program in an attempt to crash it--a form of stress testing, often used in finding buffer overflows. Convery and Franz wrote a tool that could send completely random BGP messages, or ones that began with varying amounts of correct data, followed by random data, so that they would be exercising different parts of the BGP code. Out of 1200 different fuzz patterns, they found only four flaws in the seven implementations. Again, the condition for using the fuzzer requires that the target accept BGP connections from a configured peer.
What Convery and Franz show us with their not quite exhaustive set of tests is that most BGP implementations are quite robust against blind attacks. An attacker must either be able to sniff traffic, so that reseting connections or hijacking can be successful, or the attacker must control a router. And it is this last area that actually produces the most concern.
Convery and Franz used a tool written for them by Mike Schiffman to search for potential BGP speaking routers on the Internet. Starting with the 120,000 CIDR addresses, they found IP addresses for 115,466 possible BGP speaking routers within the Internet core or edges. They then performed a SYN scan of the administrative ports, SSH, Telnet, and HTTP (22, 23, and 80) on all of these IP addresses. They discovered that an average of 14.5% of all addresses scanned would respond to one of these probes as if the port was open, and reachable from an arbitrary location. They also probed the BGP port, and found that about 4% of routers responded in some fashion.
Most of Convery and Franz's results show that an exploited router poses the greatest threat to BGP, and their scanning suggests that this may indeed be the most dangerous threat. The receipt of a SYN-ACK, the normal response to a SYN scan, does not prove that any of these routers would actually accept a connection--but it does suggest that best configuration practices (BCP) have not been applied. BCP includes only accepting administrative connections from known IP addresses, and this has obviously not been done. The authors wonder what other settings have been misconfigured in the 16,815 routers that had open administrative ports?
S-BGP and soBGP rely on digital certificates to authenticate routing information. But if the routers themselves can be compromised, the digitial signatures can only prevent bad routing information about networks these routers do not represent from spreading. And moving to such a system requires router upgrades to handle the encryption load added by certificates, as well as other infrastructure. Perhaps what is needed instead is for ISPs to secure their routers. Otherwise, secure versions of BGP will just be another bandaid.
The Convery and Franz paper about testing BGP implementations and Internet routers: http://www.nanog.org/mtg-0306/pdf/franz.pdf
Best Configuration Practices for Cisco IP routers: http://www.cisco.com/warp/public/126/configmgmt.html
Secure-BGP home page at BBN:
http://www.net-tech.bbn.com/sbgp/sbgp-index.html
Ingress and egress filtering RFC prevent source address spoofing (replaces RFC 2267): http://www.ietf.org/rfc/rfc2827.txt
The BGP TTL hack (254-255 TTL):
http://www.ietf.org/internet-drafts/draft-gill-btsh-02.txt
Cisco announces a bug (and a patch for it) in its BGP-4 implementation that can cause reloading, and thus Denial of Service, in routers configured to use BGP-4 and with bgp log-neighbor-changes enabled: http://www.cisco.com/en/US/products/products_security_advisory09186a00803be7d9.shtml
DefCon presentation in 2008 demonstrates a BGP hijacking attack, explained in this blog entry by Kim Zetter. The entry includes a link to the presentation by Anton "Tony" Kapela, data center and network director at 5Nines Data, and Alex Pilosov, CEO of Pilosoft, who uncovered and demonstrated this attack.
Kim Zetter's second blog entry, adding more details to the first.