Sagar Vemuri (slides, courtesy Z. Morley Mao and Mohit Lad) IP hijacking Sagar Vemuri (slides, courtesy Z. Morley Mao and Mohit Lad)

Agenda What is IP Hijacking? Types of IP Hijacking Detection and Notification of IP Hijacking Accurate real-time identification of IP hijacking PHAS: A Prefix Hijack Alert System

Dynamic adaptation Internet routes IP traffic : Routing session routes Control plane: exchange routes Internet Data plane: forward traffic Fail over to alternate route IP traffic Bear.eecs.umich.edu IP=141.212.110.196 Prefix=141.212.0.0/16 www.cnn.com IP=64.236.16.52 Prefix=64.236.16.0/20

What is IP Hijacking Stealing IP addresses belonging to other networks Also known as BGP Hijacking, Fraudulent origin attack Achieved by announcing unauthorized prefixes on purpose or by accident

IP Hijacking Example

Motivation for IP hijacking Conduct malicious activities Spamming, illegal file sharing, advertising Disrupt communication of legitimate hosts DoS attacks Inherent advantage Hide attacker’s identities Difficult for trace back

Hijacked IP Space for selling

MOAS Multiple Origin AS Conflicts arise if different origin ASes announce the same prefix A prefix is usually originated by a single AS But several legitimate conflicts also exist multi-homing without BGP using private AS numbers A prefix is usually originated by a single AS according to RFC1930: “Guidelines for creation, selection and Registration of an AS” A Private AS number should be used if an AS is only required to communicate via BGP with a single provider. As the routing policy between the AS and the provider will not be visible in the Internet, a Private AS Number can be used for this purpose. The IANA has reserved AS64512 through to AS65535 to be used as private ASNs.

subMOAS Subnet of an existing prefix is announced by a different origin AS Example: AS1 announces 164.83.0.0./16 and AS2 announces 164.83.240.0/24 Globally propagated and used BGP uses longest prefix based forwarding of routes

Classification of hijacking Hijack only the prefix Hijack both the prefix and the AS number Hijack a subnet of an existing prefix Hijack a prefix subnet and the AS number We first provide a classification of IP hijacking scenarios, introducing several attack types previously overlooked. The comprehensive attack taxonomy provides the foundation for our discussion on detection and the explanation for attacker’s motivations. Each one has its own specific symptom

Hijacking only the prefix Attacker announces the prefix belonging to other ASes using his own AS number. Leading to MOAS (Multiple Origin AS) conflicts

Hijack both the prefix and AS Announce a path through itself to other ASes and their prefix AS M announces a Path [AS M, AS 1] to reach prefix 141.212.110.0/24

Hijack a subnet of an existing prefix In previous attack models, the hijacker has to compete with victim to attract traffic. Announcing only a subnet of other’s prefix avoids the competition altogether due to the Longest Prefix Matching rule of BGP No apparent MOAS Conflicts in routing table! Because routing table is prefix based, they are not the same prefix subMOAS!

Hijack a subnet of a prefix and AS number Announce a path to a subnet of one of victim AS’s Prefix No subMOAS conflicts! Most stealthy with almost no abnormal symptom in routing table Ability to receive all traffic because of longest prefix matching Globally propagated and used Combine the advantage of hijacking a subnet and hijacking AS number to further reduce the ris

Hijacking along a legitimate path Path to the destination goes through the attacker’s AS Violates the rule of forwarding traffic Instead of forwarding the traffic, the attacker intercepts the traffic Originates new traffic as if coming the legitimate source Combine the advantage of hijacking a subnet and hijacking AS number to further reduce the ris

Prevention Techniques … 1 Route Filtering Analogous to ingress/egress filtering for traffic Filter route announcements to preclude prefixes not owned by customers Proper configuration of route filters at links b/w providers and customers

Prevention Techniques … 2 Difficulties with Route Filtering Lack of knowledge of address blocks owned by customers Difficult to enforce across all networks Filtering impossible along peering edges SHOULD be enforced properly by all the providers

Prevention Techniques … 3 Digitally sign routing updates High overhead in terms of memory, CPU and additional management Store a list of originating ASes Such a list is unauthenticated and optional Prefer a set of known stable routes over transient routes Does not scale well to arbitrary routes Due to lack of information on addresses allocated to customers belong to one’s peers

Data plane and control plane Control plane: controls the state of network elements Route selection Disseminate connectivity information Optimal path selection Data plane: determines data packet behavior Packet forwarding Packet differentiation (e.g., ACLs) Buffering, link scheduling There are two planes at which msgs propagate: Control plane and Data plane.

Consistency between them (Routing) state advertised by the control plane is enforced by the data plane Inconsistency due to Routing anomalies Misconfigurations Protocol anomalies Malicious behavior Main insight: use expected consistency to identify routing problems.

