Abusing Wi-Fi Beacons and Detecting & Preventing Attacks Mathy - - PowerPoint PPT Presentation

▶

abusing wi fi beacons and detecting preventing attacks

Abusing Wi-Fi Beacons and Detecting & Preventing Attacks Mathy - - PowerPoint PPT Presentation

Dec 29, 2023 368 likes •801 views

Abusing Wi-Fi Beacons and Detecting & Preventing Attacks Mathy Vanhoef, Prasant Adhikari, and Christina Ppper. With special thanks to various IEEE members. Black Hat Webcast, 17 September 2020. Background: beacons Wi-Fi networks use

slide-1

SLIDE 1

Abusing Wi-Fi Beacons and Detecting & Preventing Attacks

Mathy Vanhoef, Prasant Adhikari, and Christina Pöpper. With special thanks to various IEEE members. Black Hat Webcast, 17 September 2020.

slide-2

SLIDE 2

Background: beacons

› Wi-Fi networks use beacons to announce their presence › They are sent every ~100 ms by an Access Point

2

Problem: beacons can be forged by an adversary! Contains properties of the network:

Name of the network Supported bitrates (e.g. 11n or 11ac) Regulatory constraints (e.g. transmission power) ...

slide-3

SLIDE 3

Our contributions

Novel attacks abusing beacons

3

Defense to prevent

utsider forgeries

Standardized as part of 802.11 Defense is being implemented by Linux and might become part of WPA3

slide-4

SLIDE 4

Taking a step back: Wi-Fi security

Focus was protecting data, not beacons: › WEP, WPA1/2: only includes data frame protection › WPA3: includes management frame protection › Operating channel validation: verifies channel info  In all cases beacons remain unprotected

4

slide-5

SLIDE 5

Beacons are not protected

› WPA version & channel: verified when connecting [WiSec’18] › All other fields can be spoofed by an adversary

5

slide-6

SLIDE 6 6

Novel Attacks

slide-7

SLIDE 7

Power constraint attacks

Beacons contain the maximum allowed transmit power

7

 Adversary can lower transmission power of victim

slide-8

SLIDE 8

Power constraint attacks

Beacons contain the maximum allowed transmit power Experiments: › iPad, MacBook, and Linux: lowers transmit power of device › All other test devices not affected (unknown why)

8

slide-9

SLIDE 9

Power constraint attacks

Beacons contain the maximum allowed transmit power Vendor-specific power element of Cisco: › Can also be exploited to lower transmit power of device › Linux: can be abused to forcibly disconnect a victim Normally we cannot set negative transmission limits But with the Cisco power element we can

9

slide-10

SLIDE 10

Power constraint attacks

DEMO!

10

slide-11

SLIDE 11

Lowering a victim’s bandwidth

› Before transmission the medium must be idle:

11

In use SIFS AIFSN Backoff (CW) Packet 2

slide-12

SLIDE 12

Lowering a victim’s bandwidth

› Before transmission the medium must be idle:

12

In use SIFS AIFSN Backoff (CW) Packet 2

slide-13

SLIDE 13

Lowering a victim’s bandwidth

› Before transmission the medium must be idle:

13

In use SIFS AIFSN Backoff (CW) Packet 2

slide-14

SLIDE 14

Lowering a victim’s bandwidth

› Before transmission the medium must be idle:

14

In use SIFS AIFSN Backoff (CW) Packet 2

slide-15

SLIDE 15

Lowering a victim’s bandwidth

› Before transmission the medium must be idle:

15

In use SIFS AIFSN Backoff (CW) Packet 2

slide-16

SLIDE 16

Lowering a victim’s bandwidth

› Before transmission the medium must be idle:

16

› Beacon contains the duration of these waiting periods:

In use SIFS AIFSN Backoff (CW) Packet 2

slide-17

SLIDE 17

Lowering a victim’s bandwidth

› Before transmission the medium must be idle:

17

In use SIFS AIFSN Backoff (CW) Packet 2

› Spoofing this info causes clients to delay transmissions:

In use SIFS AIFSN Backoff (CW) Pac

› If another device transmits in the meantime, the victim restarts the waiting process & possibly never transmits

slide-18

SLIDE 18

Lowering a victim’s bandwidth: experiments

Linux is affected with any network card we tested

18

Apple devices are affected (Macbook Pro, iPhone, iPad) Windows is affected depending on network card (e.g. Alfa and TP-Link cards are affected but not Intel ones) Android is affected depending on the device: Nexus 5X was affected, but not our old Samsung i9305

slide-19

SLIDE 19

Targeted unfairness

DEMO!

19

slide-20

SLIDE 20

MitM Attack

20

Channel 1

slide-21

SLIDE 21

MitM Attack

› Adversary forwards frames between both channels

21

Channel 1 Spoof beacons

