Attacking the IPSec Standards in Encryption- only Configurations Jean Paul Degabriele and Kenneth G. Paterson Presented by Chan Wing Cheong Mar 31, 2008

Agenda IPSec Introduction Attacks against Encryption-only IPSec Configurations Case study: Attack against HP-UX Critique

IPSec Introduction

IPSec Standard RFC , RFC A protocol suite defined by IETF to provide the following security services for IP networks: −Authentication Header (AH) Provides integrity and authentication −Encapsulating Security Payload (ESP) Primarily provides encryption but can also provide limited authentication −Internet Key Exchange (IKE) Establish Security Association (SA) Generates and distributes keys for ESP

AH Protocol AH Transport Mode −Original IP header is retained AH Tunnel Mode −The original IP packet is encapsulated in a new packet

ESP Protocol ESP Transport Mode −Original IP header is retained ESP Tunnel Mode −The original IP packet is encapsulated in a new packet

ESP Protocol Encrption Algorithm −DES-CBC (64-bit key, 64-bit block size) −3DES-CBC (192-bit key, 64-bit block size) −AES-CBC (128/192/256-bit key, 128-bit block size) Convention −P 0, P 1,…,P n : Plain Text Blocks −C 0, C 1,…,C n : Cipher Text Blocks −IV: Init Vector

Cipher-Block Chaining (CBC) Encryption: C 0 = IV, C i = e(C i-1 XOR P i ) Decryption: P i = C i-1 XOR d(C i )

IKE Protocol Diffle-Hellman Algorithm −Generate shared secret key (session key) from public keys, without revealing private keys

IPSec Demo (1) – using IKE HP-UX version −telnet from to IPSec version A ESP tunnel mode, using 128-bit AES-CBC No authentication IKE −3DES-CBC encryption, MD5 hash −IKE produces one-time session key

IPSec Demo (1) – using IKE First exchange – Security Association Payload proposes 3DES- CBC encryption algorithm and MD5 hash, which is accepted by

IPSec Demo (1) – using IKE Second exchange – Key Exchange Payload and exchange Diffle- Hellman public keys to compute a shared secret key

IPSec Demo (1) – using IKE Third exchange – Identification Payload and exchange identification data encrypted by shared secret key

IPSec Demo (2) – using preshared key HP-UX version −telnet from to IPSec version A ESP tunnel mode, using 128-bit AES-CBC No authentication Manual preshared key, no IKE −Preshared key: 128-bit all zero’s −Init vector: 128-bit all zero’s −ESP payload can be decrypted using preshared key

IPSec Demo (2) – using preshared key No key exchange because preshared key is used ESP payload can be decrypted using preshared key

IPSec Demo (2) – using preshared key Cipher text C 0 : (Init Vector) C 1 : 7c79 affd 6b d5b d6f f5f1 C 2 : 8fe df0 18bb 7c C 3 : 15fa b2 61d1 79c5 dd69 d3f1 C 4 : ba89 6b df5c bb e91 Decrypt using AES, key = 128-bit all zero’s, init vector = 128-bit all zero’s d(C 1 ): a8db 109f a53e d(C 2 ): 6ce6 0ab6 a f68 ea91 6d6f f5f1 d(C 3 ): ffeb e281 43a2 18bb 7e3d 57c5 950b 6531 d(C 4 ): 14f ba 68db 72c9 d067 ddf5 CBC mode, perform XOR P 1 = C 0 XOR d(C 1 ): a8db 109f a53e P 2 = C 1 XOR d(C 2 ):109f a54b cb dd P 3 = C 2 XOR d(C 3 ): de B P 4 = C 3 XOR d(C 4 ): a 0b0c 0d0e 0e04

IPSec Demo (2) – using preshared key IP Header (RFC 791) |Version| IHL |Type of Service| Total Length | | Identification |Flags| Fragment Offset | | Time to Live | Protocol | Header Checksum | | Source Address | | Destination Address | | Options | Padding | Plain text a8db 109f a53e 109f a54b cb dd de B a 0b0c 0d0e 0e04

IPSec Padding CBC mode must operate in whole blocks Padding (RFC4303) The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3,.... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. Pad Length (PL) Next Header (NH) − −IP(4), TCP(6), UDP(17), ICMP(1), ESP(50), AH(51)

