Hello, I am Mati Vanhoef and I'm going to give a presentation about our paper titled
Protecting Wi-Fi Beacons from Outsider Forgeries. This research was published at the WISEC conference
just a few months ago and this was joint work with Prasant Adhikari and Christina Popper.
In this presentation I'm going to give a summary of our results. So as the title of the presentation
implies, we're going to protect Wi-Fi beacons. Before we get into that, what exactly is a Wi-Fi
beacon? 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. These beacons contain various
properties of the network. 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. They also contain certain regulatory constraints, for example, the maximum transmission
power and so on. But the problem in practice is that these beacons are not protected and they can
be forged by an adversary. 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. And we also standardized this defense as part of the 802.11
specification that underpins Wi-Fi. And on top of all of this, we also have an implementation on
Linux and our defense might even become part of WPA3. But before we get into these details,
let's take a step back and look at the history of Wi-Fi security. And here we can see that
previously the focus was on protecting transmitted data and not beacons. For example, if we look at
on WPA1 and 2, they really focus on protecting data only. Now, WPA3 does mandate that certain
management frames are also authenticated. However, unfortunately, this does not include beacons.
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.
In other words, even if we use all the modern standards,
beacons are not protected and they can be forged by an adversary. And if we look at the contents
inside a beacon, we see that there's a lot of information that a beacon contains. And a small
amount of information is indirectly verified when you connect to the network. 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. 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. 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. One of the first attacks that we discovered is what we call a power-constrained
attack. Namely, as I already hinted at previously, beacons contain the maximum allowed transmit power
that a client should be using. 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. And
on top of that, the beacon can even further lower the maximum transmit power below this
regulatory maximum. In other words, to simplify, an access point can command the client into using
a certain maximum transmit power. An adversary can abuse this by forging a beacon that instructs
clients into using an extremely low transmission power. In turn, this causes the network connection
of the victim to become almost unusable. That's because the frames that the victim is transmitting
will no longer reach the access point. Essentially, this means the client will no longer have a stable
internet connection. 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. Other devices were not affected. 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. Now, we also found a minor variant of this attack against
Linux. 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. 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. But by abusing this vendor-specific element
of Cisco, we can. 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. So let's show a demonstration of this. In our demo, we can see now
that the victim has a stable internet connection. However, as an adversary, we're now going to
inject 10 beacons to make sure at least one of them arrives at the victim. And if we now look
at the debug messages of the victim, we can see that it indeed lowered its transmission power.
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.
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.
Now, a second attack we discovered is that we can lower a victim's bandwidth by spoofing beacons.
And this abuses the way that a normal Wi-Fi device transmits frames. In particular, before a Wi-Fi
device will transmit a frame, it will first check whether the medium is idle or not. And in case
another device is transmitting a frame, it will first wait until this device finished transmitting.
And after that, it will wait a very short amount of time called the SIFS interval.
And this is mandatory. Every device must wait this amount of time. Additionally, it will wait
an amount of time that depends on the priority of the frame that it wants to transmit. This is
called the AIFSN period. And for example, if the device wants to send a high priority voice packet,
this period is relatively short. While if the device wants to send some background traffic,
this period is a bit longer. Then finally, the device will also wait a random amount of time
called the backoff window or the contention window. And this is a random value. And it is used to
also give other clients an opportunity to transmit as well. In case during these three periods no
other device started transmitting, in that case the device can transmit its own frame.
Now, what is interesting is that the specific values for these waiting periods are determined
by the network configuration. In particular, they are defined by the beacon. So, if we look at a
beacon in Wireshark, we can for example see that it advertises the specific value for the AIFSN
period. Additionally, the minimum and maximum duration of the backoff window is also defined
in the beacon. And of course, as an adversary, we can spoof beacons where these values are very
large. And this means we can force a victim into delaying its transmission for a longer amount of
time. And this effectively reduces the bandwidth of a victim. Now, the impact can in fact be much
higher than simply lowering the bandwidth of a victim. 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. 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. So, we tested this attack in practice and we found
that Linux is affected independent of the network card being used. We also tested some Apple devices
and here we found that the MacBook Pro, the iPhone, and the iPad are all vulnerable.
We also tested Windows 10 and here we noticed that the impact depends on the specific network card
that this operating system is using. For example, if we use an alpha or TP-Link USB Wi-Fi dongle,
then we found that Windows 10 was vulnerable. 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. Finally, we also tested two Android devices, one more
recent Nexus 5X device, and it was vulnerable to our attack. But our fairly old Samsung device
was not vulnerable to our attack. So, let's show a demo of this attack in practice.
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. 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. And if we now measure the throughput on the iPad,
we see that it is substantially lower, meaning our attack has succeeded.
We also discovered several other attacks. For instance, we discovered a partial
machine-in-the-middle attack, and this attack bypasses channel operating validation in Linux.
And for the details, I will refer you to the paper. We also discovered battery depletion attacks,
where we can spoof beacons to make clients stay awake longer than they normally are.
Additionally, we also found that it is possible to send beacons as unicast frames, and this allows
us to target specific clients. This technique worked against all the devices we tested.
So how can we prevent these attacks in practice? Well, the idea is to authenticate beacons such
that an adversary can no longer spoof them. But before we get into those details, let's first
state the goal of our defense. And the goal is to come up with a practical and simple design
to encourage adoption in practice. 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.
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. And ideally,
we will accomplish this by reusing existing cryptographic primitives that were already used in
Wi-Fi. So how can we achieve these design goals? Well, we will rely on symmetric encryption,
we will reuse a crypto-primitive that is already part of management frame protection. Additionally,
we only defend against outsider attacks. In other words, we assume that the adversary does not
possess the credentials of the network. And this assumption is similar to how broadcast
on multicast traffic is protected in WPA-213 as well. So concretely, how does our defense work?
Well, we add a new type length value element to beacons. This element is shown here,
and the two most important fields here are highlighted in green.
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. This makes our defense backwards compatible with existing Wi-Fi implementations.
So first, we have the nonce field. And the nonce field is essentially an incremental number that
is used to prevent replay attacks. And then the mic field, which stands for message integrity check,
is a CMAQ or GMAQ authentication tag that is calculated over the beacon. And here the CMAQ
and GMAQ are existing cryptographic primitives of management frame protection. 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.
So the remaining question now is, which key will be used to generate this authentication tag?
And here we decided to let the access point generate a new beacon protection key when it
starts. And this beacon protection key is always sent to the client when it is connecting. In
particular, even if the client may not support beacon protection, the access point will still
send this beacon key to the client. 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.
Now the interesting thing about this construction is that an adversary cannot manipulate the
handshake that transports the beacon key. This means that downgrade attacks are prevented because
an adversary cannot somehow remove the beacon key that is being transported to a client.
The final important thing to discuss is how that clients handle beacons that are received before
they have connected to a network. 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. So how can
we handle this in practice? 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. 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. And in case this check fails, it means there was an attack and then the client
can disconnect from the network. 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. Now that we have our defense, an interesting question is how a client should
act when it receives a forged beacon. And we decided that in that case the client should
send a notification to the access point. This allows the access point to detect rogue IPs that
are far away. For example, in our illustration here, the rogue IP is out of range of the real IP.
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. So now I want to discuss
some practical impact of our research. First and foremost, we created our specification of our
defense in collaboration with Intel, Broadcom, Qualcomm, and Huawei. And our defense is now part of the
draft IEEE 802.11 standard, meaning vendors will likely adopt this in practice as well. 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. 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.
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. If we now connect to this network, the client will indeed receive the beacon protection
key and it will enable beacon protection. As a result, if we now inject a beacon as an adversary,
the client will detect this spoofed beacon. 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. 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. It is independently being implemented by Linux, and it might become
part of an update to WPA3. Thank you for your attention.