n channel 6

Channel 6 Channel 1

slide-22

SLIDE 22

MitM Attack

› Adversary forwards frames between both channels › This MitM makes other attacks easier (e.g. KRACK)

22

Channel 1 Spoof beacons

n channel 6

Channel 6 Channel 1 Spoof beacons with CSAs on channel 1

slide-23

SLIDE 23

Other attacks & findings

Send beacon as unicast frames to target specific clients › Worked against all tested devices

23

Battery depletion attacks › Spoof beacons to make clients stay awake Partial machine-in-the-middle attack › Bypasses channel operating validation in Linux

slide-24

SLIDE 24

Practical attack considerations

Beacons are by default broadcasted to all clients › This means we attack all clients simultaneously

24

We can also send them as unicast frames to a specific victim:

slide-25

SLIDE 25 25

Our Defense

slide-26

SLIDE 26

Design goals

Straightforward to implement › Ideally reuse existing crypto primitives of Wi-Fi

26

Focus on practicality & simplicity to encourage adoption › Cryptographic operations must be efficient › Bandwidth overhead must be low

Beacons are sent at low bitrate and consume significant airtime

slide-27

SLIDE 27

Design approach

We defend against outsider attacks › Adversary doesn’t possess network credentials › Similar to protection of broadcast Wi-Fi traffic

27

To achieve our goals, we rely on symmetric encryption › Reuse crypto primitives of management frame protection

slide-28

SLIDE 28

Beacon protection: new element

We add a new type-length-value element to beacons:

28

Element ID Length Key ID Nonce MIC › Clients that do not recognize this element will ignore it › Nonce: incremental number to prevent replay attacks › Message Integrity Check: CMAC or GMAC over the beacon

Existing crypto primitive of management frame protection All WPA3-capable devices already support it

slide-29

SLIDE 29

Key management

Key used to generate/verify the authenticity tag? › AP generates a fresh beacon protection key when booting › AP always sends the beacon key when a client connects

Older clients will ignore this key New clients will enable beacon protection

 Adversary can’t manipulate handshake that transports the beacon key, preventing downgrade attacks.

29

slide-30

SLIDE 30

Pre-authentication behavior

30

Client cannot verify beacon before connecting (no key!) Periodic beacons

slide-31

SLIDE 31

Pre-authentication behavior

31

Store 1 beacon as reference & extra info from it Periodic beacons

slide-32

SLIDE 32

Pre-authentication behavior

32

Store 1 beacon as reference & extra info from it Connect to network and receive beacon protection key Verify authenticity reference beacon (disconnect if invalid) Periodic beacons

slide-33

SLIDE 33

Pre-authentication behavior

33

Store 1 beacon as reference & extra info from it Connect to network and receive beacon protection key Verify authenticity reference beacon (disconnect if invalid) Send data Periodic beacons

slide-34

SLIDE 34

Reporting forged beacons

› Clients can report forged beacons to the AP › Can now detect far away rouge APs

34

Out of range

slide-35

SLIDE 35

Reporting forged beacons

› Clients can report forged beacons to the AP › Can now detect far away rouge APs

35

1. Detect forged

beacon Out of range

slide-36

SLIDE 36

Reporting forged beacons

› Clients can report forged beacons to the AP › Can now detect far away rouge APs

36

1. Detect forged

beacon

2. Report

rogue AP Out of range

slide-37

SLIDE 37 37

Practical Results

slide-38

SLIDE 38

Specification

› Collaborated with industry to standardize our defense (Intel, Broadcom, Qualcomm and Huawei) › Since March 2019 part of the (draft) IEEE 802.11 standard:

38

slide-39

SLIDE 39

Specification

› Collaborated with industry to standardize our defense (Intel, Broadcom, Qualcomm and Huawei) › Since March 2019 part of the (draft) IEEE 802.11 standard:

39

Might become part of WPA3 specification? 

Source: https://www.wi-fi.org/security-development (July 2020)

slide-40

SLIDE 40

Specification

› Collaborated with industry to standardize our defense (Intel, Broadcom, Qualcomm and Huawei) › Since March 2019 part of the (draft) IEEE 802.11 standard:

40

Special thanks to: › Nehru Bhandaru and Thomas Derham (Broadcom) › Emily Qi and Ido Ouzueli (Intel) › Jouni Malinen and Menzo Wentink (Qualcomm) › Yunsong Yang (Huawei)

slide-41

SLIDE 41

Implementation

Now being implemented by Linux: › Kernel: generate and verify authentication tags › Hostap: manages keys and enables beacon protection

DEMO!

41

slide-42

SLIDE 42

Conclusion

› Prevent outsiders from forging beacons › Our focus on practicality paid off:

Defense is now part of the 802.11 standard Being implemented by Linux Might become part of WPA3?

42