IPSec Padding Valid Pattern for ESP Tunnel Mode −0,4 −1,1,4 −1,2,2,4 −1,2,3,3,4 Valid Pattern for ESP Transport Mode −0,NH −1,1,NH −1,2,2,NH −1,2,3,3,NH

IPSec Padding ESP Packet (RFC 4303) | Security Parameters Index (SPI) | | Sequence Number | | IV (optional) | ^ p ^e | a |n | Rest of Payload Data (variable) | | y |c ~ ~ | l |r | | | o |y | a |p | | TFC Padding * (optional, variable) | v d |t |i | | Padding (0-255 bytes) | |o |n | | Pad Length | Next Header | v Plain text a8db 109f a53e 109f a54b cb dd de B a 0b0c 0d0e 0e04

Attacks against Encryption-only IPSec Configurations

IPSec Attacks This paper describes attacks which break any RFC-compliant encryption-only IPSec implementation −Padding Oracle Attack −Chosen Plain Text Attack −Option Processing Attack −Protocol Field Attack The first few attacks may not be realistic and practical, but they reflect how attack methods are improved and refined

Attack 1: Padding Oracle P 1,…,P n : Plain Text Blocks (total n blocks) P i,1, P i,2,…,P i,t : Bytes within Plain Text Block P i (t bytes per block) C 0, C 1,…,C n : Cipher Text Blocks (total n blocks and C 0 = IV) C i,1, C i,2,…,C i,t : Bytes within Cipher Text Block C i (t bytes per block) Assume: there is no Next Header byte at the end of packet Assume: there is an Oracle that tells whether the padding is correct Attacker wants to decrypt C i Attacker submits two-block cipher text R,C i to padding Oracle If padding is correct, it is most likely that Pad Length = 0 (there is slim chance that padding can be 1,1 or 1,2,2 or 1,2,3,3…) R t XOR d(C i ) t = 0, d(C i ) t can then be computed P i,t = C i-1,t XOR d(C i ) t, P i,t can then be computed Attacker tries at most 256 values of R t to get pad length = 0 and therefore P i,t

Attack 1: Padding Oracle Now the attacker learns P i,t and wants to know P i,t-1 The attacker fixes R t so that R t XOR d(C i ) t = 1, vary R t-1 and submit R,C i to padding Oracle If padding is correct, padding must be 1 and Pad Length must be 1 R t-1 XOR d(C i ) t-1 = 1, d(C i ) t-1 can then be computed P i,t-1 = C i-1,t-1 XOR d(C i ) t-1 Attacker tries at most 256 values of R t-1 to get padding = 1,1 Fix R t, R t-1 and repeat the process to try padding = 1,2,2 Eventually all bytes in d(C i ) and P i can be obtained Notes on Padding Oracle Attack IPSec has Next Header byte at the end Whether such padding Oracle indeed exists

Attack 2: Chosen Plain Text Assume: ESP Tunnel Mode is used Assume: block size = 64 bits (trivial to adapt the attack to 128-bit block) Assume: there are 7 chosen plain texts P k (0≤k≤ 6) and corresponding cipher texts C k (0≤k≤ 6), with source IP = Host A, dest IP = Host B, TTL = 1 Assume: P k contains 20 bytes of IP header, k+12 bytes of payload, padding, Pad Length and Next Header Therefore P 0 ends with 1,2,3,4,5,6,6,4 and P 6 ends with 0, | IP Header (20 bytes) | | Payload Data (12 bytes) | | (k bytes) | Padding |Pad Length | Next Header | P k has 5 blocks and therefore C k has 6 blocks (C k 0 = IV)

Attack 2: Chosen Plain Text Attacker wants to decrypt C i Attacker submits 6-block cipher text C 6 0, C 6 1, C 6 2, C 6 3, R 6, C i to dest host R 6 does not affect IP header after decryption If padding is not correct, the packet will be silently dropped by dest host If padding is correct, most likely PL = 0 and NH = 4, and Host B will reply with ICMP type 11 “time to live exceeded” ICMP reply may be encrypted, attacker needs to monitor 9-block cipher text from Host B to Host A R 6 XOR d(C i ) ends with 0,4, last 2 bytes of d(C i ) can be computed P i = C i-1 XOR d(C i ), last 2 bytes of P i can be computed

