Fragmentation Considered Vulnerable Yossi Gilad & Amir Herzberg - PowerPoint PPT Presentation

Fragmentation Considered Vulnerable Yossi Gilad & Amir Herzberg Computer Science Department, Bar Ilan University

Overview  IP fragmentation recap  `Easy case’ fragment miss -association attacks  Fragmentation attacks in tunnels  Conclusions

IP Fragmentation - Recap  Today: attacks on IP fragmentation  Blind (spoofing only) attacker  Interception and DoS attacks.  The Internet is a diverse network  Different Maximal Transmission Units (MTUs) on different links/nets  What if |long-pkt|>MTU? LongPkt LongPkt MTU Alice Router Router Router Defragment (fragment)

IP Fragmentation - Recap  Solution 1: Path MTU discovery (PMTUd)  Discard oversized pkt, inform sender (via ICMP)  Requires connection  Solution 2: IP fragmentation  ‘Break’ long pkt into fragments (|frag|<MTU)  Fragment at: any node (IPv4) / only src (IPv6)  Defragment: only at destination  According to: source, destination, protocol & frag ID Long Pkt Long Pkt Long Pkt LongPkt LongPkt MTU Alice Router Router Router Bob (fragment) (Defragment)

‘Fragmentation considered Harmful’  IP fragmentation is conceptually easy, but…  Wasteful/harmful [KentMogul87]  Complexities: may arrive late or out of order, overlap  How much storage? How long keep fragments in cache?  But: still often used  PMTUd often fails (for UDP, no ICMP feedback,…)  Fragmentation is common in UDP and tunneled traffic [Shannon02]

‘Fragmentation considered Harmful’  Implementation vulnerabilities:  Memory allocation DoS attacks: TearDrop, Rose…  Tiny fragment evasion of firewalls  Specification vulnerabilities:  Fragment cache overflow attack [KPS03]  Zalewski (2003) notes that fragmented TCP traffic can be vulnerable to (blind) TCP injections  Fragment mis-association attack [M04,rfc4963]

Fragment Misassociation Attack MTU= MTU= 1500B 1000B SrcIP=Alice, Dst=Bob, ID=1, Offset=980, MF=0 SrcIP=Alice, Dst=Bob, ID=2, Offset=980, MF=0 …. SrcIP=Alice, Dst=Bob, HDR+1480B ID=b, Offset=980, MF=0 (ID=x) HDR+980B, ID=x, offset=0 (if x≤b) HDR+500B, ID=x, offset=980 (stays in cache till timeout or kills next ID=x frg) Fragment mis-association attack: But, Send fake 2 nd frag with same ID… |cache|<<#frags (drop%<<1%)

What if…  Frag mis-association has low drop rate  What if attacker can find the `next’ ID?  Trivial to `kill’ packet (DoS)  Can also `inject’ a fragment  Need to fix checksum  Checksum can be disabled for UDP  How is the IP ID chosen (by the sender)?  Usually a counter – this is specifically recommended by IPv6 specification  Two main approaches:  Global counter (Windows)  Per-destination counter (Linux)

Sometimes, ID Exposing Is Easy  When the sender uses a global identifier  Just by observing any packet from the sender  When the attacker has a zombie behind the NAT with the destination  Can also intercept fragments! Rewrite transport layer header 

Sometimes, ID Exposing Is Easy Intercepting fragments SrcIP=Alice, DstIP=NAT, ID=i+1, Offset=1480, MF=0 A. Src-IP=Alice, Dst-IP=NAT, ID=i+1, Offset=0, MF=1, Dst- port: Bob’s discarded B. SrcIP=Alice, DstIP=NAT, ID=i+1, Offset=1480, MF=0 cached SrcIP=Alice, DstIP=NAT, ID=i+1, Offset=0, MF=1, Dst- port: Zombie’s, No chksum mis-associated with Alice frag. B Defrag & forward to Zombie

Fragment Interception: Results  Results for IP tables based NAT 92.00% Fragment interception ratio 90.00% 1024 fragments are in 88.00% the cache 64 fragments are in the 86.00% cache 84.00% 82.00% 80.00% 0 20 40 60 80 100 Attacker's bandwidth mbit/sec

Other Cases?  Can similar attacks apply when sender uses per-destination IP-IDs?  Easy: if there is NAT (shown before)  What if there is no NAT?  Yes!  For a tunnel scenario

ID Exposing Attack  Alice and Bob are connected via a tunnel  Main difference from NAT scenario:  Packets `on the Internet’ have a different IP header Adversarial agent, PuZo, can not `see’ the `Internet’ ID   Improved motivation: fragmentation is common in tunnels  In talk: Zombie (to receive raw IP packet)  In paper: Puppet (running in sandbox)

ID Exposing Attack  Use packet loss as a side channel to identify the current ID within the tunnel  We assume no benign traffic or packet loss  Full version shows how to deal with those

ID Exposing Attack – Basic Version S GW B PuZo GW A Begin Get File Mis- associated

ID Exposing Attack – Basic Version S GW B PuZo GW A . . . . . . . . . . . .

ID Exposing Attack - Meet in the Middle  But… if n is the number of possible identifiers, this attack requires to send O(n) packets.  2 16 for IPv4, for 2 32 IPv6  Revise with meet in the middle technique

ID Exposing Attack - Meet in the Middle  Send fragments  lay traps n n  Narrow the search space to n  Detect loss  assume `ID hit’ (frag. mis -association)  Exhaustive search over all remaining IDs  Reduced number of packets to O( ) n  Also feasible for IPv6 (n = 2 32 )

Continual Deny & Expose  Mal has the current ID  Goal: deny fragmented traffic  Main Difficulty: maintain synchronization with current IP ID  Incremented for every packet (regardless of arrival/loss)

Continual Deny & Expose  Basic idea: use PuZo to `monitor’ IP ID progress  Send two sequences of spoofed fragments with consecutive IDs  Small `gap’ of unset IDs between them  PuZo makes a periodic request for data  Response arrives  ID within the gap  Send the next sequence

Continual Deny & Expose - Results  Success depends on the number of forged fragment attacker can `cache in’  Usually 64 or no limitation (except cache size, 6500+) 100.00% 99.00% 98.00% 97.00% Loss Rate 96.00% 95.00% 94.00% Open source, 256 93.00% Open source, 64 92.00% Commercial, 256 Commercial, 64 91.00% 90.00% 0 20 40 60 80 100 Attacker's bandwidth Mbit/sec

Conclusions  Fix IP ID  Add appropriate defenses to network firewalls, IDS/IPS  Need to improve specification of networking protocols  Need to develop validation techniques  Further motivation for [Gont11]

Questions?