[00:00.000 --> 00:05.200] Hello, I am Mati Vanhoef and I'm going to give a presentation about our paper titled [00:05.200 --> 00:12.340] Protecting Wi-Fi Beacons from Outsider Forgeries. This research was published at the WISEC conference [00:12.340 --> 00:18.420] just a few months ago and this was joint work with Prasant Adhikari and Christina Popper. [00:18.620 --> 00:24.600] In this presentation I'm going to give a summary of our results. So as the title of the presentation [00:24.600 --> 00:31.740] implies, we're going to protect Wi-Fi beacons. Before we get into that, what exactly is a Wi-Fi [00:31.740 --> 00:38.820] beacon? Well, Wi-Fi networks use Wi-Fi beacons to announce their presence to nearby clients [00:38.820 --> 00:46.960] and they are sent roughly every 100 milliseconds by an access point. These beacons contain various [00:46.960 --> 00:51.420] properties of the network. For example, they contain the name of the network, [00:51.420 --> 00:58.280] they contain the supported bit range, for example, whether the network supports the 11n or 11ac [00:58.280 --> 01:05.240] standard. They also contain certain regulatory constraints, for example, the maximum transmission [01:05.240 --> 01:12.580] power and so on. But the problem in practice is that these beacons are not protected and they can [01:12.580 --> 01:20.660] be forged by an adversary. In our work, in this presentation, we present novel attacks that abuse [01:20.660 --> 01:28.080] beacons and motivated by these novel attacks that we discovered, we implement a defense to prevent [01:28.080 --> 01:35.260] outsiders from forging beacons. And we also standardized this defense as part of the 802.11 [01:35.260 --> 01:44.060] specification that underpins Wi-Fi. And on top of all of this, we also have an implementation on [01:44.060 --> 01:54.240] Linux and our defense might even become part of WPA3. But before we get into these details, [01:54.240 --> 01:59.840] let's take a step back and look at the history of Wi-Fi security. And here we can see that [01:59.840 --> 02:06.780] previously the focus was on protecting transmitted data and not beacons. For example, if we look at [02:06.780 --> 02:17.400] on WPA1 and 2, they really focus on protecting data only. Now, WPA3 does mandate that certain [02:17.400 --> 02:24.280] management frames are also authenticated. However, unfortunately, this does not include beacons. [02:24.280 --> 02:32.100] And even if we look at some very recent additions to Wi-Fi, such as operating channel validation, [02:32.100 --> 02:36.760] this only verifies the information about the current channel at the access point. [02:36.780 --> 02:44.280] In other words, even if we use all the modern standards, [02:44.280 --> 02:52.320] beacons are not protected and they can be forged by an adversary. And if we look at the contents [02:52.320 --> 02:59.220] inside a beacon, we see that there's a lot of information that a beacon contains. And a small [02:59.220 --> 03:06.400] amount of information is indirectly verified when you connect to the network. For example, the WPA [03:06.400 --> 03:12.840] version that is supported by the network on the current operating channel is securely verified [03:12.840 --> 03:19.840] when you are connecting to a network. But all the other information that is contained in a beacon, [03:19.840 --> 03:24.680] and here we are only showing a small part of the possible information in the beacon, [03:25.040 --> 03:33.520] can be spooked by an adversary and possibly be abused. So, the first thing that we did in our [03:33.520 --> 03:41.200] research is that we searched for novel attacks that an adversary can carry out by spoofing these [03:41.200 --> 03:49.840] beacon frames. One of the first attacks that we discovered is what we call a power-constrained [03:49.840 --> 03:58.960] attack. Namely, as I already hinted at previously, beacons contain the maximum allowed transmit power [03:58.960 --> 04:07.260] that a client should be using. For example, if we look at the following beacon content in Wireshark, [04:07.260 --> 04:13.700] we can see that it contains the maximum transmit power that is allowed in a certain country. And [04:13.700 --> 04:20.840] on top of that, the beacon can even further lower the maximum transmit power below this [04:20.840 --> 04:28.700] regulatory maximum. In other words, to simplify, an access point can command the client into using [04:28.860 --> 04:36.420] a certain maximum transmit power. An adversary can abuse this by forging a beacon that instructs [04:36.420 --> 04:42.620] clients into using an extremely low transmission power. In turn, this causes the network connection [04:42.620 --> 04:49.880] of the victim to become almost unusable. That's because the frames that the victim is transmitting [04:49.880 --> 04:56.240] will no longer reach the access point. Essentially, this means the client will no longer have a stable [04:56.240 --> 05:03.440] internet connection. So if we look in practice, we tested this attack against various operating [05:03.440 --> 05:11.880] systems, and we found that an iPad on a MacBook was vulnerable to an attack, and Linux was also [05:11.880 --> 05:20.300] vulnerable to attacks. Other devices were not affected. It is unclear why, although we conjecture [05:20.300 --> 05:27.500] that after injecting forged beacons, other devices may reset their parameters back to normal once [05:27.500 --> 05:36.320] they receive a legitimate beacon. Now, we also found a minor variant of this attack against [05:36.320 --> 05:43.740] Linux. Namely, when we were inspecting the source code of the Linux kernel, we noticed that it's [05:43.740 --> 05:52.380] also able to parse a vendor-specific information element that belonged to Cisco. And what's [05:52.380 --> 06:00.540] interesting about this implementation in Linux is that normally, if we follow the specification, [06:00.540 --> 06:07.140] we cannot set a negative maximum transmission power. But by abusing this vendor-specific element [06:07.140 --> 06:16.260] of Cisco, we can. And it turns out that if we are able to set a negative transmission limit, [06:16.260 --> 06:22.140] then the drivers of Linux do not handle this properly, and as a result, they forcibly are [06:22.140 --> 06:29.800] disconnected from the network. So let's show a demonstration of this. In our demo, we can see now [06:29.800 --> 06:35.960] that the victim has a stable internet connection. However, as an adversary, we're now going to [06:35.960 --> 06:43.060] inject 10 beacons to make sure at least one of them arrives at the victim. And if we now look [06:43.060 --> 06:49.880] at the debug messages of the victim, we can see that it indeed lowered its transmission power. [06:50.060 --> 06:55.060] And if we look in Wireshark, if we look at the spoofed beacon, it now indeed contains this [06:55.060 --> 07:00.340] power-constrained element that reduces the transmission power of the client. [07:00.340 --> 07:06.440] If the victim now tries to refresh the website or visit a new one, you will see that [07:06.440 --> 07:11.670] 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:28.360] And this abuses the way that a normal Wi-Fi device transmits frames. In particular, before a Wi-Fi [07:28.360 --> 07:35.660] device will transmit a frame, it will first check whether the medium is idle or not. And in case [07:35.660 --> 07:42.500] 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:57.100] And this is mandatory. Every device must wait this amount of time. Additionally, it will wait [07:57.100 --> 08:02.340] an amount of time that depends on the priority of the frame that it wants to transmit. This is [08:02.340 --> 08:11.300] called the AIFSN period. And for example, if the device wants to send a high priority voice packet, [08:11.300 --> 08:17.000] this period is relatively short. While if the device wants to send some background traffic, [08:17.000 --> 08:24.620] this period is a bit longer. Then finally, the device will also wait a random amount of time [08:24.620 --> 08:32.920] called the backoff window or the contention window. And this is a random value. And it is used to [08:32.920 --> 08:40.720] also give other clients an opportunity to transmit as well. In case during these three periods no [08:40.720 --> 08:48.200] other device started transmitting, in that case the device can transmit its own frame. [08:49.050 --> 08:56.480] Now, what is interesting is that the specific values for these waiting periods are determined [08:56.480 --> 09:04.220] by the network configuration. In particular, they are defined by the beacon. So, if we look at a [09:04.220 --> 09:10.720] beacon in Wireshark, we can for example see that it advertises the specific value for the AIFSN [09:10.720 --> 09:19.460] period. Additionally, the minimum and maximum duration of the backoff window is also defined [09:19.460 --> 09:26.420] in the beacon. And of course, as an adversary, we can spoof beacons where these values are very [09:26.420 --> 09:35.040] large. And this means we can force a victim into delaying its transmission for a longer amount of [09:35.040 --> 09:44.080] time. And this effectively reduces the bandwidth of a victim. Now, the impact can in fact be much [09:44.800 --> 09:50.760] higher than simply lowering the bandwidth of a victim. And that's because if another device [09:50.760 --> 09:58.160] starts transmitting during any of these waiting periods, then the device will need to completely [09:58.160 --> 10:04.840] restart its waiting procedure. In other words, if there is another nearby client that is [10:05.420 --> 10:11.760] downloading or uploading a file, our victim may simply never get the chance to transmit the frame [10:11.760 --> 10:21.280] and our attack will result in a denial of service. So, we tested this attack in practice and we found [10:21.280 --> 10:30.100] that Linux is affected independent of the network card being used. We also tested some Apple devices [10:30.100 --> 10:35.820] and here we found that the MacBook Pro, the iPhone, and the iPad are all vulnerable. [10:36.820 --> 10:44.640] We also tested Windows 10 and here we noticed that the impact depends on the specific network card [10:44.640 --> 10:52.940] that this operating system is using. For example, if we use an alpha or TP-Link USB Wi-Fi dongle, [10:52.940 --> 10:59.820] then we found that Windows 10 was vulnerable. However, if we used the built-in network card [10:59.820 --> 11:06.620] of certain laptops, which is typically an Intel network card, at least on the devices we tested, [11:06.620 --> 11:14.400] then Windows 10 was not vulnerable. Finally, we also tested two Android devices, one more [11:14.400 --> 11:22.480] recent Nexus 5X device, and it was vulnerable to our attack. But our fairly old Samsung device [11:22.480 --> 11:29.100] was not vulnerable to our attack. So, let's show a demo of this attack in practice. [11:29.100 --> 11:36.200] We will target an iPad device and we can see that before starting the attack, the iPad has a [11:36.200 --> 11:43.160] throughput of about 10 megabit per second. Then, as an adversary, we will spoof two beacons and if [11:43.160 --> 11:49.220] we look in Wireshark, this spoofed beacon has the maximum value for the back-off window and also the [11:49.220 --> 11:57.240] maximum value for the AIFSN waiting period as well. And if we now measure the throughput on the iPad, [11:57.240 --> 12:02.050] we see that it is substantially lower, meaning our attack has succeeded. [12:03.220 --> 12:07.860] We also discovered several other attacks. For instance, we discovered a partial [12:07.860 --> 12:14.150] machine-in-the-middle attack, and this attack bypasses channel operating validation in Linux. [12:14.760 --> 12:20.700] And for the details, I will refer you to the paper. We also discovered battery depletion attacks, [12:20.700 --> 12:27.000] where we can spoof beacons to make clients stay awake longer than they normally are. [12:27.000 --> 12:32.940] Additionally, we also found that it is possible to send beacons as unicast frames, and this allows [12:32.940 --> 12:39.120] us to target specific clients. This technique worked against all the devices we tested. [12:40.060 --> 12:46.820] So how can we prevent these attacks in practice? Well, the idea is to authenticate beacons such [12:46.820 --> 12:53.080] that an adversary can no longer spoof them. But before we get into those details, let's first [12:53.080 --> 13:00.020] state the goal of our defense. And the goal is to come up with a practical and simple design [13:00.020 --> 13:06.520] to encourage adoption in practice. So this means that our cryptographic operations must be [13:06.520 --> 13:12.620] efficient, and that the bandwidth overhead must be low as well, because beacons are sent at a low [13:12.620 --> 13:19.380] bitrate, and even adding a few bytes will consume a significantly higher airtime. [13:20.380 --> 13:25.760] Finally, we also want the defense to be straightforward to implement, because then this [13:25.760 --> 13:32.820] increases the chance that vendors will actually adopt our defense in practice. And ideally, [13:32.820 --> 13:38.220] we will accomplish this by reusing existing cryptographic primitives that were already used in [13:38.220 --> 13:46.640] Wi-Fi. So how can we achieve these design goals? Well, we will rely on symmetric encryption, [13:46.640 --> 13:53.800] we will reuse a crypto-primitive that is already part of management frame protection. Additionally, [13:53.800 --> 14:00.160] we only defend against outsider attacks. In other words, we assume that the adversary does not [14:00.160 --> 14:06.560] possess the credentials of the network. And this assumption is similar to how broadcast [14:06.560 --> 14:15.880] on multicast traffic is protected in WPA-213 as well. So concretely, how does our defense work? [14:15.880 --> 14:22.480] Well, we add a new type length value element to beacons. This element is shown here, [14:22.480 --> 14:27.940] and the two most important fields here are highlighted in green. [14:28.960 --> 14:33.860] Now, before I discuss the details of these two important fields, I first want to mention that [14:33.860 --> 14:38.700] clients that do not recognize this new type length value element, they will automatically [14:38.700 --> 14:45.400] ignore it. This makes our defense backwards compatible with existing Wi-Fi implementations. [14:45.880 --> 14:52.960] So first, we have the nonce field. And the nonce field is essentially an incremental number that [14:52.960 --> 15:00.440] is used to prevent replay attacks. And then the mic field, which stands for message integrity check, [15:00.440 --> 15:07.880] is a CMAQ or GMAQ authentication tag that is calculated over the beacon. And here the CMAQ [15:07.880 --> 15:14.140] and GMAQ are existing cryptographic primitives of management frame protection. And the interesting [15:14.140 --> 15:21.600] thing is that all WPA3 capable devices are already required to support these operations, [15:21.600 --> 15:25.980] 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:40.620] And here we decided to let the access point generate a new beacon protection key when it [15:40.620 --> 15:47.920] starts. And this beacon protection key is always sent to the client when it is connecting. In [15:47.920 --> 15:53.480] particular, even if the client may not support beacon protection, the access point will still [15:53.480 --> 15:59.500] send this beacon key to the client. And older clients will simply ignore this new key, [15:59.500 --> 16:05.920] but new clients will treat it as an indication that the access point supports beacon protection. [16:05.920 --> 16:12.240] Now the interesting thing about this construction is that an adversary cannot manipulate the [16:12.240 --> 16:17.700] handshake that transports the beacon key. This means that downgrade attacks are prevented because [16:17.700 --> 16:24.060] an adversary cannot somehow remove the beacon key that is being transported to a client. [16:25.320 --> 16:31.760] The final important thing to discuss is how that clients handle beacons that are received before [16:31.760 --> 16:38.080] they have connected to a network. Because recall that a client only receives the beacon key once [16:38.080 --> 16:43.960] it has connected to the network, meaning that beacons that are received before that cannot be [16:43.960 --> 16:51.280] authenticated because the client does not possess the key to verify their authenticity. So how can [16:51.280 --> 16:59.340] we handle this in practice? Well, our solution is that before a client connects to a network, [16:59.340 --> 17:05.640] it will store one beacon as a reference and it will extract all information of the network [17:05.640 --> 17:13.140] from this reference beacon. And when the client now connects to this network and once it has [17:13.140 --> 17:18.820] received the beacon protection key, it can take this reference beacon and then verify its [17:18.820 --> 17:26.020] authenticity. And in case this check fails, it means there was an attack and then the client [17:26.020 --> 17:33.100] can disconnect from the network. On the other hand, if the authenticity of the reference beacon [17:33.100 --> 17:41.760] can be successfully validated, then the client can send data frames to the network and can operate [17:41.760 --> 17:48.540] as normal. Now that we have our defense, an interesting question is how a client should [17:48.540 --> 17:53.900] act when it receives a forged beacon. And we decided that in that case the client should [17:53.900 --> 17:59.960] send a notification to the access point. This allows the access point to detect rogue IPs that [17:59.960 --> 18:07.120] are far away. For example, in our illustration here, the rogue IP is out of range of the real IP. [18:07.160 --> 18:13.500] However, when a client receives a forged beacon from the rogue IP, it can notify the real access [18:13.500 --> 18:20.220] point of this and then the real access point can take appropriate actions. So now I want to discuss [18:20.220 --> 18:26.100] some practical impact of our research. First and foremost, we created our specification of our [18:26.100 --> 18:33.340] defense in collaboration with Intel, Broadcom, Qualcomm, and Huawei. And our defense is now part of the [18:33.340 --> 18:42.180] draft IEEE 802.11 standard, meaning vendors will likely adopt this in practice as well. Moreover, [18:42.180 --> 18:47.860] the Wi-Fi Alliance has recently expressed interest in our defense as well, meaning it might become [18:47.860 --> 18:57.140] part of an update to WPA3 or it might become part of a separate certification program. Our defense [18:57.140 --> 19:02.940] is independently also being implemented by Linux, where the kernel generates and verifies authentication [19:02.940 --> 19:09.540] tags and host AP manages keys and enables beacon protection if it is supported by the network. [19:09.560 --> 19:15.320] We will now show a demo of this on a recent Linux kernel, where if we start the access point and [19:15.320 --> 19:20.760] view the beacons in Wireshark, we can indeed see that the authentication tag is being added to [19:20.760 --> 19:26.640] beacons. If we now connect to this network, the client will indeed receive the beacon protection [19:26.640 --> 19:33.520] key and it will enable beacon protection. As a result, if we now inject a beacon as an adversary, [19:33.520 --> 19:40.100] the client will detect this spoofed beacon. In this demo, we made the client print a small debug message, [19:40.100 --> 19:44.700] and if we now look at the debug log, we can confirm that the forged beacon has been detected [19:44.700 --> 19:52.040] and the attack has been prevented. To conclude our talk, we proposed a defense to prevent [19:52.040 --> 19:58.040] outsiders from forging beacons, and our focus on practicality has paid off, because our defense is [19:58.040 --> 20:04.740] now part of the 802.11 standard. It is independently being implemented by Linux, and it might become [20:04.740 --> 20:09.580] part of an update to WPA3. Thank you for your attention.