Security Issues Affecting Internet Transit Points and Backbone

Providersbatz

batsy@vapour.net

Blackhat Briefings 1999

Introduction

Many sites believe that the only external threats to their network come from unsophisticated script kids or well funded corporate espionage projects. This problem is compounded by the underestimation of the former, and the belief that their organization is not of interest tothe latter.

The reality is that the stakes are raised substantially if the company in question is publicly traded. By allowing any investor with a computer and an online trading account to have a vested interest in their share price, the status and information contained on their network acquires thespeculative value of whatever capital an attacker would invest in the company.

With this motive established, we can examine some new threats and some existing threats in a new context. With the proliferation of online trading, new financial incentives exist for even the least sophisticated attacker to violate your network.

PREAMBLE:

The Internet is divided into routing policy domains called Autonomous Systems.

These are the political topographical regions of the Internet. Most organizations have only 1 Internet visible Autonomous System.

Many Internet providers charge their customer based upon the amount of bandwidth used over a set period.

To facilitate this, the ISP must have some mechanism for maintaining a reasonable QoS fortheir customer base.

ISP's use Border Gateway Protocol (BGP) protocols to route and optimize traffic flowing in and out of their networks.

The quality of that flow directly affects the quality of service their customers recieve.

To manipulate the flow of all traffic in and out of an ISP's network is to have complete control of the quality of service it can offer to its customers.

Border Gateway Protocol as defined in RFC1771 is a link state protocol used for communicating routing information between Autonomous Systems.

It requires TCP for transport between bgp speakers called peers and uses TCP port 179 for these connections.

BGP uses 4 kinds of messages during a session:

OPEN

UPDATE

NOTIFICATION

KEEPALIVE

OPEN:

The OPEN message contains the BGP version number (4 is current and most widely used), The Autonomous System Number(ASN) of the originator of the session, HoldTime which is the maximum time interval between KEEPALIVE, UPDATE and NOTIFICATION messages, The BGP Identifier which is the IP address that the source is establishing the connection for, and Optional Parameters which includes a field for the total length of the Optional Parameters field. It also carries authentication information that may be used between peers. If there is no authentication data present in the field, the Length will be 0.

UPDATE: This is the guts of the protocol as it carries routes and information about them. There are 5 fields in this message They are Unfeasable Routes Length, Withdrawn Routes, Total Path Attributes Length, Path Attributes and Network Layer Reachability Information (NLRI).

This information is the most relevant to our discussion as PathAttributes are really what causes a peer to make a particular decision about a route.

KeepAlive:

This is an empty BGP message whose name is describes its function. They are empty BGP messages sent to assure that the session does not time out. The interval between their transmission must be lessthan the configured Hold Time which is generally less than 90seconds.

BGP AttributesUsed to communicate information about a route being announced. These are relevant to the the decision process and are generally activated using communities which will be discussed shortly. The most common attributes are :

ORIGIN AS-PATH LOCAL_PREF ATOMIC_AGGREGATOR AGGREGATOR NEXT_HOP MULTI_EXIT_DESC

ORIGIN

ORIGIN attribute communicates information about whether the route was learned from the AS's IGP or from a peer, and will contain all relevant information about the source of the announcement.

LOCAL_PREF

The local preference attibute allows a BGP speaker to assign preference to routes learned from a particular peer. This information is not propagated outside the AS to external peers.

AS_PATH

AS_PATH is a list of ASN's that define the path to the origin of a route. These are known as AS hops. This information is the first attribute examined when deciding the metric or distance to a destination to decide the preference of a route.

ATOMIC_AGGREGATOR

ATOMIC_AGGREGATOR is used if a bgp speaker has preference set for a less specific route. This information must also be announced to all peers that the route is announced to.

ATOMIC_AGGREGATOR

ATOMIC_AGGREGATOR is used if a bgp speaker has preference set for a less specific route. This information must also be announced to all peers that the route is announced to.

AGGREGATOR

AGGREGATOR specifies that a route being announced has been aggregated, or may not be completely routed by the origin AS. This allows bgp speakers to summarize routes as not to clutter global tables with longer prefixes.

NEXT_HOP

NEXT_HOP is included in all UPDATE messages and carries the IP address of the originator of the announcement.