Accurate real-time identification of IP hijacking Xin Hu Z. Morley Mao

Approach Goal: Approach: Detect and thwart potential IP hijacking attempts Light-weight and real-time detection Approach: Real-time monitoring and active/passive fingerprinting triggered by suspicious routing updates Identify conflicting data-plane fingerprints indicating “successful” IP hijacking Given the above difficulties and possibility of compromised nodes, Our work focuses on real-time detection of ongoing IP hijacking events as soon as they occur rather than postmortem analysis. Online detection enables timely mitigation responses in the form of blocking malicious hijacking our work benefits significantly from various fingerprinting approaches to characterize end hosts and possibly networks: for example, OS-based fingerprinting using tools such as nmap [25] and xprobe2 [26], physical device fingerprinting by identifying clock skews [27], timestamp-based information using TCP and ICMP timestamp probing, as well as IP ID probing commonly used for counting hosts behind NAT [28].

Methodology Monitor all route updates in real time Given suspicious updates, use data-plane fingerprinting to reduce false positive/negative rate Our key insight: A real hijacking will result in conflicting fingerprints describing the edge networks

Fingerprinting Technique for remotely determining the characteristics or identity of devices A given IP address in the hijacked prefix is used by different end hosts Faking a fingerprint is extremely difficult and challenging

Fingerprinting … 2 Host-based Network-based Operating System Actual physical device Host software Host services Network-based Firewall properties Bandwidth information

Fingerprinting … 3 The system employs four main type of fingerprints: OS detection IP ID probing TCP round trip time ICMP timestamp

Probe place selection From a single place, the probing packets can only reach either attacker’s or victim’s AS, not both. To probe both, we need multiple probing points. Use Planetlab, which consists of more than 600 machines all over the world. Select probing places that are near the targets, in terms of AS path.

Detection of hijacking a prefix Candidates are prefixes that have MOAS conflicts. Build path tree for the prefix: Select Planetlab nodes near different origin ASes and probing live hosts in the prefix

Detection of hijacking a prefix and AS number Candidates are BGP Updates that violates Geographical constraint Edge popularity Constraint The invalid path announced by attacker will be very likely to violate these constraint Geographical location of prefixes and ASes can be obtained from a number of commercial and public database such as IP2Location, Netgeo Netgeo Record for prefix 141.212.0.0/16 Edge popularity constraint: To retain the origin AS, an attacker may fake an AS edge between its AS and the victim AS. We identify such anomalies for computing the popularity of an AS edge. If the AS edge has never been previously observed in other route announcements or there are few prefixes using routes traversing this edge, it is highly suspicious. Geographic constraint: Similar to the above constraint, an fake AS edge can connect two geographically distant networks. BGP peering sessions between two ASes almost always occur between routers physically colocated. Thus, an AS edge corresponding to two distant networks signals an alarm. |141.212.0.0/16|237| COUNTRY: US NAME: UMNET2 CITY: ANN ARBOR STATE: MICHIGAN LAT: 42.29 LONG: -83.72

Detection of hijacking a subnet of prefix -- Reflect scan During hijacking, the reflected SYN/ACK packet will not reach H2 IP ID value of H2 will not increase. If not hijacking, the reflected SYN/ACK packet will be sent to H2 IP ID value of H2 will increase

Detection of hijacking a prefix subnet and AS number Candidate is every new prefix that is a subnet of some prefix in its origin AS. To detect, combine Geographical constraint Reflect scan

System architecture

Classifier For each BGP update, classifier decides whether it is a valid update and classify those invalid updates into separate types Then feed the classification results to probing module for selecting proper probing methods

