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

: Routing session

routes Control plane:exchange routes

Bear.eecs.umich.eduIP=141.212.110.196

Prefix=141.212.0.0/16

www.cnn.comIP=64.236.16.52

Prefix=64.236.16.0/20

Internet

IP traffic

Data plane:forward traffic

Fail over to alternate route

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

Victim ASAS 1

AS 1: I am the onwerof 141.212.110.0/24

Attacker’s ASAS M

AS M: I am the ownerof 141.212.110.0/24

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

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

Hijacking only the prefix Attacker announces the prefix

belonging to other ASes using his own AS number.

Leading to MOAS (Multiple Origin AS) conflicts

Victim ASAS 1

AS 1: I am the onwerof 141.212.110.0/24

Attacker’s ASAS M

AS M: I am the ownerof 141.212.110.0/24

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

Victim ASAS 1

AS 1: I am the onwerof 141.212.110.0/24

Attacker’s ASAS M

AS M: I have a path tothe owner of

141.212.110.0/24

Invalid Path

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!

Victim ASAS 1

AS 1: I am the onwerof 141.212.0.0/16

Attacker’s ASAS M

AS M: I am the ownerof 141.212.110.0/24

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

Victim ASAS 1

AS 1: I am the onwerof 141.212.0.0/16

Attacker’s ASAS M

AS M: I have a path tothe owner of

141.212.110.0/24

Invalid Path

Globally propagated and used

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

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

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

Consistency between them Consistency

(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 HuZ. Morley Mao

Approach Goal:

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

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

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

|141.212.0.0/16|237|COUNTRY: US NAME: UMNET2 CITY: ANN ARBORSTATE: MICHIGAN LAT: 42.29 LONG: -83.72

Detection of hijacking a subnet of prefix -- Reflect scan

Probing Machine141.212.110.75.

H2 195.6.203.3

Attacker’s AS 2Victim AS 1

H‘2 195.6.203.3H1 195.6.216.26

P1 195.6.0.0/16 P2 195.6.203.0/24

1. SYN/ACK Src IP: 141.212.110.75

2. RST IP ID = 1234

3. SYN to port 80 Src IP: 195.6.203.3

4.SYN/ACK Src IP: 195.6.216.26

5.RST IP ID = 6789

6. SYN/ACK Src IP: 141.212.110.757. RST

IP ID = 1235

Probing Machine141.212.110.75.

H2 195.6.203.3

AS 2AS 1

H1 195.6.216.26

P1 195.6.0.0/16P2 195.6.203.0/24

1. SYN/ACK Src IP: 141.212.110.752. RST

IP ID = 1234

3. SYN to port 80 Src IP: 195.6.203.3

4. SYN/ACK Src IP: 195.6.216.26

5. RST IP ID = 1235

6. SYN/ACK Src IP: 141.212.110.757. RST

IP ID = 1236

a) Hijacking Attacks b) No Hijacking Attacks

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

Hijacking Prefix

Hijacking Prefix& AS number

Hijacking subsetof Prefix

Hijacking subset ofPrefix & AS number

Valid Updates

Monitor Module

BGP Updates

Potential Hijacking

Probing Module

OS Detection

IP ID Probing

TCP Timestamp

ICMP Timestamp

IP ID Idle Scan

Detection Module

Probing Results

Raise Alarms ofHijacking attacks

Classifier

Probing Targets

ClassifierBGP Update

New Prefix Y

N

MOASYPotential Hijacking

of Prefix

N

Violate TopologicalConstraints

YPotential Hijacking ofPrefix & AS number

N

Subset ofexisted prefix

Y Potential Hijackingof subset of Prefix

Y

subMOAS

YPotential Hijackingof subset of Prefix

& AS number

N

Valid Update

N

Violate TopologicalConstraints

N

In Bogon list

N

Y

Hijacking ofunallocated Prefix

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 SERVICE23/tcp open telnet1214/tcp filtered fasttrack6346/tcp filtered gnutella6699/tcp filtered napsterNo 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 SERVICE7/tcp open echo9/tcp open discard13/tcp open daytime19/tcp open chargen23/tcp open telnetNo exact OS matches for host

…

K-root server resultsPlanetlab in Chinabash-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 SERVICE53/tcp open domain179/tcp open bgp2601/tcp open zebra2605/tcp open bgpd

Device type: general purposeRunning: FreeBSD 5.X|6.XOS 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

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 SERVICE53/tcp open domain

Device type: general purposeRunning: Linux 2.4.X|2.5.XOS details: Linux 2.4.0 - 2.5.20Uptime 26.048 days (since Thu Mar 23 06:17:24 2006)Nmap finished: 1 IP address (1 host up) scanned in 43.319 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 ChenColorado State University

Mohit Lad, Lixia ZhangUCLA

Beichuan ZhangUniversity 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

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.

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

D

B

Data Collector

P= 65.173.134.0/24 Path=D A Q

P= 65.173.134.0/24 Path=B A Q

Origin Set

Prefix Origin set

65.173.134.0/24 {Q}

Origin set: Set of origins seen by all the monitors

P=65.173.134.0/24 Path=D X

{Q,X}

ALARM: Origin set for 65.173.134.0/24 changed

Instantaneous origin set has lots of dynamics

1:001:05

Message Delivery

A

Q

B

X

Y

D

C

ZRV

PHAS

Hijacker

PHAS detects origin change for prefix 65.173.134.0/24

Alarm can be delivered to hijacker instead of true origin.

Problem: One or more nodes on path from PHAS to origin could believe the hijacker.

65.173.134.0/24

True origin

65.173.134.0/24

Multipath Delivery

PHAS Origin

A

C

B

Hijacker

It is difficult for hijacker to compromise all paths, i.e. cut this graph.

?

Origin specifies multiple “webmail” servers {A,B,C} as intermediate storage points

Message Delivery

If no mailbox can be reached, then ALARM raised

WebMail A

WebMail B

A

Q

B

X

Y

D

C

Z

UCLA

131.179.0.0/16

131.179.0.0/16

RV

PHAS

Hijacker

C is affected by hijack, but since WebMail A and B are not hijacked, C delivers to WebMail.

??

?

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: 1160417987TYPE: originBGP-UPDATE-TIME: 1160396231PHAS-DETECT-TIME: 1160414387PHAS-NOTIFY-TIME: 1160417987PREFIX: 60.253.29.0/24SET: 30533GAINED: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