MULTI_EXIT_DISC

MULTI_EXIT_DISC advises adjacent bgp speakers that the originator of a route has multiple adjacencies to the destination AS.

BGP DECISION PROCESS

When a BGP speaker recieves a route the following decision process is performed on it:

Next Hop information is checked for reachability. If it is unreachable, the route is dropped.

Local Preference is checked to see if it is higher than other that of similar routes from other sources.

Check to see if the route originated locally within the recieving router. Choose route with shortest AS_PATH length.

BGP Decision Process Continued….

Check the ORIGIN of the route (in the order of IGP, EGP, or INCOMPLETE)

Compare MULTI_EXIT_DISC information for lowest value which will give confederation information.

Compare IGP information to see which path is shortest to next hop.

Use BGP Router ID (implementation specific). Cisco uses lowest ip address of the loopback addresses of the peers.

BGP Communities

These are defined locally within an AS and corespond to the assignment of attributes to routes being announced to them by their peers. This is also the case for AS's wanting to shape traffic coming into their network from their peers.

A network provider may be allowed to announce routes to a peer using the communities provided to them as a part of the peering agreement. Most NSP's have communities that are used internally and those that they allow external peers to use.

If a route is announced with the correct community, the recipient peer will alter the attriutes it assigns to the route.

Catastrophic Misconfiguration

The most well known example of damage caused by a misconfigured BGP peer can be described as follows.

- Routes from AS40 are transited by AS10 and AS20 respectively. - AS10 accepts anything it hears from AS40. - Both AS10 and AS20 send full Internet bgp tables to AS40.

- AS40 announces its internal routes which are redistributed from iBGP within the confines of its border routers.

- The problem arises when AS40 redistributes the full Internet Routing into its iBGP tables.

- The Internet Routing Table is then redistributed from iBGP (origin of IGP) to eBGP and then to AS10 and AS20 as originating within AS40.

AS40 is effectively announcing that the entire Internet originates within its network.

The result of this is that all Internet bound traffic from neighbouring AS's will saturate AS40's network and make the Internet inaccessible to any peer AS that is listening to this announcement.

This is why AS_PATH based filtering is a Bad Thing(tm)

More MisconfigurationAS10 is configured with the following errors:(See Appendix B)

AS_PATH based filtering for all peers and accepting all routes indiscriminately.

Does not configure filtering of RFC1918 or other AS's netblocks.Has IGP synchronization turned off.

Unspecific single route map that allows all peers to announce routes with all communities to them. The obscurity of the communities is the only thing preventing a peer from using them.

More misconfiguration Continued…

Redistributes IGP directly into BGP without filtering.

Does not aggregate routes.

Though it is impossible that a single peer may simultaneously have all of these errors in place, many providers have at least one or a combination of them.

Aggressive Routing AS10 has customer AS40 who is multihomed with a T3 to AS20 and a T3 to AS10.

AS10 assigns a LOCAL_PREF of 100 to all customer routes and assigns a LOCAL_PREF of 120 to routes learned from iBGP peers.

Both AS10 and AS20 charge customer AS40 using traffic statistics.

The trouble arises when AS20 announces all their routes to AS10 with the community 10:120.

-{253.1.0.0/16,AS40} is announced from AS40 to AS10 and AS20respectively.

-AS10 assigns a LOCAL_PREF of 100 to this route and announces it to it's peers as {253.1.0.0/16,AS40_AS10}.

-AS20 also assigns a LOCAL_PREF of 100 to the route and announces it to the it back to AS10 as 253.1.0.0/16 with an AS_PATH of AS40_AS20 and the community 10:120.

-AS10 assigns a LOCAL_PREF of 100 to this route and announces it to it's peers as {253.1.0.0/16,AS40, AS10}.

-AS20 also assigns a LOCAL_PREF of 100 to the route and announces it to the it back to AS10 as 253.1.0.0/16 with an AS_PATH of AS40_AS20 and the community 10:120.

- Because AS20 knows AS10's communities, they have AS10 is sending all traffic to the customer network and is being recieved by AS20 who is suddenly seeing a great deal of traffic heading down their customer link to AS40.

