Accurate Real-time Identification of IP Hijacking

Presented by Jacky Mak

OutlineProblem and ObjectivesInterdomain Routing and BGP BasicsAttack Model of IP HijackingReal-time Detection TechniquesImplementationEvaluationConclusion and Critique

The ProblemWhat is IP hijacking?

Stealing IP addresses belonging to other networks to:

Conduct malicious activities such as spamming and DoS attacksDisrupt the reachability of legitimate hosts in the stolen addresses

Also known as BGP (Border Gateway Protocol) hijacking or fraudulent origin attacks

The ProblemIP hijacking is not difficult!The current BGP protocol (RFC 4271) [1]

implements little authentication and assumes a significant level of trust between peering ASesIP hijacking may occur if an autonomous system (AS) advertises a prefix that it is not authorized to use either on purpose or by accident

The ProblemPublic incidents:

Feb 2008: Pakistan's attempt to block YouTube access within their country takes down YouTube entirely [2]

Jan 2006: Con-Edison hijacks big chunk of the Internet [3]

Dec 2004: TTNet in Turkey pretends to be the entire Internet [4]

Apr 1997: The misbehaving AS7007 brings down the whole Internet [5]

The ProblemNetwork providers could preclude customers from announcing routes for prefixes that they do not own. However:

Providers do not always know which address blocks their customers ownRoute filtering is impossible along peering edges because the information about the peers’customers are often not availableAs long as there is one provider that does not enforce filtering, IP hijacking can still occur

The ObjectivesWe want a solution to detect IP hijacking with these properties:

Timeliness – detect suspicious routing updates as soon as they occurAccuracy – minimize both false positives and false negativesScalability – does not require too much resources to monitor a large number of routing updates in real timePracticability – can be incrementally deployed without modifying infrastructure nor requiring support from networks

Interdomain Routing and BGP Basics

Autonomous System (AS)A set of routers that has a single routing policy, and that run under a single technical administrationViewed as a single entity from the outside worldEach public AS has a unique number (ASN) assigned by IANA. See RFC 1930ASNs were 16-bit until early 2007; 32-bit ASN is described in RFC 4893Routing information is exchanged between ASesvia an exterior gateway protocol such as BGP

Interdomain Routing and BGP Basics

Autonomous System (AS)Stub AS – an AS that is connected to only one other ASMultihomed AS – an AS that is connectioned to more than one ASTransit AS – an AS that provides connections through itself to separate networks. ISPs are always transit ASes.Peering – voluntary interconnection of ASes for the purpose of exchanging traffic without each party paying the other

Interdomain Routing and BGP Basics

Autonomous System (AS)Tier-1 ISPs’ backbones

Tier-2 ISPs

Tier-3 ISPs

Interdomain Routing and BGP Basics

BGPAllows a subnet to advertise its existence to the rest of the Internet and how to get thereASes exchange routing information over TCP connections over port 179ASes determine “good” routes to subnets based on the reachability information and on AS policies

Interdomain Routing and BGP Basics

BGPUses path vector routing instead of link-state routing (OSPF) or distance-vector routing (RIP)

Interdomain Routing and BGP Basics

The global routing table has over 200,000 entries as of later 2006

Attack Model of IP HijackingType-1: Hijack a prefix Type-2: Hijack a prefix and its ASType-3: Hijack a subnet of a prefixType-4: Hijack a subnet of a prefix and its ASType-5: Hijack along a legitimate path

1: Hijack a PrefixThe attacker announces the ownership of IP indexes that belong to some victim ASesMultiple Origin AS (MOAS) conflicts in routing table – the same prefix appears to have originated from both the original owner’s AS and the hijacker’s AS

1: Hijack a Prefix

1: Hijack a Prefix

2: Hijack a Prefix and its ASThe attacker announces a route to a prefix with an AS path that traverses its own AS to reach the victimThere is no MOAS conflict, but the route is still invalidThe attacker can easily intercept, modify, and insert traffic

2: Hijack a Prefix and its AS

Fake AS edge or routing policy violation

3: Hijack a Subnet of a PrefixSimilar to type 1, except the attacker only announces a subnet of an existing prefixThere is no directly observable MOAS without examining its supernet prefixsubMOAS

3: Hijack a Subnet of a Prefix

3: Hijack a Subnet of a Prefix

4: Hijack a Subnet of a Prefix and its AS

The attacker announces a path to reach the victim AS and a subnet of this AS’s prefixMost difficult to detect because it introduces neither MOAS nor subMOAS

4: Hijack a Subnet of a Prefix and its AS

5: Hijack along a Legitimate Path

