WEBVTT 00:00.000 --> 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. 00:09.300 --> 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. 00:18.620 --> 00:22.320 In this presentation I'm going to give a summary of our results. 00:22.600 --> 00:28.080 So as the title of the presentation implies, we're going to protect Wi-Fi beacons. 00:28.080 --> 00:32.780 Before we get into that, what exactly is a Wi-Fi beacon? 00:32.780 --> 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. 00:45.320 --> 00:48.720 These beacons contain various properties of the network. 00:48.720 --> 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. 00:59.880 --> 01:07.580 They also contain certain regulatory constraints, for example, the maximum transmission power and so on. 01:07.580 --> 01:15.120 But the problem in practice is that these beacons are not protected and they can be forged by an adversary. 01:15.520 --> 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. 01:31.480 --> 01:39.260 And we also standardized this defense as part of the 802.11 specification that underpins Wi-Fi. 01:39.520 --> 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. 01:51.340 --> 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. 01:58.920 --> 02:05.400 And here we can see that previously the focus was on protecting transmitted data and not beacons. 02:05.400 --> 02:13.420 For example, if we look at on WPA1 and 2, they really focus on protecting data only. 02:13.500 --> 02:20.600 Now, WPA3 does mandate that certain management frames are also authenticated. 02:20.600 --> 02:24.280 However, unfortunately, this does not include beacons. 02:24.280 --> 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. 02:36.780 --> 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. 02:50.020 --> 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. 02:57.920 --> 03:04.620 And a small amount of information is indirectly verified when you connect to the network. 03:04.620 --> 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. 03:16.100 --> 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. 03:30.700 --> 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. 03:43.860 --> 03:51.200 One of the first attacks that we discovered is what we call a power-constrained attack. 03:51.200 --> 04:02.040 Namely, as I already hinted at previously, beacons contain the maximum allowed transmit power that a client should be using. 04:02.080 --> 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. 04:13.520 --> 04:22.680 And on top of that, the beacon can even further lower the maximum transmit power below this regulatory maximum. 04:22.980 --> 04:31.440 In other words, to simplify, an access point can command the client into using a certain maximum transmit power. 04:32.220 --> 04:40.240 An adversary can abuse this by forging a beacon that instructs clients into using an extremely low transmission power. 04:40.720 --> 04:45.820 In turn, this causes the network connection of the victim to become almost unusable. 04:46.100 --> 04:53.120 That's because the frames that the victim is transmitting will no longer reach the access point. 04:53.200 --> 04:58.240 Essentially, this means the client will no longer have a stable internet connection. 04:58.680 --> 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. 05:14.740 --> 05:16.740 Other devices were not affected. 05:16.740 --> 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. 05:31.180 --> 05:37.660 Now, we also found a minor variant of this attack against Linux. 05:37.980 --> 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. 05:51.380 --> 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. 06:04.600 --> 06:09.560 But by abusing this vendor-specific element of Cisco, we can. 06:10.260 --> 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. 06:25.320 --> 06:28.100 So let's show a demonstration of this. 06:28.180 --> 06:33.100 In our demo, we can see now that the victim has a stable internet connection. 06:33.260 --> 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. 06:42.360 --> 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. 06:50.060 --> 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. 07:00.340 --> 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. 07:13.720 --> 07:20.170 Now, a second attack we discovered is that we can lower a victim's bandwidth by spoofing beacons. 07:20.700 --> 07:26.040 And this abuses the way that a normal Wi-Fi device transmits frames. 07:26.220 --> 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. 07:34.680 --> 07:42.500 And in case another device is transmitting a frame, it will first wait until this device finished transmitting. 07:43.140 --> 07:49.300 And after that, it will wait a very short amount of time called the SIFS interval. 07:49.520 --> 07:50.920 And this is mandatory. 07:50.920 --> 07:54.220 Every device must wait this amount of time. 07:55.280 --> 08:01.880 Additionally, it will wait an amount of time that depends on the priority of the frame that it wants to transmit. 08:01.880 --> 08:05.320 This is called the AIFSN period. 08:05.540 --> 08:13.900 And for example, if the device wants to send a high priority voice packet, this period is relatively short. 08:13.900 --> 08:19.660 While if the device wants to send some background traffic, this period is a bit longer. 08:20.360 --> 08:28.880 Then finally, the device will also wait a random amount of time called the backoff window or the contention window. 08:29.060 --> 08:31.260 And this is a random value. 08:31.260 --> 08:38.240 And it is used to also give other clients an opportunity to transmit as well. 08:38.300 --> 08:48.200 In case during these three periods no other device started transmitting, in that case the device can transmit its own frame. 08:49.050 --> 08:59.140 Now, what is interesting is that the specific values for these waiting periods are determined by the network configuration. 08:59.140 --> 09:02.360 In particular, they are defined by the beacon. 09:02.400 --> 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. 09:12.260 --> 09:21.120 Additionally, the minimum and maximum duration of the backoff window is also defined in the beacon. 09:21.420 --> 09:27.480 And of course, as an adversary, we can spoof beacons where these values are very large. 09:27.480 --> 09:36.040 And this means we can force a victim into delaying its transmission for a longer amount of time. 09:36.420 --> 09:41.180 And this effectively reduces the bandwidth of a victim. 09:41.860 --> 09:48.160 Now, the impact can in fact be much higher than simply lowering the bandwidth of a victim. 09:48.240 --> 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. 10:01.520 --> 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. 10:16.980 --> 10:27.080 So, we tested this attack in practice and we found that Linux is affected independent of the network card being used. 10:27.160 --> 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. 10:36.820 --> 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. 10:48.080 --> 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. 10:56.060 --> 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. 11:09.440 --> 11:19.560 Finally, we also tested two Android devices, one more recent Nexus 5X device, and it was vulnerable to our attack. 11:19.560 --> 11:25.680 But our fairly old Samsung device was not vulnerable to our attack. 11:26.000 --> 11:29.100 So, let's show a demo of this attack in practice. 11:29.100 --> 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. 11:39.720 --> 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. 11:54.200 --> 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. 12:03.220 --> 12:06.000 We also discovered several other attacks. 12:06.000 --> 12:14.150 For instance, we discovered a partial machine-in-the-middle attack, and this attack bypasses channel operating validation in Linux. 12:14.760 --> 12:18.020 And for the details, I will refer you to the paper. 12:18.100 --> 12:27.000 We also discovered battery depletion attacks, where we can spoof beacons to make clients stay awake longer than they normally are. 12:27.000 --> 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. 12:35.220 --> 12:39.120 This technique worked against all the devices we tested. 12:40.060 --> 12:43.700 So how can we prevent these attacks in practice? 12:43.920 --> 12:50.280 Well, the idea is to authenticate beacons such that an adversary can no longer spoof them. 12:50.280 --> 12:55.600 But before we get into those details, let's first state the goal of our defense. 12:55.600 --> 13:03.340 And the goal is to come up with a practical and simple design to encourage adoption in practice. 13:03.460 --> 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. 13:20.380 --> 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. 13:31.480 --> 13:39.660 And ideally, we will accomplish this by reusing existing cryptographic primitives that were already used in Wi-Fi. 13:40.660 --> 13:43.640 So how can we achieve these design goals? 13:43.640 --> 13:52.760 Well, we will rely on symmetric encryption, we will reuse a crypto-primitive that is already part of management frame protection. 13:52.800 --> 13:57.000 Additionally, we only defend against outsider attacks. 13:57.000 --> 14:03.540 In other words, we assume that the adversary does not possess the credentials of the network. 14:03.540 --> 14:12.320 And this assumption is similar to how broadcast on multicast traffic is protected in WPA-213 as well. 14:12.540 --> 14:15.880 So concretely, how does our defense work? 14:15.880 --> 14:20.400 Well, we add a new type length value element to beacons. 14:20.400 --> 14:27.940 This element is shown here, and the two most important fields here are highlighted in green. 14:28.960 --> 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. 14:39.940 --> 14:45.400 This makes our defense backwards compatible with existing Wi-Fi implementations. 14:45.880 --> 14:49.300 So first, we have the nonce field. 14:49.300 --> 14:55.740 And the nonce field is essentially an incremental number that is used to prevent replay attacks. 14:56.220 --> 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. 15:06.480 --> 15:13.460 And here the CMAQ and GMAQ are existing cryptographic primitives of management frame protection. 15:13.480 --> 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. 15:26.820 --> 15:34.020 So the remaining question now is, which key will be used to generate this authentication tag? 15:34.200 --> 15:41.720 And here we decided to let the access point generate a new beacon protection key when it starts. 15:41.780 --> 15:47.600 And this beacon protection key is always sent to the client when it is connecting. 15:47.620 --> 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. 15:56.620 --> 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. 16:05.920 --> 16:14.820 Now the interesting thing about this construction is that an adversary cannot manipulate the handshake that transports the beacon key. 16:14.820 --> 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. 16:25.320 --> 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. 16:34.160 --> 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. 16:50.080 --> 16:53.620 So how can we handle this in practice? 16:53.620 --> 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. 17:08.580 --> 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. 17:20.720 --> 17:28.680 And in case this check fails, it means there was an attack and then the client can disconnect from the network. 17:29.020 --> 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. 17:44.760 --> 17:51.300 Now that we have our defense, an interesting question is how a client should act when it receives a forged beacon. 17:51.460 --> 17:56.700 And we decided that in that case the client should send a notification to the access point. 17:57.000 --> 18:01.460 This allows the access point to detect rogue IPs that are far away. 18:01.500 --> 18:07.120 For example, in our illustration here, the rogue IP is out of range of the real IP. 18:07.160 --> 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. 18:19.080 --> 18:22.960 So now I want to discuss some practical impact of our research. 18:23.000 --> 18:31.180 First and foremost, we created our specification of our defense in collaboration with Intel, Broadcom, Qualcomm, and Huawei. 18:31.380 --> 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. 18:41.340 --> 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. 18:56.420 --> 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. 19:09.560 --> 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. 19:21.980 --> 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. 19:29.660 --> 19:36.240 As a result, if we now inject a beacon as an adversary, the client will detect this spoofed beacon. 19:36.520 --> 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. 19:48.880 --> 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. 20:00.900 --> 20:07.920 It is independently being implemented by Linux, and it might become part of an update to WPA3. 20:07.920 --> 20:09.580 Thank you for your attention.