1
00:00:00,000 --> 00:00:09,220
Hello, I am Mati Vanhoef and I'm going to give a presentation about our paper titled Protecting Wi-Fi Beacons from Outsider Forgeries.

2
00:00:09,300 --> 00:00:18,420
This research was published at the WISEC conference just a few months ago and this was joint work with Prasant Adhikari and Christina Popper.

3
00:00:18,620 --> 00:00:22,320
In this presentation I'm going to give a summary of our results.

4
00:00:22,600 --> 00:00:28,080
So as the title of the presentation implies, we're going to protect Wi-Fi beacons.

5
00:00:28,080 --> 00:00:32,780
Before we get into that, what exactly is a Wi-Fi beacon?

6
00:00:32,780 --> 00:00:44,860
Well, Wi-Fi networks use Wi-Fi beacons to announce their presence to nearby clients and they are sent roughly every 100 milliseconds by an access point.

7
00:00:45,320 --> 00:00:48,720
These beacons contain various properties of the network.

8
00:00:48,720 --> 00:00:59,700
For example, they contain the name of the network, they contain the supported bit range, for example, whether the network supports the 11n or 11ac standard.

9
00:00:59,880 --> 00:01:07,580
They also contain certain regulatory constraints, for example, the maximum transmission power and so on.

10
00:01:07,580 --> 00:01:15,120
But the problem in practice is that these beacons are not protected and they can be forged by an adversary.

11
00:01:15,520 --> 00:01:31,480
In our work, in this presentation, we present novel attacks that abuse beacons and motivated by these novel attacks that we discovered, we implement a defense to prevent outsiders from forging beacons.

12
00:01:31,480 --> 00:01:39,260
And we also standardized this defense as part of the 802.11 specification that underpins Wi-Fi.

13
00:01:39,520 --> 00:01:50,460
And on top of all of this, we also have an implementation on Linux and our defense might even become part of WPA3.

14
00:01:51,340 --> 00:01:58,540
But before we get into these details, let's take a step back and look at the history of Wi-Fi security.

15
00:01:58,920 --> 00:02:05,400
And here we can see that previously the focus was on protecting transmitted data and not beacons.

16
00:02:05,400 --> 00:02:13,420
For example, if we look at on WPA1 and 2, they really focus on protecting data only.

17
00:02:13,500 --> 00:02:20,600
Now, WPA3 does mandate that certain management frames are also authenticated.

18
00:02:20,600 --> 00:02:24,280
However, unfortunately, this does not include beacons.

19
00:02:24,280 --> 00:02:36,760
And even if we look at some very recent additions to Wi-Fi, such as operating channel validation, this only verifies the information about the current channel at the access point.

20
00:02:36,780 --> 00:02:49,240
In other words, even if we use all the modern standards, beacons are not protected and they can be forged by an adversary.

21
00:02:50,020 --> 00:02:57,680
And if we look at the contents inside a beacon, we see that there's a lot of information that a beacon contains.

22
00:02:57,920 --> 00:03:04,620
And a small amount of information is indirectly verified when you connect to the network.

23
00:03:04,620 --> 00:03:15,900
For example, the WPA version that is supported by the network on the current operating channel is securely verified when you are connecting to a network.

24
00:03:16,100 --> 00:03:30,140
But all the other information that is contained in a beacon, and here we are only showing a small part of the possible information in the beacon, can be spooked by an adversary and possibly be abused.

25
00:03:30,700 --> 00:03:43,240
So, the first thing that we did in our research is that we searched for novel attacks that an adversary can carry out by spoofing these beacon frames.

26
00:03:43,860 --> 00:03:51,200
One of the first attacks that we discovered is what we call a power-constrained attack.

27
00:03:51,200 --> 00:04:02,040
Namely, as I already hinted at previously, beacons contain the maximum allowed transmit power that a client should be using.

28
00:04:02,080 --> 00:04:13,400
For example, if we look at the following beacon content in Wireshark, we can see that it contains the maximum transmit power that is allowed in a certain country.