Attack 2: Chosen Plain Text Now the attacker wants to the remaining bytes of P i Attacker submits 6-block cipher text C 5 0, C 5 1, C 5 2, C 5 3, R 5, C i to dest host R 5 6 = R 6 6 XOR 1 so that PL = 1 If padding is correct, padding = 1, PL = 1 and NH = 4, and dest host will reply with ICMP time exceeded packet (9-block cipher text if encrypted) Repeat the process until all bytes in d(C i ) and P i can be obtained Notes on Chosen Plain Text Attack Requires chosen plain text and cipher text (Source IP, Dest IP, TTL value)

Attack 3: Option Processing Assume: ESP Tunnel Mode is used Assume: block size = 64 bits (trivial to adapt the attack to 128-bit block) Assume: Dest host performs relaxed IP packet length checking The attacker needs P k and C k (0≤k≤ 6) to proceed chosen plain text attack Lemma P i = C i-1 XOR d(C i ), if bit flip occurs in C 0 = IV, changes occur on P 1 only Preparation 1. The attacker collects D 0, D 1,…,D n from IPSec payload (D 0 = IV) 2. Flip the bits 6 and 7 of the block D 0 3. Vary the bytes 4 and 5 of block D 0 4. Submit the modified payload to dest host 5. Repeat steps 3, 4 for all possible values of bytes 4, 5 until dest host reply with ICMP type 12 “parameter problem”

Attack 3: Option Processing |Version| IHL |Type of Service| Total Length | | Identification |Flags| Fragment Offset | | Time to Live | Protocol | Header Checksum | | Source Address | | Destination Address | | Options | Padding | Flip the bits 6 and 7 of IV so that header length changes from 5 to 6 Header Checksum = 1’s complement sum of 16-bit header words Vary the bytes 4 and 5 of IV to produce different values of ID so that original checksum can still be obtained The first 4 bytes of payload will then be interpreted as option Most likely the option is incorrectly formatted, and dest host will reply with ICMP type 12 “parameter problem”

Attack 3: Option Processing Attacker follows chosen plain text attack to decrypt C i Attacker submits cipher text D 0, D 1,…,D n, R 6, C i to dest host If padding is not correct, the packet will be silently dropped by dest host If padding is correct, most likely PL = 0 and NH = 4 After appending R 6, C i, the header length is not correct but is still processed by dest host due to relaxed length checking Dest host will reply with ICMP type 12 “parameter problem” Repeat the process until all bytes in d(C i ) and P i can be obtained Notes on Option Processing Attack Requires dest host to perform relaxed IP packet length checking

Attack 4: Protocol Field Assume: ESP Tunnel Mode is used Assume: block size = 128 bits (does not work on 64-bit block size) The attacker needs P k and C k (0≤k≤ 6) to proceed chosen plain text attack Lemma P i = C i-1 XOR d(C i ), if bit flip occurs in C 0 = IV, changes occur on P 1 only Preparation 1. The attacker collects D 0, D 1,…,D n from IPSec payload (D 0 = IV) 2. Flip the bits 72 and 73 of the block D 0 3. Vary the bytes 10 and 11 of block D 0 4. Submit the modified payload to dest host 5. Repeat steps 3, 4 for all possible values of bytes 10, 11 until dest host reply with ICMP type 3 “protocol unreachable”

Attack 4: Protocol Field |Version| IHL |Type of Service| Total Length | | Identification |Flags| Fragment Offset | | Time to Live | Protocol | Header Checksum | | Source Address | | Destination Address | | Options | Padding | Flip the bits 72 and 73 of IV so that Protocol value is increased by 192 Protocol numbers from 140 to 252 are currently unassigned Header Checksum = 1’s complement sum of 16-bit header words Vary the bytes 10 and 11 of IV until a correct checksum is obtained If the checksum is correct, the dest host will reply with ICMP type 3 “protocol unreachable”

