660 likes | 811 Views
Security Issues Affecting Internet Transit Points and Backbone Providers. batz batsy@vapour.net Blackhat Briefings 1999. Introduction.
E N D
Security Issues Affecting Internet Transit Points and Backbone Providers batz 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 to the 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 the speculative 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 Path Attributes 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 less than the configured Hold Time which is generally less than 90 seconds.
BGP Attributes Used 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.
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 Misconfiguration AS10 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 AS20 respectively.
-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.