29
00:04:13,520 --> 00:04:22,680
And on top of that, the beacon can even further lower the maximum transmit power below this regulatory maximum.

30
00:04:22,980 --> 00:04:31,440
In other words, to simplify, an access point can command the client into using a certain maximum transmit power.

31
00:04:32,220 --> 00:04:40,240
An adversary can abuse this by forging a beacon that instructs clients into using an extremely low transmission power.

32
00:04:40,720 --> 00:04:45,820
In turn, this causes the network connection of the victim to become almost unusable.

33
00:04:46,100 --> 00:04:53,120
That's because the frames that the victim is transmitting will no longer reach the access point.

34
00:04:53,200 --> 00:04:58,240
Essentially, this means the client will no longer have a stable internet connection.

35
00:04:58,680 --> 00:05:14,260
So if we look in practice, we tested this attack against various operating systems, and we found that an iPad on a MacBook was vulnerable to an attack, and Linux was also vulnerable to attacks.

36
00:05:14,740 --> 00:05:16,740
Other devices were not affected.

37
00:05:16,740 --> 00:05:30,180
It is unclear why, although we conjecture that after injecting forged beacons, other devices may reset their parameters back to normal once they receive a legitimate beacon.

38
00:05:31,180 --> 00:05:37,660
Now, we also found a minor variant of this attack against Linux.

39
00:05:37,980 --> 00:05:51,280
Namely, when we were inspecting the source code of the Linux kernel, we noticed that it's also able to parse a vendor-specific information element that belonged to Cisco.

40
00:05:51,380 --> 00:06:04,600
And what's interesting about this implementation in Linux is that normally, if we follow the specification, we cannot set a negative maximum transmission power.

41
00:06:04,600 --> 00:06:09,560
But by abusing this vendor-specific element of Cisco, we can.

42
00:06:10,260 --> 00:06:24,820
And it turns out that if we are able to set a negative transmission limit, then the drivers of Linux do not handle this properly, and as a result, they forcibly are disconnected from the network.

43
00:06:25,320 --> 00:06:28,100
So let's show a demonstration of this.

44
00:06:28,180 --> 00:06:33,100
In our demo, we can see now that the victim has a stable internet connection.

45
00:06:33,260 --> 00:06:42,180
However, as an adversary, we're now going to inject 10 beacons to make sure at least one of them arrives at the victim.

46
00:06:42,360 --> 00:06:49,880
And if we now look at the debug messages of the victim, we can see that it indeed lowered its transmission power.

47
00:06:50,060 --> 00:07:00,340
And if we look in Wireshark, if we look at the spoofed beacon, it now indeed contains this power-constrained element that reduces the transmission power of the client.

48
00:07:00,340 --> 00:07:11,670
If the victim now tries to refresh the website or visit a new one, you will see that the website is no longer loading, meaning our attack was successful.

49
00:07:13,720 --> 00:07:20,170
Now, a second attack we discovered is that we can lower a victim's bandwidth by spoofing beacons.

50
00:07:20,700 --> 00:07:26,040
And this abuses the way that a normal Wi-Fi device transmits frames.

51
00:07:26,220 --> 00:07:34,600
In particular, before a Wi-Fi device will transmit a frame, it will first check whether the medium is idle or not.

52
00:07:34,680 --> 00:07:42,500
And in case another device is transmitting a frame, it will first wait until this device finished transmitting.

53
00:07:43,140 --> 00:07:49,300
And after that, it will wait a very short amount of time called the SIFS interval.

54
00:07:49,520 --> 00:07:50,920
And this is mandatory.

55
00:07:50,920 --> 00:07:54,220
Every device must wait this amount of time.

56
00:07:55,280 --> 00:08:01,880
Additionally, it will wait an amount of time that depends on the priority of the frame that it wants to transmit.

57
00:08:01,880 --> 00:08:05,320
This is called the AIFSN period.