Attack 4: Protocol Field Attacker follows chosen plain text attack to decrypt C i Attacker submits cipher text D 0, D 1,…,D n, R 6, C i to dest host If padding is not correct, the packet will be silently dropped by dest host If padding is correct, most likely PL = 0 and NH = 4 After appending R 6, C i, the header length is not correct but is still processed by dest host due to relaxed length checking Dest host will reply with ICMP type 3 “protocol unreachable” Repeat the process until all bytes in d(C i ) and P i can be obtained Notes on Protocol Field Attack Requires dest host to perform relaxed IP packet length checking Does not work against 64-bit block size

Case Study: Attack Against HP-UX

HP-UX version −Source: −Dest: IPSec version A ESP tunnel mode, using 128-bit AES-CBC No authentication Manual preshared key, no IKE −Preshared key: 128-bit all zero’s −Init vector: 128-bit all zero’s

Preparation Phase Flip the bits 72 and 73 of IV so that Protocol value is increased by 192 Vary the bytes 10 and 11 of IV until a correct checksum is obtained This new cipher text will generate ICMP “protocol unreachable” reply Original cipher text C 0 : (Init Vector) C 1 : 7c79 affd 6b d5b d6f f5f1 C 2 : 8fe df0 18bb 7c C 3 : 15fa b2 61d1 79c5 dd69 d3f1 C 4 : ba89 6b df5c bb e91 ICMP generating cipher text D 0 : c0 00c (Init Vector) D 1 : 7c79 affd 6b d5b d6f f5f1 D 2 : 8fe df0 18bb 7c D 3 : 15fa b2 61d1 79c5 dd69 d3f1 D 4 : ba89 6b df5c bb e91

Preparation Phase Cipher text with modified init vector is injected to the network

Preparation Phase ICMP protocol unreachable packet is observed because protocol field has been tampered This ICMP generating packet can then be used as padding oracle

Attack Phase (against C 1 byte 14) Replace the last two blocks by random block R and cipher text C 1 Total packet length is preserved Systematically vary the last two bytes of R to produce correct padding The most likely correct padding is PL = 0 ICMP reply is observed for XXXX = a500 to a5ff It turns out that HP-UX does not inspect Next Header (NH) byte R = a5, d(C 1 ) XOR R = 0, d(C 1 ) = a5, P 1 = C 0 XOR d(C 1 ) = a5 ICMP generating cipher text D 0 : c0 00c (Init Vector) D 1 : 7c79 affd 6b d5b d6f f5f1 D 2 : 8fe df0 18bb 7c D 3 : 15fa b2 61d1 79c5 dd69 d3f1 D 4 : ba89 6b df5c bb e91 Attack cipher text (attack against bytes 14,15 of C 1 ) D 0 : c0 00c (Init Vector) D 1 : 7c79 affd 6b d5b d6f f5f1 D 2 : 8fe df0 18bb 7c R : XXXX C 1 : 7c79 affd 9df0 18bb 7c

Attack Phase (against C 1 byte 14) Replace the last two blocks by random block R and cipher text C 1, and inject the modified cipher text to the network Systematically vary the last two bytes of R to produce correct padding The most likely correct padding is PL = 0

Attack Phase (against C 1 byte 14) ICMP is observed when the last two bytes of R = a500 to a5ff R = a5 d(C 1 ) XOR R = 0 d(C 1 ) = a5 C 0 = all zero P 1 = C 0 XOR d(C 1 ) = a5 The byte 14 of P 1 is therefore a5

Attack Phase (against C 1 byte 13) Replace the last two blocks by random block R and cipher text C 1 d(C 1 ) = a5, fix byte 14 of R to a4 so that d(C 1 ) XOR R = 1 Systematically vary byte 13 of R to produce correct padding The only correct padding is 1, PL = 1 ICMP reply is observed for XX = 9e R = 9e, d(C 1 ) XOR R = 1, d(C 1 ) = 9f, P 1 = C 0 XOR d(C 1 ) = 9f ICMP generating cipher text D 0 : c0 00c (Init Vector) D 1 : 7c79 affd 6b d5b d6f f5f1 D 2 : 8fe df0 18bb 7c D 3 : 15fa b2 61d1 79c5 dd69 d3f1 D 4 : ba89 6b df5c bb e91 Attack cipher text (attack against byte 13 of C 1 ) D 0 : c0 00c (Init Vector) D 1 : 7c79 affd 6b d5b d6f f5f1 D 2 : 8fe df0 18bb 7c R : XX a400 C 1 : 7c79 affd 9df0 18bb 7c

