Mathy Vanhoef

Introduction:

WPA-TKIP Protocol

Existing Attacks

New Attacks:

Denial of Service

Fragmentation Attack

MIC Reset Attack

We will cover:

Connecting

Sending & receiving packets

Quality of Service (QoS) extension

Design Constraints:

Must run on legacy hardware

Uses (hardware) WEP encapsulation

Defined by EAPOL and results in a session key

What people normally capture & crack

EAPOL protection DataEncr MIC1 MIC2

DataEncr key: used to encrypt packets

MIC keys (Message Integrity Code):

Verify integrity of data. But why two?

Result of handshake is 512 bit session key

Renewed after rekeying timeout (1 hour)

WPA-TKIP designed for old hardware

Couldn’t use strong integrity checks (CCMP)

New algorithm called Michael was created

Weakness: plaintext + MIC reveals MIC key

To improve security two MIC keys are used

MIC1 for AP to client communication

MIC2 for client to AP communication

Calculate MIC to assure integrity

WEP Encapsulation:

Calculate CRC

Encrypt the packet using RC4

Add replay counter (TSC) to avoid replays

TSC MIC Data CRC

Encrypted

WEP decapsulation:

Verify TSC to prevent replays

Decrypt packet using RC4

Verify CRC

Verify MIC to assure authenticity

TSC MIC Data CRC

Encrypted

Replay counter & CRC are good, but MIC not

Transmission error unlikely

Network may be under attack!

Defense mechanism on MIC failure:

Client sends MIC failure report to AP

AP silently logs failure

Two failures in 1 min: network down for 1 min

Defines several QoS channels

Implemented by new field in 802.11 header

TSC MIC Data CRC

Encrypted

QoS

unencrypted

Individual replay counter (TSC) per channel

Used to pass replay counter check of receiver!

Support for up to 8 channels

But WiFi certification only requires 4

Channel TSC

0: Best Effort 4000

1: Background 0

2: Video 0

3: Voice 0

Introduction:

WPA-TKIP Protocol

Existing Attacks

New Attacks:

Denial of Service

Fragmentation Attack

MIC Reset Attack

Martin Beck: TU-Dresden, Germany Erik Tews: TU-Darmstadt, Germany

First known attack on TKIP, requires QoS

Decrypts ARP reply sent from AP to client

MIC key for AP to client

Takes at least 8 minutes to execute

Remove last byte

CRC can be corrected if last byte is known

Try all 256 values & send using diff. priority

On correct guess: MIC failure report

TSC MIC Data CRC QoS

TSC MIC’ Data CRC' QoS

Takes 12 minutes to execute

Limited impact: injection of 3-7 small packets

An improved attack on TKIP

2009/11: targets DHCP Ack packet

Cryptanalysis for RC4 and Breaking WPA-TKIP

2011/11: Removes QoS requirement

Falsification Attacks against WPA-TKIP in a realistic

environment

2012/02: Reduces execution time to 8 minutes

Unpublished (Martin Beck, 2010)

Suggests fragmentation attack

Not implemented, unrealistic usage example

MIC Reset Attack

Implemented, but PoC not available

Incorrect theoretical analysis

Suggests a decryption attack

Not implemented & contains essential flaw

Papers about Denial of Service (DoS) attacks: 802.11 DoS attack: real vulnerabilities and

practical solutions

2003: Not specific to TKIP, but WiFi in general

A study of the TKIP cryptographic DoS attack

2007: Requires man-in-the-middle position

Introduction:

WPA-TKIP Protocol

Existing Attacks

New Attacks:

Denial of Service

Fragmentation Attack

MIC Reset Attack

MIC = Michael(MAC dest, MAC source, MIC key, priority, data)

Rc4key = MixKey(MAC transmitter, key, TSC)

Key observations:

Individual replay counter per priority

Priority influences MIC but not encryption key

Two MIC failures: network down

What happens when the priority is changed?

Capture packet, change priority, replay

On Reception :

Verify replay counter

Decrypt packet using RC4

Verify CRC (leftover from WEP)

Verify MIC to assure authenticity

Capture packet, change priority, replay

On Reception :

Verify replay counter OK

Decrypt packet using RC4 OK

Verify CRC (leftover from WEP) OK

Verify MIC to assure authenticity FAIL

Do this twice: Denial of Service

Disadvantage: attack fails if QoS is disabled

Cryptanalysis for RC4 and breaking WPA:

Capture packet, add QoS header, change priority, replay

On Reception:

Doesn’t check whether QoS is actually used