58
00:08:05,540 --> 00:08:13,900
And for example, if the device wants to send a high priority voice packet, this period is relatively short.

59
00:08:13,900 --> 00:08:19,660
While if the device wants to send some background traffic, this period is a bit longer.

60
00:08:20,360 --> 00:08:28,880
Then finally, the device will also wait a random amount of time called the backoff window or the contention window.

61
00:08:29,060 --> 00:08:31,260
And this is a random value.

62
00:08:31,260 --> 00:08:38,240
And it is used to also give other clients an opportunity to transmit as well.

63
00:08:38,300 --> 00:08:48,200
In case during these three periods no other device started transmitting, in that case the device can transmit its own frame.

64
00:08:49,050 --> 00:08:59,140
Now, what is interesting is that the specific values for these waiting periods are determined by the network configuration.

65
00:08:59,140 --> 00:09:02,360
In particular, they are defined by the beacon.

66
00:09:02,400 --> 00:09:12,020
So, if we look at a beacon in Wireshark, we can for example see that it advertises the specific value for the AIFSN period.

67
00:09:12,260 --> 00:09:21,120
Additionally, the minimum and maximum duration of the backoff window is also defined in the beacon.

68
00:09:21,420 --> 00:09:27,480
And of course, as an adversary, we can spoof beacons where these values are very large.

69
00:09:27,480 --> 00:09:36,040
And this means we can force a victim into delaying its transmission for a longer amount of time.

70
00:09:36,420 --> 00:09:41,180
And this effectively reduces the bandwidth of a victim.

71
00:09:41,860 --> 00:09:48,160
Now, the impact can in fact be much higher than simply lowering the bandwidth of a victim.

72
00:09:48,240 --> 00:10:01,160
And that's because if another device starts transmitting during any of these waiting periods, then the device will need to completely restart its waiting procedure.

73
00:10:01,520 --> 00:10:16,440
In other words, if there is another nearby client that is downloading or uploading a file, our victim may simply never get the chance to transmit the frame and our attack will result in a denial of service.

74
00:10:16,980 --> 00:10:27,080
So, we tested this attack in practice and we found that Linux is affected independent of the network card being used.

75
00:10:27,160 --> 00:10:35,820
We also tested some Apple devices and here we found that the MacBook Pro, the iPhone, and the iPad are all vulnerable.

76
00:10:36,820 --> 00:10:47,660
We also tested Windows 10 and here we noticed that the impact depends on the specific network card that this operating system is using.

77
00:10:48,080 --> 00:10:55,960
For example, if we use an alpha or TP-Link USB Wi-Fi dongle, then we found that Windows 10 was vulnerable.

78
00:10:56,060 --> 00:11:08,740
However, if we used the built-in network card of certain laptops, which is typically an Intel network card, at least on the devices we tested, then Windows 10 was not vulnerable.

79
00:11:09,440 --> 00:11:19,560
Finally, we also tested two Android devices, one more recent Nexus 5X device, and it was vulnerable to our attack.

80
00:11:19,560 --> 00:11:25,680
But our fairly old Samsung device was not vulnerable to our attack.

81
00:11:26,000 --> 00:11:29,100
So, let's show a demo of this attack in practice.

82
00:11:29,100 --> 00:11:39,680
We will target an iPad device and we can see that before starting the attack, the iPad has a throughput of about 10 megabit per second.

83
00:11:39,720 --> 00:11:54,100
Then, as an adversary, we will spoof two beacons and if we look in Wireshark, this spoofed beacon has the maximum value for the back-off window and also the maximum value for the AIFSN waiting period as well.

84
00:11:54,200 --> 00:12:02,050
And if we now measure the throughput on the iPad, we see that it is substantially lower, meaning our attack has succeeded.

85
00:12:03,220 --> 00:12:06,000
We also discovered several other attacks.

86
00:12:06,000 --> 00:12:14,150
For instance, we discovered a partial machine-in-the-middle attack, and this attack bypasses channel operating validation in Linux.

