![ Disadvantage: attack fails if QoS is disabled
Solution: 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
[Cryptanalysis for RC4 and breaking WEP/WPA-TKIP]](https://image.slidesharecdn.com/brucon2012-130218175115-phpapp01/85/New-flaws-in-WPA-TKIP-17-320.jpg)
New flaws in WPA-TKIP
- 1. Mathy Vanhoef @vanhoefm Brucon 2012
- 2. 0x00 The WPA-TKIP protocol 0x04 Denial of Service 0x08 Demo 0x0C Beck & Tews attack 0x10 Fragmentation attack 0x14 Performing a port scan
- 3. We will cover: Connecting Sending & receiving packets Quality of Service (QoS) extension Design Constraints: Must run on legacy hardware Uses (hardware) WEP encapsulation
- 4. Defined by EAPOL and results in a session key What you normally capture & crack
- 5. Result of handshake is 512 bit session key Renewed after rekeying timeout (1 hour) EAPOL protection DataEncr MIC1 MIC2 DataEncr key: used to encrypt packets MIC keys (Message Integrity Code): Verify integrity of data. But why two?
- 6. 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
- 7. TSC Data MIC CRC Encrypted Calculate MIC to assure integrity WEP Encapsulation: Calculate CRC Encrypt the packet using RC4 Add replay counter (TSC) to avoid replays
- 8. TSC Data MIC CRC Encrypted WEP decapsulation: Verify TSC to prevent replays Decrypt packet using RC4 Verify CRC Verify MIC to assure authenticity
- 9. 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
- 10. Defines several QoS channels Implemented by new field in 802.11 header QoS TSC Data MIC CRC unencrypted Encrypted Individual replay counter (TSC) per channel Used to pass replay counter check of receiver!
- 11. Channel TSC 0: Best Effort 4000 1: Background 0 2: Video 0 3: Voice 0 Support for up to 8 channels But WiFi certification only requires 4
- 12. MIC = Michael(MAC dest, MAC source, MIC key, priority, data) Rc4key = MixKey(MAC transmitter, key, TSC)
- 13. The previous slides contain all the info to find a denial of service attack, any ideas?
- 14. The previous slides contain all the info to find a denial of service attack, any ideas? 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?
- 15. Capture packet, change priority, replay On Reception : Verify replay counter Decrypt packet using RC4 Verify CRC (leftover from WEP) Verify MIC to assure authenticity
- 16. 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
- 17. Disadvantage: attack fails if QoS is disabled Solution: 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 [Cryptanalysis for RC4 and breaking WEP/WPA-TKIP]
- 18. Attacker: VMWare vs. Victim: Windows
- 19. Example: network with 20 connected clients 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
- 20. 0x00 The WPA-TKIP protocol 0x04 Denial of Service 0x08 Demo 0x0C Beck & Tews attack 0x10 Fragmentation attack 0x14 Performing a port scan
- 21. First known attack on TKIP, requires QoS Decrypts ARP reply sent from AP to client Simplified: each byte is decrypted by sending a modified packet for all 256 possible values: Wrong guess: CRC invalid Correct guess: CRC valid but MIC failure MIC key for AP to client
- 22. Takes 12 minutes to execute Limited impact: injection of 3-7 small packets
- 23. 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!
- 24. Stream cipher XOR-based This means: Ciphertext Plaintext Keystream Predicting the plaintext gives the keystream
- 25. 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
- 26. But is 12 bytes enough to send a packet? No, MIC & CRC alone are 12 bytes. If only we could somehow combine them… …well, title of this section is fragmentation
- 27. But is 12 bytes enough to send a packet? No, MIC & CRC alone are 12 bytes. If only we could somehow combine them… …well, title of this section is fragmentation Using 802.11 fragmentation we can combine 16 keystreams to send one large packet
- 28. Data MIC Data1 Data2 Data16 MIC TSC1 Data1 CRC1 TSC16 Data16 MIC CRC16 MIC calculated over complete packet Each fragment has CRC and different TSC 12 bytes/keystream: inject 120 bytes of data
- 29. 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!
- 30. 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!
- 32. Building packets sucks…
- 34. tcpdump -i mon0 -w crash.pcap
- 35. Target will send outgoing SYN/ACK Will this go through the firewall/NAT? Normally not… Device SYN/ACK forwarded? Scarlet VDSL Box No WAG320N No OpenBSD/PF No DD-WRT When SPI is disabled
- 36. Realistic in practice? Bidirectional traffic is possible Internet Access Point Client Attacker
- 37. Realistic in practice? Bidirectional traffic is possible Internet Access Point Client Attacker
- 38. Realistic in practice? Bidirectional traffic is possible Internet Access Point Client Attacker
- 39. Realistic in practice? Can connect to open ports Internet Access Point Client Attacker
- 40. Client running SSH server with weak password Bypass firewall using fragmentation attack Bidirectional communication is possible Connect to SSH server as root Dump the network password! Note: not been tested
- 41. Beck & Tews: Inject 3-7 packets of 28 bytes Fragmentation: Inject arbitrary amount of packets With a size up to 120 bytes Additionally, exploit IP fragmentation to transmit IP packets of arbitrary size
- 42. Belkin F5D7053: Ignores TSC… you can simply replay a packet When connected to a protected network, it still accepts unencrypted packets
- 43. Very efficient Denial of Service Use fragmentation to launch actual attacks Forced to use WPA-TKIP? Use short rekeying timeout (2 mins) Disable QoS and update drivers (if possible) Update to WPA2-AES Specifically set encryption to AES only