attacking the ipsec standards in encryption-only configurations
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
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 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
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−P0, P1,…,Pn: Plain Text Blocks
−C0, C1,…,Cn: Cipher Text Blocks
−IV: Init Vector
Cipher-Block Chaining (CBC)• Encryption: C0 = IV, Ci = e(Ci-1 XOR Pi)
• Decryption: Pi = Ci-1 XOR d(Ci)
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 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
IPSec Demo (1) – using IKEFirst exchange –
Security Association Payload
16.159.165.62 proposes 3DES-CBC encryption algorithm and MD5 hash, which is accepted by 16.159.165.75
IPSec Demo (1) – using IKESecond exchange
– Key Exchange Payload
16.159.165.62 and 16.159.165.75 exchange Diffle-Hellman public keys to compute a shared secret key
IPSec Demo (1) – using IKEThird exchange –
Identification Payload
16.159.165.62 and 16.159.165.75 exchange identification data encrypted by shared secret key
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
IPSec Demo (2) – using preshared keyNo key exchange
because preshared key is used
ESP payload can be decrypted using preshared key
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
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 text4500 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
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)
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)
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 text4500 0030 6625 0000 4006 a8db 109f a53e109f a54b cb37 0017 1233 dd81 0000 00007002 8000 de52 0000 0204 05B4 0303 00010102 0304 0506 0708 090a 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• 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
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
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)
Attack 2: Chosen Plain Text• Attacker wants to decrypt Ci
• Attacker submits 6-block cipher text C60, C6
1, C62, C6
3, 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
Attack 2: Chosen Plain Text• Now the attacker wants to the remaining bytes of Pi
• Attacker submits 6-block cipher text C50, C5
1, C52, C5
3, R5, Ci to dest host
• R56 = R6
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(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)
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
LemmaPi = Ci-1 XOR d(Ci), if bit flip occurs in C0 = IV, changes occur on P1 only
Preparation1. The attacker collects D0, D1,…,Dn from IPSec payload (D0 = IV)2. Flip the bits 6 and 7 of the block D0
3. Vary the bytes 4 and 5 of block D0
4. Submit the modified payload to dest host5. 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 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”
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
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
LemmaPi = Ci-1 XOR d(Ci), if bit flip occurs in C0 = IV, changes occur on P1 only
Preparation1. The attacker collects D0, D1,…,Dn from IPSec payload (D0 = IV)2. Flip the bits 72 and 73 of the block D0
3. Vary the bytes 10 and 11 of block D0
4. Submit the modified payload to dest host5. 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 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”
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
Case Study:Attack Against HP-UX
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
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 textC0: 0000 0000 0000 0000 0000 0000 0000 0000 (Init Vector)C1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1C2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530C3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1C4: ba89 6b95 0624 df5c bb71 8966 6038 6e91
ICMP generating cipher textD0: 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector)D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530D3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1D4: ba89 6b95 0624 df5c bb71 8966 6038 6e91
Preparation PhaseCipher text with
modified init vector is injected to the network
Preparation PhaseICMP 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 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 textD0: 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector)D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530D3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1D4: 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 f5f1D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530R : 0000 0000 0000 0000 0000 0000 0000 XXXXC1: 7c79 affd 9df0 18bb 7c39 5271 9608 6530
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
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
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 textD0: 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector)D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530D3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1D4: 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 f5f1D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530R : 0000 0000 0000 0000 0000 0000 00XX a400C1: 7c79 affd 9df0 18bb 7c39 5271 9608 6530
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
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
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 textD0: 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector)D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530D3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1D4: 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 f5f1D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530R : 0000 0000 0000 0000 0000 0000 XX9d a700C1: 7c79 affd 9df0 18bb 7c39 5271 9608 6530
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
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
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 109f a53e
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
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 checkRed 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”
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.02.01 (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
−http://people.eku.edu/styere/Encrypt/JS-AES.html
−http://www.hanewin.net/encrypt/aes/aes-test.htm
• Packet Injection Tool−http://nemesis.sourceforge.net/
• Illustration−http://docs.hp.com/
−http://www.wikipedia.org/