87
00:12:14,760 --> 00:12:18,020
And for the details, I will refer you to the paper.

88
00:12:18,100 --> 00:12:27,000
We also discovered battery depletion attacks, where we can spoof beacons to make clients stay awake longer than they normally are.

89
00:12:27,000 --> 00:12:35,220
Additionally, we also found that it is possible to send beacons as unicast frames, and this allows us to target specific clients.

90
00:12:35,220 --> 00:12:39,120
This technique worked against all the devices we tested.

91
00:12:40,060 --> 00:12:43,700
So how can we prevent these attacks in practice?

92
00:12:43,920 --> 00:12:50,280
Well, the idea is to authenticate beacons such that an adversary can no longer spoof them.

93
00:12:50,280 --> 00:12:55,600
But before we get into those details, let's first state the goal of our defense.

94
00:12:55,600 --> 00:13:03,340
And the goal is to come up with a practical and simple design to encourage adoption in practice.

95
00:13:03,460 --> 00:13:19,380
So this means that our cryptographic operations must be efficient, and that the bandwidth overhead must be low as well, because beacons are sent at a low bitrate, and even adding a few bytes will consume a significantly higher airtime.

96
00:13:20,380 --> 00:13:31,480
Finally, we also want the defense to be straightforward to implement, because then this increases the chance that vendors will actually adopt our defense in practice.

97
00:13:31,480 --> 00:13:39,660
And ideally, we will accomplish this by reusing existing cryptographic primitives that were already used in Wi-Fi.

98
00:13:40,660 --> 00:13:43,640
So how can we achieve these design goals?

99
00:13:43,640 --> 00:13:52,760
Well, we will rely on symmetric encryption, we will reuse a crypto-primitive that is already part of management frame protection.

100
00:13:52,800 --> 00:13:57,000
Additionally, we only defend against outsider attacks.

101
00:13:57,000 --> 00:14:03,540
In other words, we assume that the adversary does not possess the credentials of the network.

102
00:14:03,540 --> 00:14:12,320
And this assumption is similar to how broadcast on multicast traffic is protected in WPA-213 as well.

103
00:14:12,540 --> 00:14:15,880
So concretely, how does our defense work?

104
00:14:15,880 --> 00:14:20,400
Well, we add a new type length value element to beacons.

105
00:14:20,400 --> 00:14:27,940
This element is shown here, and the two most important fields here are highlighted in green.

106
00:14:28,960 --> 00:14:39,940
Now, before I discuss the details of these two important fields, I first want to mention that clients that do not recognize this new type length value element, they will automatically ignore it.

107
00:14:39,940 --> 00:14:45,400
This makes our defense backwards compatible with existing Wi-Fi implementations.

108
00:14:45,880 --> 00:14:49,300
So first, we have the nonce field.

109
00:14:49,300 --> 00:14:55,740
And the nonce field is essentially an incremental number that is used to prevent replay attacks.

110
00:14:56,220 --> 00:15:06,280
And then the mic field, which stands for message integrity check, is a CMAQ or GMAQ authentication tag that is calculated over the beacon.

111
00:15:06,480 --> 00:15:13,460
And here the CMAQ and GMAQ are existing cryptographic primitives of management frame protection.

112
00:15:13,480 --> 00:15:25,980
And the interesting thing is that all WPA3 capable devices are already required to support these operations, meaning vendors will already have implemented them by now.

113
00:15:26,820 --> 00:15:34,020
So the remaining question now is, which key will be used to generate this authentication tag?

114
00:15:34,200 --> 00:15:41,720
And here we decided to let the access point generate a new beacon protection key when it starts.

115
00:15:41,780 --> 00:15:47,600
And this beacon protection key is always sent to the client when it is connecting.

116
00:15:47,620 --> 00:15:56,620
In particular, even if the client may not support beacon protection, the access point will still send this beacon key to the client.

117
00:15:56,620 --> 00:16:05,920
And older clients will simply ignore this new key, but new clients will treat it as an indication that the access point supports beacon protection.