Again bypass replay counter check

MIC still dependent on priority

Example: network with 20 connected clients

Old deauthentication attack:

Must continuously sends packets

Say 10 deauths per client per second

(10 * 60) * 20 = 12 000 frames per minute

New attack

2 frames per minute

Specifically exploits flaws in WPA-TKIP

Takes down network for 1 minute yet requires no man-in-the-middle position

Requires sending only two packets to take down the network for 1 minute

Introduction:

WPA-TKIP Protocol

Existing Attacks

New Attacks:

Denial of Service

Fragmentation Attack

MIC Reset Attack

What is needed to inject packets: MIC key

Result of Beck & Tews attack

Unused replay counter

Inject packet on unused QoS channel

Keystream corresponding to replay counter

Beck & Tews results in only one keystream…

How can we get more? First need to know RC4!

Stream cipher XOR-based

This means: Ciphertext

Plaintext

Keystream

Predicting the plaintext gives the keystream

Simplified:

All data packets start with LLC header

Different for APR, IP and EAPOL packets

Detect ARP & EAPOL based on length

Everything else: IP

Practice: almost no incorrect guesses!

Gives us 12 bytes keystream for each packet

But is 12 bytes enough to send a packet? No, MIC & CRC alone are 12 bytes. If only we could somehow combine them… Using 802.11 fragmentation we can combine

16 keystreams to send one large packet

MIC calculated over complete packet

Each fragment has CRC and different TSC

12 bytes/keystream: inject 120 bytes of data

TSC1 Data1 TSC16 Data16 CRC16 MIC CRC1

Data MIC

Data1 Data16 MIC Data2

Beck & Tews attack: MIC key AP to client

Predict packets & get keystreams

Combine short keystreams by fragmentation

Send over unused QoS channel

What can we do with this?

ARP/DNS Poisoning

Sending TCP SYN packets: port scan!

A few notes:

Scan 500 most popular ports

Detect SYN/ACK based on length

Avoid multiple SYN/ACK’s: send RST

Port scan of internal client:

Normally not possible

We are bypassing the network firewall / NAT!

Fragmentation attack implemented!

Slightly improved & verified prediction of packets

Verified usage of 802.11 fragmentation

Realistic example: portscan

Introduction:

WPA-TKIP Protocol

Existing Attacks

New Attacks:

Denial of Service

Fragmentation Attack

MIC Reset Attack

Assume we know the MIC key

We know the initial MIC state for packets

Attack idea:

Construct a packet, so that after processing it, the state is equal to the inital state.

We can then append a random packet to it, knowing that its MIC value is valid.

State1: initial state of every packet

Data MIC Magic Prefix

State1

Targeted packet

State1: initial state of every packet

State2: state after processing prefix

Data MIC Magic Prefix

State2

Targeted packet

State1: initial state of every packet

State2: state after processing prefix

State3: equal to state1 due to magic bytes

Data MIC Magic Prefix

State3

Targeted packet

State1: initial state of every packet

State2: state after processing prefix

State3: equal to state1 due to magic bytes

State4: equal to MIC of targeted packet!

Data MIC Magic Prefix

State4

Targeted packet

How to calculate the magic bytes?

Method suggested in unpublished paper

Essentially a birthday attack

Has been verified, indeed works

Theoretical analysis:

Was done very informal & contained errors

Done correctly using probability theory

The prefix attack can be used to decrypt the targeted packet.

Unpublished paper:

Suggested the prefix to be a ping request

Reply will echo the data = targeted packet

Flaw: ping request contains checksum

As the targeted packet is unknown, we cannot calculate the checksum, packet will be dropped

The prefix attack can be used to decrypt the targeted packet.

Solution:

Prefix is UDP packet to closed port

UDP doesn’t require a checksum

Assuming port is closed, host will reply with ICMP unreachable containing the UDP packet

Make it reply to external ip

In practice:

Capture a packet from AP to client

Send the prefix using fragmentation

Send the targeted packet

Reply of client contains complete packet

Assumes client isn’t running a firewall

Rudimantary PoC is working

Correct theoretical analysis

Using clear assumptions & probability theory

Verified by practical experiments!

Working decryption attack:

Their suggestion contained an essential flaw

Different technique based on UDP packets

Rudimentairy proof of concept is working (WIP)

Highly efficient Denial of Service

Very reliable PoC

Fragmentation to launch actual attacks

Verified that fragmentation works

Reliable PoC portscan attack

MIC reset to decrypt AP to client packets

Correct theoretical analysis

UDP technique

PoC is work in progress