1 / 54

Attacking the IPSec Standards in Encryption-only Configurations

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.

elvis-cline
Télécharger la présentation

Attacking the IPSec Standards in Encryption-only Configurations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. IPSec Introduction

  4. IPSec Standard • RFC 2401-2412, RFC 4301-4309 • 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

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

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

  7. 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 • P0, P1,…,Pn: Plain Text Blocks • C0, C1,…,Cn: Cipher Text Blocks • IV: Init Vector

  8. Cipher-Block Chaining (CBC) • Encryption: C0 = IV, Ci = e(Ci-1 XOR Pi) • Decryption: Pi = Ci-1 XOR d(Ci)

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

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

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

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

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

  14. IPSec Demo (2) – using preshared key • HP-UX version 11.23 • telnet from 16.159.165.62 to 16.159.165.75 • IPSec version A.02.00.01 • 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

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

  16. IPSec Demo (2) – using preshared key • Cipher text C0: 0000 0000 0000 0000 0000 0000 0000 0000 (Init Vector) C1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 C2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 C3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1 C4: ba89 6b95 0624 df5c bb71 8966 6038 6e91 • Decrypt using AES, key = 128-bit all zero’s, init vector = 128-bit all zero’s d(C1): 4500 0030 6625 0000 4006 a8db 109f a53e d(C2): 6ce6 0ab6 a007 1730 4f68 ea91 6d6f f5f1 d(C3): ffeb e281 43a2 18bb 7e3d 57c5 950b 6531 d(C4): 14f8 9127 5444 01ba 68db 72c9 d067 ddf5 • CBC mode, perform XOR P1 = C0 XOR d(C1): 4500 0030 6625 0000 4006 a8db 109f a53e P2 = C1 XOR d(C2): 109f a54b cb37 0017 1233 dd81 0000 0000 P3 = C2 XOR d(C3): 7002 8000 de52 0000 0204 05B4 0303 0001 P4 = C3 XOR d(C4): 0102 0304 0506 0708 090a 0b0c 0d0e 0e04

  17. IPSec Demo (2) – using preshared key • IP Header (RFC 791) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 4500 0030 6625 0000 4006 a8db 109f a53e 109f a54b cb37 0017 1233 dd81 0000 0000 7002 8000 de52 0000 0204 05B4 0303 0001 0102 0304 0506 0708 090a 0b0c 0d0e 0e04

  18. 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) • http://www.iana.org/assignments/protocol-numbers • IP(4), TCP(6), UDP(17), ICMP(1), ESP(50), AH(51)

  19. 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

  20. IPSec Padding • ESP Packet (RFC 4303) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 4500 0030 6625 0000 4006 a8db 109f a53e 109f a54b cb37 0017 1233 dd81 0000 0000 7002 8000 de52 0000 0204 05B4 0303 0001 0102 0304 0506 0708 090a 0b0c 0d0e0e04

  21. Attacks against Encryption-only IPSec Configurations

  22. 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

  23. Attack 1: Padding Oracle • P1,…,Pn: Plain Text Blocks (total n blocks) • Pi,1, Pi,2,…,Pi,t: Bytes within Plain Text Block Pi (t bytes per block) • C0, C1,…,Cn: Cipher Text Blocks (total n blocks and C0 = IV) • Ci,1, Ci,2,…,Ci,t: Bytes within Cipher Text Block Ci (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 Ci • Attacker submits two-block cipher text R,Ci 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…) • Rt XOR d(Ci)t = 0, d(Ci)t can then be computed • Pi,t = Ci-1,t XOR d(Ci)t, Pi,t can then be computed • Attacker tries at most 256 values of Rt to get pad length = 0 and therefore Pi,t

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

  25. 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 Pk (0≤k≤ 6) and corresponding cipher texts Ck (0≤k≤ 6), with source IP = Host A, dest IP = Host B, TTL = 1 • Assume: Pk contains 20 bytes of IP header, k+12 bytes of payload, padding, Pad Length and Next Header • Therefore P0 ends with 1,2,3,4,5,6,6,4 and P6 ends with 0,4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Header (20 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Data (12 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (k bytes) | Padding |Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • Pk has 5 blocks and therefore Ck has 6 blocks (Ck0 = IV)

  26. Attack 2: Chosen Plain Text • Attacker wants to decrypt Ci • Attacker submits 6-block cipher text C60, C61, C62, C63, R6, Ci to dest host • R6 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 • R6 XOR d(Ci) ends with 0,4, last 2 bytes of d(Ci) can be computed • Pi = Ci-1 XOR d(Ci), last 2 bytes of Pi can be computed

  27. Attack 2: Chosen Plain Text • Now the attacker wants to the remaining bytes of Pi • Attacker submits 6-block cipher text C50, C51, C52, C53, R5, Ci to dest host • R56 = R66 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(Ci) and Pi can be obtained Notes on Chosen Plain Text Attack • Requires chosen plain text and cipher text (Source IP, Dest IP, TTL value)

  28. 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 Pk and Ck (0≤k≤ 6) to proceed chosen plain text attack Lemma Pi = Ci-1 XOR d(Ci), if bit flip occurs in C0 = IV, changes occur on P1 only Preparation • The attacker collects D0, D1,…,Dn from IPSec payload (D0 = IV) • Flip the bits 6 and 7 of the block D0 • Vary the bytes 4 and 5 of block D0 • Submit the modified payload to dest host • Repeat steps 3, 4 for all possible values of bytes 4, 5 until dest host reply with ICMP type 12 “parameter problem”

  29. Attack 3: Option Processing 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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”

  30. Attack 3: Option Processing • Attacker follows chosen plain text attack to decrypt Ci • Attacker submits cipher text D0, D1,…,Dn, R6, Ci 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 R6, Ci, 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(Ci) and Pi can be obtained Notes on Option Processing Attack • Requires dest host to perform relaxed IP packet length checking

  31. 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 Pk and Ck (0≤k≤ 6) to proceed chosen plain text attack Lemma Pi = Ci-1 XOR d(Ci), if bit flip occurs in C0 = IV, changes occur on P1 only Preparation • The attacker collects D0, D1,…,Dn from IPSec payload (D0 = IV) • Flip the bits 72 and 73 of the block D0 • Vary the bytes 10 and 11 of block D0 • Submit the modified payload to dest host • Repeat steps 3, 4 for all possible values of bytes 10, 11 until dest host reply with ICMP type 3 “protocol unreachable”

  32. Attack 4: Protocol Field 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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”

  33. Attack 4: Protocol Field • Attacker follows chosen plain text attack to decrypt Ci • Attacker submits cipher text D0, D1,…,Dn, R6, Ci 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 R6, Ci, 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(Ci) and Pi 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

  34. Case Study:Attack Against HP-UX

  35. Case Study: Attack Against HP-UX • HP-UX version 11.23 • Source: 16.159.165.62 • Dest: 16.159.165.75 • IPSec version A.02.00.01 • 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

  36. 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 C0: 0000 0000 0000 0000 0000 0000 0000 0000 (Init Vector) C1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 C2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 C3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1 C4: ba89 6b95 0624 df5c bb71 8966 6038 6e91 ICMP generating cipher text D0: 0000 0000 0000 0000 00c000c0 0000 0000 (Init Vector) D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 D3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1 D4: ba89 6b95 0624 df5c bb71 8966 6038 6e91

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

  38. 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

  39. Attack Phase (against C1 byte 14) • Replace the last two blocks by random block R and cipher text C1 • 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(C1) XOR R = 0, d(C1) = a5, P1 = C0 XOR d(C1) = a5 ICMP generating cipher text D0: 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector) D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 D3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1 D4: ba89 6b95 0624 df5c bb71 8966 6038 6e91 Attack cipher text (attack against bytes 14,15 of C1) D0: 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector) D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 R: 0000 0000 0000 0000 0000 0000 0000 XXXX C1: 7c79 affd 9df0 18bb 7c39 5271 9608 6530

  40. Attack Phase (against C1 byte 14) Replace the last two blocks by random block R and cipher text C1, 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

  41. Attack Phase (against C1 byte 14) ICMP is observed when the last two bytes of R = a500 to a5ff R = a5 d(C1) XOR R = 0 d(C1) = a5 C0 = all zero P1 = C0 XOR d(C1) = a5 The byte 14 of P1 is therefore a5

  42. Attack Phase (against C1 byte 13) • Replace the last two blocks by random block R and cipher text C1 • d(C1) = a5, fix byte 14 of R to a4 so that d(C1) 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(C1) XOR R = 1, d(C1) = 9f, P1 = C0 XOR d(C1) = 9f ICMP generating cipher text D0: 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector) D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 D3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1 D4: ba89 6b95 0624 df5c bb71 8966 6038 6e91 Attack cipher text (attack against byte 13 of C1) D0: 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector) D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 R: 0000 0000 0000 0000 0000 0000 00XX a400 C1: 7c79 affd 9df0 18bb 7c39 5271 9608 6530

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

  44. Attack Phase (against C1 byte 13) ICMP is observed when the byte 13 of R = 9e R = 9e d(C1) XOR R = 1 d(C1) = 9f C0 = all zero P1 = C0 XOR d(C1) = 9f The byte 13 of P1 is therefore 9f

  45. Attack Phase (against C1 byte 12) • Replace the last two blocks by random block R and cipher text C1 • d(C1) = 9fa5, fix byte 13,14 of R to 9da7 so that d(C1) 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(C1) XOR R = 1, d(C1) = 10, P1 = C0 XOR d(C1) = 10 ICMP generating cipher text D0: 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector) D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 D3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1 D4: ba89 6b95 0624 df5c bb71 8966 6038 6e91 Attack cipher text (attack against byte 12 of C1) D0: 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector) D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 R: 0000 0000 0000 0000 0000 0000 XX9d a700 C1: 7c79 affd 9df0 18bb 7c39 5271 9608 6530

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

  47. Attack Phase (against C1 byte 12) ICMP is observed when the byte 12 of R = 11 R = 11 d(C1) XOR R = 1 d(C1) = 10 C0 = all zero P1 = C0 XOR d(C1) = 10 The byte 12 of P1 is therefore 10

  48. Attack Phase • Cipher Text C0: 0000 0000 0000 0000 0000 0000 0000 0000 (Init Vector) C1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 C2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 C3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1 C4: ba89 6b95 0624 df5c bb71 8966 6038 6e91 • Plain Text P1: 4500 0030 6625 0000 4006 a8db 109fa53e P2: 109f a54b cb37 0017 1233 dd81 0000 0000 P3: 7002 8000 de52 0000 0204 05B4 0303 0001 P4: 0102 0304 0506 0708 090a 0b0c 0d0e 0e04 • We have retrieved byte 14 of C1 = 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

  49. Critique

  50. 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 2.6.18, <srcdir>/net/ipv4/esp4.c /* ... check padding bits here. Silly. :-) */ • Requires RFC4303 defined padding pattern • How should RFC define “random padding”

More Related