118
00:16:05,920 --> 00:16:14,820
Now the interesting thing about this construction is that an adversary cannot manipulate the handshake that transports the beacon key.

119
00:16:14,820 --> 00:16:24,060
This means that downgrade attacks are prevented because an adversary cannot somehow remove the beacon key that is being transported to a client.

120
00:16:25,320 --> 00:16:34,020
The final important thing to discuss is how that clients handle beacons that are received before they have connected to a network.

121
00:16:34,160 --> 00:16:49,940
Because recall that a client only receives the beacon key once it has connected to the network, meaning that beacons that are received before that cannot be authenticated because the client does not possess the key to verify their authenticity.

122
00:16:50,080 --> 00:16:53,620
So how can we handle this in practice?

123
00:16:53,620 --> 00:17:08,160
Well, our solution is that before a client connects to a network, it will store one beacon as a reference and it will extract all information of the network from this reference beacon.

124
00:17:08,580 --> 00:17:20,200
And when the client now connects to this network and once it has received the beacon protection key, it can take this reference beacon and then verify its authenticity.

125
00:17:20,720 --> 00:17:28,680
And in case this check fails, it means there was an attack and then the client can disconnect from the network.

126
00:17:29,020 --> 00:17:43,660
On the other hand, if the authenticity of the reference beacon can be successfully validated, then the client can send data frames to the network and can operate as normal.

127
00:17:44,760 --> 00:17:51,300
Now that we have our defense, an interesting question is how a client should act when it receives a forged beacon.

128
00:17:51,460 --> 00:17:56,700
And we decided that in that case the client should send a notification to the access point.

129
00:17:57,000 --> 00:18:01,460
This allows the access point to detect rogue IPs that are far away.

130
00:18:01,500 --> 00:18:07,120
For example, in our illustration here, the rogue IP is out of range of the real IP.

131
00:18:07,160 --> 00:18:18,720
However, when a client receives a forged beacon from the rogue IP, it can notify the real access point of this and then the real access point can take appropriate actions.

132
00:18:19,080 --> 00:18:22,960
So now I want to discuss some practical impact of our research.

133
00:18:23,000 --> 00:18:31,180
First and foremost, we created our specification of our defense in collaboration with Intel, Broadcom, Qualcomm, and Huawei.

134
00:18:31,380 --> 00:18:41,000
And our defense is now part of the draft IEEE 802.11 standard, meaning vendors will likely adopt this in practice as well.

135
00:18:41,340 --> 00:18:56,140
Moreover, the Wi-Fi Alliance has recently expressed interest in our defense as well, meaning it might become part of an update to WPA3 or it might become part of a separate certification program.

136
00:18:56,420 --> 00:19:09,540
Our defense is independently also being implemented by Linux, where the kernel generates and verifies authentication tags and host AP manages keys and enables beacon protection if it is supported by the network.

137
00:19:09,560 --> 00:19:21,800
We will now show a demo of this on a recent Linux kernel, where if we start the access point and view the beacons in Wireshark, we can indeed see that the authentication tag is being added to beacons.

138
00:19:21,980 --> 00:19:29,500
If we now connect to this network, the client will indeed receive the beacon protection key and it will enable beacon protection.

139
00:19:29,660 --> 00:19:36,240
As a result, if we now inject a beacon as an adversary, the client will detect this spoofed beacon.

140
00:19:36,520 --> 00:19:47,320
In this demo, we made the client print a small debug message, and if we now look at the debug log, we can confirm that the forged beacon has been detected and the attack has been prevented.

141
00:19:48,880 --> 00:20:00,900
To conclude our talk, we proposed a defense to prevent outsiders from forging beacons, and our focus on practicality has paid off, because our defense is now part of the 802.11 standard.

142
00:20:00,900 --> 00:20:07,920
It is independently being implemented by Linux, and it might become part of an update to WPA3.

143
00:20:07,920 --> 00:20:09,580
Thank you for your attention.