Date post: | 22-May-2015 |
Category: |
Technology |
Upload: | vanhoefm |
View: | 568 times |
Download: | 4 times |
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