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.
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 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.
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 a
string 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 GateD
supports 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 Ingress
Filtering: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
!