Attack Phase (against C 1 byte 13) Fix byte 14 of R to a4 so that d(C 1 ) XOR R = 1 Systematically vary byte 13 of R to produce correct padding The most likely correct padding is 1, PL = 1

Attack Phase (against C 1 byte 13) ICMP is observed when the byte 13 of R = 9e R = 9e d(C 1 ) XOR R = 1 d(C 1 ) = 9f C 0 = all zero P 1 = C 0 XOR d(C 1 ) = 9f The byte 13 of P 1 is therefore 9f

Attack Phase (against C 1 byte 12) Replace the last two blocks by random block R and cipher text C 1 d(C 1 ) = 9fa5, fix byte 13,14 of R to 9da7 so that d(C 1 ) XOR R = 0202 Systematically vary byte 12 of R to produce correct padding The only correct padding is 1,2, PL = 2 ICMP reply is observed for XX = 11 R = 11, d(C 1 ) XOR R = 1, d(C 1 ) = 10, P 1 = C 0 XOR d(C 1 ) = 10 ICMP generating cipher text D 0 : c0 00c (Init Vector) D 1 : 7c79 affd 6b d5b d6f f5f1 D 2 : 8fe df0 18bb 7c D 3 : 15fa b2 61d1 79c5 dd69 d3f1 D 4 : ba89 6b df5c bb e91 Attack cipher text (attack against byte 12 of C 1 ) D 0 : c0 00c (Init Vector) D 1 : 7c79 affd 6b d5b d6f f5f1 D 2 : 8fe df0 18bb 7c R : XX9d a700 C 1 : 7c79 affd 9df0 18bb 7c

Attack Phase (against C 1 byte 12) Fix byte 13,14 of R to 9da7 so that d(C 1 ) XOR R = 2,2 Systematically vary byte 12 of R to produce correct padding The most likely correct padding is 1,2, PL = 2

Attack Phase (against C 1 byte 12) ICMP is observed when the byte 12 of R = 11 R = 11 d(C 1 ) XOR R = 1 d(C 1 ) = 10 C 0 = all zero P 1 = C 0 XOR d(C 1 ) = 10 The byte 12 of P 1 is therefore 10

Attack Phase Cipher Text C 0 : (Init Vector) C 1 :7c79 affd 6b d5b d6f f5f1 C 2 :8fe df0 18bb 7c C 3 :15fa b2 61d1 79c5 dd69 d3f1 C 4 :ba89 6b df5c bb e91 Plain Text P 1 : a8db 109f a53e P 2 :109f a54b cb dd P 3 : de B P 4 : a 0b0c 0d0e 0e04 We have retrieved byte 14 of C 1 = a5, byte 13 = 9f, byte 12 = 10 The process can be repeated to get byte 0 to byte 14 Byte 15 cannot be retrieved because HP-UX does not inspect NH byte

Critique

Attack Requirement Requires strict IPSec padding check −Vulnerable to Bellovin attack if padding check is not strictly enforced −Open Solaris, HP-UX perform padding check −Linux does not perform padding check Red Hat Enterprise Linux 5, kernel , /net/ipv4/esp4.c /*... check padding bits here. Silly. :-) */ Requires RFC4303 defined padding pattern −How should RFC define “random padding”

Attack Requirement Requires CBC mode encryption −CBC is widely used because, if not so, encrypting the same plaintext using the same key always produces the same output Requires encryption-only configuration −HP-UX does not support encryption-only configuration since IPSec A (Oct 2005) Requires IPSec tunnel mode −The attack can actually be adapted against IPSec transport mode, with further preparation tasks

Preventing Attack Include authentication in IPSec configuration Change shared secret key frequently

Critique IP packet has well defined data pattern −Poor randomness of data makes attack easier IP header is located at the beginning of data −Can be easily modified via CBC mode init vector Generic encryption algorithm may not be suitable for IPSec The attack does not work against HP-UX because Protocol field is inspected before Next Header

Acknowledgement AES Decryption Tool − − Packet Injection Tool − Illustration − −