Depending on the amount of traffic on the link, this will either saturate the link causing a DOS or dramaticly affect the traffic statistics on the customers interface. This has been observed and unattended for periods of time exceeding a month.

This problem has been observed in the wild.

Propagation of Spoofed RFC1918 Addresses

AS20 has a dedicated customer who is using a packet filter on the border of their network using addresses in 10.0.0.0/8, the internet visible gateway of their filter is 253.1.2.1. The 10/8 route should be invisible to the rest of the internet.

AS40 has an evil user that connects via dialup.

AS40 redistributes their IGP (RIP) directly into BGP.

Evil user connects to an ISDN port in the dial pool and using routed or a simple perl script broadcasts 10.0/16 with a source of 253.1.2.1 to the terminal server.

Terminal server sends this information to the Core router which accomodatingly redistributes it to AS10 which in turn propagates the announcement to the target, AS20.

The route as propagated along the AS path to her target and she may now launch her scans from a safe distance, outside of the imediate administrative domain of her prey.

Evil user may also send a RIP update saying that she has 10.128/16 which effectively puts her within the 10/8 address space.

The core router does not synchronize and thus does not check reachability information of the route it learned from RIP.

The stray route will have to be manually cleared from the router as it will not receive another update from RIP, nor will it bother checking the status of the route within the IGP due to the lack of synchronization on the session.

Depending on the configuration of the packet filter (most are misconfigured) Ms. Evil is now free to scan, connect and otherwise abuse hosts behind the packet filter without having to use ip spoofing or any other methods that have limited success against current IP implementations.

Blackholes and Wormholes

Blackhole:

The most well known application of purposeful blackholing is Paul Vixie's MAPS RBL which announced offending netblocks to subscribers via ebgp-multihop where the offending routes next hop information would be changed to an address that would simply drop the packets.

The only difference between a blackhole and a wormhole is that a wormhole has a host that has the blackholed route assigned to an interface.

Blackholing a route involves announcing to your peers that you have a route to a network that you in fact do not. All peers that are listening to your announcement will send traffic destined to the offending network to your router, which will promptly send the packets careening into the bitbucket.

This method proved extremely effective in cutting down the amount of spam on the internet by shunning routes to providers that could not keep their users in check.

Legitimate blackholing can be accomplished by establishing a multi-hop bgp session with the source of the blackholed networks and maintaining an access-list of the routes that you wish to accept from the blackhole peer.

It is probably the most effective DoS attack thus far concieved on the Internet. It may be more effectively named a DoE attack which refers to Denial of Existance.

Wormhole:

There is no legitimate use for this. Creating a wormhole involves finding the route for a target network and attempting to propagate an announcemet that it in fact terminates on your own network, where a host with the wormholed networks been configured to respond to services that the target would ordinarily be providing.

I have called it a wormhole because the very fabric of the internet is being altered to create a direct path to another destination.

This can be most easily accomplished using the misconfigured IGP redistribution mentioned in a previous attack, or using forged UPDATE messages.

Most hijacking of networks so far has been done with DNS and in small volatile routing domains using RIP.

This has not been seen in the wild...yet.

Using IP spoofing to forge UPDATE Messages

Due to the fact that most BGP sessions are established over the same physical wire, forging the opening of a session would be exceedingly difficult if not impossible as it would be nessecary to disable responses from the spoofed interface, which must be traversed by the spoofed packet.

The only feasable OPEN attack would be against an EBGP-MULTIHOP session between two hosts with IP stacks that use predictable TCP sequence numbers and whos BGP implementation does not support authentication.

This leaves the possibility of inserting forged UPDATE messages into an existing session. An interesting feature of BGP is that UPDATE and KEEPALIVE packets are not required to contain a sequence number other than that of the TCP sequence number in the TCP header.

Authentication is only done at the beginning of the session in the OPEN sequence of the protocol.

UPDATE and KEEPALIVE messages must be transmitted in an interval less than a preconfigured HOLD TIMER which is recommended to be greater than 2 seconds. This leaves at least a 2 second window for the insertion of any information an attacker wishes into the TCP stream.

Using IP spoofing against modern versions of Cisco's IOS is not effective and thus they will not be vulnerable to the spoofing of UPDATE messages.

Implementations Supporting Authentication