Instead of forwarding the traffic to the expected next-hop network, the attacker intercepts traffic and originates traffic using the address block of the downstream networkMerely violate the rule of forwarding traffic based on its advertised routeCan be identified by traceroute easily

Real-time Detection Techniques

Fingerprinting-based consistency checks Type 1: Detection of prefix hijackingType 2: Detection of prefix and AS hijackingType 3: Detection of prefix subnet hijackingType 4: Detection of prefix subnet and AS hijacking

Fingerprinting-based Consistency Checks (FP Checks)

When IP hijacking occurs, a given IP address in the hijacked prefix may be used by different end hostsWe can check the consistency of destination hosts by verifying whether their properties matchTwo types of fingerprints: host-based and network based

Fingerprinting-based Consistency Checks (FP Checks)

Host OS properties – Nmap [6]

Starting Nmap 4.03 ( http://www.insecure.org/nmap/ ) at 2008-04-05 15:29 HKTInsufficient responses for TCP sequencing (0), OS detection may be less accurateInteresting ports on fortress.cse.cuhk.edu.hk (137.189.91.192):(The 1668 ports scanned but not shown below are in state: closed)PORT STATE SERVICE VERSION80/tcp open http Apache httpd 2137/tcp filtered netbios-ns138/tcp filtered netbios-dgm139/tcp filtered netbios-ssn443/tcp open ssl/http Apache httpd 21723/tcp filtered pptpDevice type: general purposeRunning: Sun Solaris 10OS details: SunOS 5.10 (sparc)

Nmap finished: 1 IP address (1 host up) scanned in 23.244 seconds

Difficulties: probe duration, load-balanced hosts, firewall, …

Fingerprinting-based Consistency Checks (FP Checks)

IP Identifier probing

Fingerprinting-based Consistency Checks (FP Checks)

IP Identifier probingIP ID should be unique for each IP datagram with the same source-destination to facilitate IP fragment reassemblyA common implementation is “global” IP ID, i.e., incrementing IP ID by 1 for every packet sent, regardless of the destination IPDifficulties: some systems use random IP ID or reset it to be 0; some systems set IP ID to unique across every connection or peer; not applicable if DF (Don’t Fragment) flag is set

Fingerprinting-based Consistency Checks (FP Checks)

IP Identifier probing – hping [7]

[root@xanadu hping2-rc3]# hping -c 5 www.cse.cuhk.edu.hkHPING www.cse.cuhk.edu.hk (eth1 137.189.91.192): NO FLAGS are set, 40 headers + 0 data byteslen=46 ip=137.189.91.192 ttl=250 DF id=6153 sport=0 flags=RA seq=0 win=0 rtt=1.9 mslen=46 ip=137.189.91.192 ttl=250 DF id=6154 sport=0 flags=RA seq=1 win=0 rtt=1.7 mslen=46 ip=137.189.91.192 ttl=250 DF id=6155 sport=0 flags=RA seq=2 win=0 rtt=1.7 mslen=46 ip=137.189.91.192 ttl=250 DF id=6156 sport=0 flags=RA seq=3 win=0 rtt=2.0 mslen=46 ip=137.189.91.192 ttl=250 DF id=6157 sport=0 flags=RA seq=4 win=0 rtt=1.8 ms

--- www.cse.cuhk.edu.hk hping statistic ---5 packets tramitted, 5 packets received, 0% packet lossround-trip min/avg/max = 1.7/1.8/2.0 ms

[root@labsupport hping2-rc3]# hping -c 5 www.cse.cuhk.edu.hkHPING www.cse.cuhk.edu.hk (eth0 137.189.91.192): NO FLAGS are set, 40 headers + 0 data byteslen=46 ip=137.189.91.192 ttl=252 DF id=6158 sport=0 flags=RA seq=0 win=0 rtt=20.0 mslen=46 ip=137.189.91.192 ttl=252 DF id=6159 sport=0 flags=RA seq=1 win=0 rtt=1474.2 mslen=46 ip=137.189.91.192 ttl=252 DF id=6160 sport=0 flags=RA seq=2 win=0 rtt=639.0 mslen=46 ip=137.189.91.192 ttl=252 DF id=6161 sport=0 flags=RA seq=3 win=0 rtt=58.2 mslen=46 ip=137.189.91.192 ttl=252 DF id=6162 sport=0 flags=RA seq=4 win=0 rtt=673.7 ms

--- www.cse.cuhk.edu.hk hping statistic ---5 packets tramitted, 5 packets received, 0% packet lossround-trip min/avg/max = 20.0/573.0/1474.2 ms

Fingerprinting-based Consistency Checks (FP Checks)

TCP timestamp probingThe TCP timestamp option specified by RFC 1323 [8]

used for measuring round-trip times, but it can also be used to estimate the uptime of the target hostTCP timestamp is set based on the internal clock of the machine’s TCP network stack which is reset upon system rebootThis virtual clock runs at a certain frequency ranging from 1Hz to 10kHzKnowing the frequency and the TCP timestamp, the system uptime can be inferred

Fingerprinting-based Consistency Checks (FP Checks)

ICMP timestamp probingThe ICMP timestamp reply contains the system time of the target host reported in millisecond [9]

Since many hosts are not synchronized with NTP, we can expect two different hosts likely to have noticeable differences in their clock and hence in their ICMP timestamp repliesDifficulties: many hosts do not reply to ICMP timestamp requests

Detection of Prefix Hijacking

1. For each prefix involved in MOAS conflicts, find all paths reaching the prefix

2. Build an AS path tree, rooted at the prefix3. Find a live host if possible in the prefix serving as

the probing target4. Select probe locations so that packets traverse

different AS paths and reach conflicting origin ASes

5. Perform FP checks6. Analyze obtained fingerprints to check for

mismatches implying potential IP hijack attacks

Detection of Prefix Hijacking

Challenge: how to select probe locations such that probe traffic goes into different origin ASes?Use the current best AS paths from publicly available BGP data to guide the selection Probe locations should be as close to the original ASes as possibleDifficulties:

Incomplete routing data to predict AS-level pathsLimited probe locations

Detection of Prefix and AS Hijacking

Edge popularity constraint: Suspicious if the AS edge has never been observed in other route announcements or there are few prefixes using routes traversing this edgeGeographic constraint: BGP peering sessions between two ASes almost always occur between routers colocated, but a fake AS edge can connect two geographically distant networks Relationship constraint: Use inferred AS relationship to identify obvious violations of routing policies within the AS paths

Detection of Prefix Subnet Hijacking

Customer-provider check: Providers will not intentionally hijack customer’s routes due to lack of economic incentivesCustomers are incapable of hijacking provider’s routes because traffic needs to first traverse the provider’s network, and providers can easily detect such routing announcementsUnlike peer to peer relationships, customer provider relationships can be viewed as transitiveNo AS path can traverse a customer-provider edge after a provider-customer or peer-peer edgeNo path can go through more than one peer-peer edge

Detection of Prefix Subnet Hijacking

Customer-provider check (continued): Edges appearing before the tier-1 AS in the AS path are all customer-provider edges (“up” edges) and edges appearing after the tier-1 AS must be all provider-customer edges (“down” edges)Legitimate AS paths must be valley-freeGiven the prevalence of AS paths containing tier-1 ISPs, this check reduces false positives of subMOAS cases with very low false positivesLow overhead and suitable for real-time monitoringDoes not deal with conflicts involving two provider ASeswho do not have a customer-provider relationship, so we need to resort to fingerprinting for the remaining cases

Detection of Prefix Subnet Hijacking

Reflect scan: Make use of predictable IP ID increment IP packet and IGP routing within victim AS which is unaffected by polluted BGP updatesUse IP spoofing to solicit traffic inside the victim ASThe target host will respond differently depending on whether the subMOAS is caused by hijackingDifficulties:

Need to identify a relatively idle host in the hijacked prefixThere is no ingress filtering for spoofed packets

Reflect Scan when Hijacking Occurs

Reflect Scan without Hijacking

Detection of Prefix Subnet and AS Hijacking

Continuously monitor new prefixes that are subnets of existing prefixes in the routing tableApply similar checks for type-2 attacks: edge popularity constraints, geographic constraints, and relationship constraints (EGR constraints)Apply reflect scan probing to deal with the remaining cases that violates the previous checksWe can still achieve real-time monitoring given that the space of suspicious cases for this attack type only include new prefixes not present in the current routing tables

Summary of Detection Techniques

ImplementationSystem Architecture:

Monitor module: processes BGP updates in real time to identify potential IP hijackingProbing module: takes input from the Monitor module and selects corresponding probing techniques. It chooses the appropriate probing locations and launches probing to the target prefixDetection module: analyzes and compares the probe results to identify real hijacking incidents

ImplementationSystem architecture:

ImplementationClassification of hijack types:

ImplementationBGP data set:

University of Oregon RouteViews Server [10]

peering with 57 BGP routers in 46 different ASes: Larger coverage but 2-hour lag Used to evaluate the prototype system’s scalability and efficiency in processing large number of BGP updates

University of Michigan’s route monitor peering with 7 BGP routers in 7 distinct ASes including academic and commercial networks:

Smaller coverage but real time updatesUsed to study timely responses to anomalous updates

ImplementationProbe location selection:

Planetlab [11] testbed is used as the probing places for both type-1 and type-2 atackes

642 machines in 179 different ASes including 3 tier-1 ISPsAble to find probing locations for 89% MOAS cases and 75% type-2 attack cases

Reflect scans can be conducted anywhere as long as IP spoofing is not blocked

ImplementationLive IP addresses for probing:

Collected by combining locally collected DNS and Web server logsUsed reverse DNS to look up authoritative DNS servers and mail servers of various domainsUsed light-weight ping sweeps for a very limited address range if unable to find a live host from the list1,165,845 unique IP addresses collected: allowing to find 70.3% target hosts for all prefixes in MOAS conflicts, 55.2% for type-2 attacks, 71.0% for subMOAS conflicts, and 90.1% for type-4 attacks

ImplementationGeographic information of prefixes:

Used the NetGeo [12] database to map IP addresses and AS numbers to geographic locationsNetGeo returned detailed longitude and latitude values for 98.4% of 198,146 prefixes queried

EvaluationSystem Performance

Update rate:Maximum: 12 updates/secondMinimum: < 1 update/secondAverage: 2.45 updates/secondA workstation machine can easily handle such update rates for many BGP feeds

EvaluationSystem Performance

Anomaly rate:

EvaluationSystem Performance

Probing time:

In general, probing takes less than 10 minutesAverage time is less than 3 minutes for Nmapand 4 minutes for reflect scan

EvaluationSystem Performance

Memory usage:The prototype system is implemented using both Perl and C and runs on a desktop computer with P4 3.2GHz CPU and 1.5GB memoryFor RouteViews data, it uses 66% of total memoryFor real-time BGP data, it uses less than 7% of total memory

EvaluationFeasibility of probing techniques:

IP ID probing: for each OS, we can always select appropriate probing technique to ensure the IP ID reply is globally sequentialTCP/ICMP timestamp probing: both ICMP and TCP timestamp are supported by all of them except Windows XP and Cisco routers. Some routers also disable ICMP timestamp replies.

EvaluationFeasibility of probing techniques:

EvaluationEffectiveness of customer-provider checking:

Using a tier-1 ISP list obtained based on [13], on average 84.4% of all AS paths in RouteViewsdata contains at least one tier-1 AS, and this increases to than 96% for the locally collected BGP data.Therefore the proposed customer-provider heuristic is fairly effective at eliminating valid subMOAS conflicts, also demonstrated in Table II.

EvaluationMonitoring results:

Obtained from over 111 hours of real-time monitoring across 8 days. The rate is averaged over all 7 feeds monitored:

EvaluationSuspicious MOAS conflicts:

EvaluationSuspicious type-2 attacks:

EvaluationSuspicious type-2 attacks:

EvaluationSuspicious subMOAS attacks:

Prefix 193.140.140.0/24 is announced by AS15390 at 21:27 April 25th, 2006, which has a subMOAS conflict with prefix 193.140.0.0/16 owned by AS8517:

ConclusionA framework for accurate, real-time IP hijacking detectionBased on the insight that a real hijacking attack will result in conflicting data-plane fingerprints describing the hijacked networkSignificantly reduce false positives without sacrificing efficiencyCan be incrementally deployed without modifying any infrastructure nor requiring support from networks

Further Works and CritiqueFP efficiency and difficulties caused by firewalls and load balancingLimited by the availability of suitable probing locationsContinuous monitoring?Performance-triggered probing?How to notify the victim?

References[1] RFC 4271 – Border Gateway Protocol 4 (BGP-4)http://www.ietf.org/rfc/rfc4271.txt

[2] Pakistan hijacks YouTube http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube_1.shtml

[3] Con-Ed Steals the 'Net http://www.renesys.com/blog/2006/01/coned_steals_the_net.shtml

[4] TTNet in Turkey hijacks the Internet http://www.renesys.com/blog/2005/12/internetwide_nearcatastrophela.shtml

[5] Murphy's Law Strikes Again: AS7007 http://lists.ucc.gu.uwa.edu.au/pipermail/lore/2006-August/000040.html

[6] Nmap http://nmap.org/

[7] hping http://www.hping.org/

References[8] RFC 1323 – TCP Extensions for High Performancehttp://www.ietf.org/rfc/rfc1323.txt

[9] RFC 792 – Internet Control Message Protocolhttp://www.ietf.org/rfc/rfc792.txt

[10] University of Oregon Route Views Archive Projecthttp://www.routeviews.org/

[11] PlanetLab http://www.planet-lab.org/

[12] NetGeo – The Internet Geographic Databasehttp://www.netgeo.com

[13] Subramanian et al. Characterizing the Internet hierarchy from multiple vantage points. In Proc. IEEE INFOCOM, 2002.