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