Cisco's IOS allows the use of md5 for authentication of peers. IOS also has very random TCP ISN's and it would be extremely difficult if not impossible to insert a forged UPDATE message into a BGP session between two Cisco Routers. Information about how this authentication is done was not available to the author due to its proprietary nature.

Merit's free version of GateD goes through the motions of supporting authentication, but does not currently seem to have any strong authentication available. After going through the source looking for the authentication routine, it was observed that GateD only looks for astring of all 1's in the authentication field of the header of the OPEN message. A string of all 1's signifies to the BGP speaker that no authentication mechanism is present.

The GateD users manual states that there is an option called "noauthcheck" which allows for strings other than all 1's, but not to bother verifying whether they are at all important.

This simply allows for interoperability with implementations that support authentication and not to provide any actual security.

Though a number of vendors use GateD in their products, they are members of the GateD consortium and thus have access to more current revisions of the software. The author was not able to verify from documentation whether the current commercial version of GateDsupports proper authentication.

Recommendations

BGP is a robust protocol whose authentication mechanism is not widely implemented or used.

It is possible to arbitrarily alter paths on the Internet if proper precautions are not taken in the configuration of routers.

BGP routing tables are the definitive source of information about the internet and their integrity should be authenticated appropriately.

It is possible to insert false information into a peering session either by abusing misconfigured routers or actively inserting information into the peering session.

The consequences of a misconfigured or abused network can affect the global Internet. A properly filtered network will not be implicitly affected by a misconfigured or abused network.

All sites should filter RFC1918 netblocks.

All sites that have implementations that support authentication should use it.

Any IGP routes should be static routes that are inserted into bgp directly. i.e IOS's 'network' command.

Do NOT redistribute RIP into BGP.

Be Careful if you absolutely must redistribute BGP routes into your IGP. There are many design alternatives available.

BGP Communities directly affect the traffic on your network. Use them sparingly and only when specificly nessecary.

Do NOT assume the obscurity of your communities is adequate protection. .

Access to your core routers gives an excessive amount of power to an attacker, both over your network and over your peers.

Do NOT filter solely based upon AS_PATH information. This is more trust than anyone should have in any network.

Wait with bated breath for IPSec to be more widely implemented

Appendix A Further Reading

Halabi, Bassam, "Internet Routing Architectures", Cisco Press

Y. Rekhter & Tony Li, "A Border Gateway Protocol 4 (BGP-4)" RFC1771,

Huitema, Christian. "Routing in the Internet", Prentice Hall

Freedman, Avi. "BGP Routing Part I: BGP and Multi-Homing",http://www.netaxs.com/~freedman/bgp.html

P. Ferguson, Cisco Systems & D. Senie, BlazeNet Inc "Network IngressFiltering:Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC2267

Appendix B

This is the mockup of the configuration for the exchange router in AS10.

router rip version 1 ! ! ! network [....] no auto-summary ! router bgp 10 no synchronization redistribute rip subnets network [....] network [....] neighbor x.x.x.x remote-as 40 neighbor x.x.x.x version 4 neighbor x.x.x.x filter-list 1 in neighbor x.x.x.x distribute-list 50 out neighbor x.x.x.x route-map COMMUNITIY in neighbor y.y.y.y remote-as 20 neighbor y.y.y.y version 4 neighbor y.y.y.y filter-list 1 in neighbor y.y.y.y distribute-list 50 out neighbor y.y.y.y route-map foo in neighbor z.z.z.z remote-as 30 neighbor z.z.z.z version 4 neighbor z.z.z.z filter-list 1 in neighbor z.z.z.z distribute-list 50 out neighbor z.z.z.z route-map foo in !

!ip bgp-community new-format ip community-list 1 permit 40:80 ip community-list 1 permit 40:100 ip community-list 1 permit 40:120 ip community-list 1 deny

ip as-path access-list 1 permit ^40_ ip as-path access-list 1 permit ^20_ ip as-path access-list 1 permit ^30_ ! access-list 50 permit ip any any ! route-map foo permit 10 match community 80 set local-preference 80 ! route-map foo permit 20 match community 100 set local-preference 100 ! route-map foo permit 30 match community 120 set local-preference 120 !