Different signatures, example: 63.130.249.0/24|63.130.249.1|1273 3561|1273:planetlab-1.eecs.cwru.edu 3561:node1.lbnl.nodes.planet-lab.org planetlab-1.eecs.cwru.edu: Interesting ports on 63.130.249.1: (The 1664 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 23/tcp open telnet 1214/tcp filtered fasttrack 6346/tcp filtered gnutella 6699/tcp filtered napster No exact OS matches for host … node1.lbnl.nodes.planet-lab.org: Interesting ports on 63.130.249.1: (The 1663 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 7/tcp open echo 9/tcp open discard 13/tcp open daytime 19/tcp open chargen 23/tcp open telnet No exact OS matches for host …

K-root server results Local Machine [root@wing statistic]# nmap -O 193.0.14.129 Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port Interesting ports on k.root-servers.net (193.0.14.129): (The 1667 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE 53/tcp open domain Device type: general purpose Running: Linux 2.4.X|2.5.X OS details: Linux 2.4.0 - 2.5.20 Uptime 26.048 days (since Thu Mar 23 06:17:24 2006) Nmap finished: 1 IP address (1 host up) scanned in 43.319 seconds Planetlab in China bash-2.05b# nmap -O 193.0.14.129 Interesting ports on k.root-servers.net (193.0.14.129): (The 1664 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 53/tcp open domain 179/tcp open bgp 2601/tcp open zebra 2605/tcp open bgpd Device type: general purpose Running: FreeBSD 5.X|6.X OS details: FreeBSD 5.2-CURRENT - 5.3 (x86) with pf scrub all, FreeBSD 5.2.1-RELEASE or 6.0-CURRENT Uptime 119.383 days (since Mon Dec 19 22:13:54 2005) Nmap finished: 1 IP address (1 host up) scanned in 15.899 seconds

Limitations No proper way to inform the owner of the legitimate prefix/AS Accuracy of fingerprinting techniques Choosing a probing location might be difficult

PHAS: A Prefix Hijack Alert System Dan Massey and Yan Chen Colorado State University Mohit Lad, Lixia Zhang UCLA Beichuan Zhang University of Arizona

Necessities for a viable Detection system Ability to see the “bad” information Use BGP Data Collectors (like RouteViews) Ability to distinguish between “good” and “bad” information Prefix owner knows legitimate origin, suballocations, and last hop. Incentive to fix the problem if one is found Prefix owner is affected directly Necessities for a viable detection system

Objectives of PHAS Goal: Report origin changes If a new origin appears, report immediately Potential Attack If an origin has not been in use for “some time”, report origin removal. Attack stopped. Prevent replay attacks. Why not report origin removals immediately? Origins very dynamic. Most of the dynamics are legitimate. Necessities for a viable detection system

RouteViews based PHAS Step 1: Monitor RouteViews BGP tables and updates in (near) Real-Time Step 2: Keep a database of Origins used to reach each Prefix Step 3: Report any change in Origins used to reach the Prefix Step 4: Owner applies local filter rules to determine significance

Components of PHAS

Email Registration The owner should first register with the PHAS to get notifications Attacker registers as owner PHAS alarms are based on public information Attacker tries to unsubscribe or modify owner registration Slice secret and send one part to each mailbox. Require all parts assembled to confirm change.

Origin Monitor Origin set: Set of origins seen by all the monitors P= 65.173.134.0/24 Path=D A Q P=65.173.134.0/24 Path=D X 1:05 1:00 Data Collector D P= 65.173.134.0/24 Path=B A Q Origin set: Set of origins seen by all the monitors B Origin Set Prefix Origin set 65.173.134.0/24 {Q} ALARM: Origin set for 65.173.134.0/24 changed {Q,X} Instantaneous origin set has lots of dynamics

Message Delivery PHAS detects origin change for prefix 65.173.134.0/24 Q Hijacker True origin C B Alarm can be delivered to hijacker instead of true origin. Z Y RV PHAS Problem: One or more nodes on path from PHAS to origin could believe the hijacker.

Multipath Delivery Origin specifies multiple “webmail” servers {A,B,C} as intermediate storage points A PHAS Origin B C ? Hijacker It is difficult for hijacker to compromise all paths, i.e. cut this graph.

Message Delivery WebMail B 131.179.0.0/16 D A X 131.179.0.0/16 Q ? Hijacker UCLA C C is affected by hijack, but since WebMail A and B are not hijacked, C delivers to WebMail. B Z Y RV WebMail A PHAS If no mailbox can be reached, then ALARM raised

Local Notification Filter Deployed at the user side Reduce false positives Task 1: Deliver only one copy of alarm to mailbox. Task 2: Simple Filter rules IF ORIGIN-GAINED EQ 562 THEN REJECT IF TYPE=LOSS THEN REJECT

Customizing PHAS Notifications PHAS Delivers Text Data in a Simple Format: SEQUENCE_NUMBER: 1160417987 TYPE: origin BGP-UPDATE-TIME: 1160396231 PHAS-DETECT-TIME: 1160414387 PHAS-NOTIFY-TIME: 1160417987 PREFIX: 60.253.29.0/24 SET: 30533 GAINED: LOST: 33697 Readable By People, But Intended for Scripts Script receives notifications and applies local policies

Limitations Cannot identify subnet hijacking attacks Cannot identify last hop hijacks Prefix in routing table: 131.179.0.0/16, with origin Q Hijacker X announces a false link to Q. Leave corrective action for prefix owner Prefix owner knows what is legitimate and what is not.

Conclusion Both papers deal with detection of IP Hijacking First appraoch: detects in Real-time Second approach: might involve some delay PHAS also sends notifications to the user to take corrective action Can combine both the approaches to be more effective: detection + notification