34c3 intro
Herald: I'm really happy to be able to
introduce our next speaker. Mathy is a
postdoc in Network Security and Applied
Crypto. He took part in discovering and
implementing quite some attacks in this
field and especially in the wireless
sector. And today he will show us, that all
our Wi-Fi devices are vulnerable.
Especially the ones with Linux and
Android. So, I don't want to go into the
technical details, because he would do
this and I think if you're interested in
even learning more about it, he even linked
the research paper as well as the scripts
and a website for this attack in the
Fahrplan. So for now, give a big round of
applause for Mathy Vanhoef!
applause
Mathy Vanhoef: Ok, thank you for the
introduction and thank you all for
attending the talk, even though it's
already a bit late in the evening. Thank
you CCC for allowing me to speak here. So
today I'm going to talk about my research
on WPA2 and you probably have already
heard about this under the name of KRACK
attacks. Now, the history of this research
is quite interesting, because during my PhD,
I was already researching the security of
wireless networks and during my PhD
defense last year, when I was finishing up
on writing my thesis, one of the jury
members in my PhD asked: "Hey, you're
recommending WPA2 with AES in your thesis,
but are you sure that's really a secure
solution?" And last year my answer was:
"Yeah, I mean it seems secure. It has been
around for more than a decade and if we
ignore some brute-force attacks against
the password, if you select a secure
password, then there are no real weaknesses
that are known. On top of that, there are
also mathematical proofs that state that
if you have the 4-way handshake on the
encryption algorithm, that it's supposed to
be secure. Unfortunately, a year later I
was staring at some OpenBSD code. In
particular, I was looking at this function
called ic_set_key. The details aren't
important here yet, but this key installs
the encryption key for use by the driver,
so frames get encrypted and I was
wondering, what
would happen if this function is called
twice. And I was thinking, like, will it
reinstall the key and what will happen
when you reinstall the key? And it turns
out that answering this question led to
the attack I found and as you know by now,
this uncovered the flaw in WPA2. So in a
sense, this talk is all about how I gave
the wrong answer during my PhD defense. To
explain the attack, I will illustrate it
against the 4-way handshake. After that I
will discuss the impact of the attack in
practice, then I will go over some
common misconceptions that have been
floating around the internet and finally I
will discuss some lessons that we can
learn from this
research and from our findings. Let's get
started with explaining the attack against
the 4-way handshake and the first
question I have to answer here is: what
exactly is this 4-way handshake? And the
4-way handshake is executed whenever
you connect to a protected Wi-Fi network.
It's used when you connect to your home
Wi-Fi network where you just have a pre-
shared password, but it's also used in
enterprise network-networks where you for
example have a username and a password to
log in.
The purpose of this handshake is to verify
that you possess the correct credentials
in order to connect to the network and at
the same time, this 4-way handshake
negotiates a fresh session key that will
be used to encrypt data frames.
This session key is called the PTK, the
pairwise temporal key. And as I mentioned,
this handshake seemed to be really secure
because for over a decade, no attacks have
been found against it, assuming that a
secure password is being used, and on top
of that, the 4-way handshake was
formally proven to be secure and the
encryption algorithm that is used after
the 4-way handshake, which generally
is AES CCMP, that was also formally
proven to be secure.
Yet somehow we did find an attack even
though we have all these formal proofs,
even though this protocol has been around
for that long. So what went
wrong?
To explain this, I'm going to explain how
the 4-way handshake works, using this
specific example. So let's say, we have the
client on the right here that wants to
connect to the access point on the left.
Now, in order to start the 4-way
handshake, there first needs to be some
preshared secrets between the client on
the access point and if you have a network
at home, this preshared secret is basically
the password of the network. But if you
have an enterprise or a more professional
network, then - where you for example have
to log in using a username and a password -
then first 802.1x authentication algorithm
is executed, which in practice is commonly
some form of RADIUS authentication.
The details of that are not important.
What's important here is the result.
Namely, after this authentication phase
there is a shared secret between the
client and the access point.
And once we have this shared secret, we
can execute the 4-way handshake. What
the first two messages in the 4-way
handshake do, is they transport a random
number between both devices.
So in particular, the access point will
generate a random number called the access
point nonce, the ANonce, and it will
transport that to the client.
Then in reaction to that, the client will
generate its own random number called the
supplicant nonce - and supplicant is
basically a synonym for client - and it
will send that random number, the SNonce,
to the access point in the second message
of the handshake. Once both devices have
each other's random number, then we can
derive this unique per session key.
How that key is derived, is fairly simple: we
take the preshared key, that is known
between these two devices, we combine that
with both of these random numbers and the
result is the PTK, this fresh encryption
key, that will later be used to encrypt
data frames.
Now, I want to clarify one thing, and you
might have heard about this research under
the name 'key reinstallation attacks:
forcing nonce reuse in WPA2'.
I want to highlight here that the nonce
reuse does not refer to the nonce reuse
about the ANonce or SNonce during the
4-way handshake. So here we're going [to]
assume, that these ANonce and SNonce, that
they are random and not predictable. The
nonce reuse refers to nonce reuse that
will happen during the encryption
algorithm, which I will explain in a bit.
That's it for the first stage of the 4-way
handshake. The second stage of the 4-way
handshake, a bit simplified, it basically
confirms that both parties negotiate at
the same PTK, the same encryption key. And
in particular, the access point will send
Message 3 to the client. The client will
verify the authenticity of that frame and
if everything looks ok, the client will
reply using Msg4 to the access point.
Once these four messages have been
exchanged, both the client on the access
point will install the PTK for use by the
driver, so now data frames can be exchanged
and these data frames will be encrypted.
Ok, so now we covered the 4-way
handshake, we know the highlight of how it
works. Now the final thing I need to
explain, before we can get to the details
of the attack, is: How does encryption work
in a Wi-Fi network? And to explain this,
let's take the example here, where we want
to send some plain text data from, e.g.,
from the client to the access
point. Then the first thing that will
happen, is that we will take the PTK and
the fresh session key, that the 4-way
handshake just negotiated and we will
combine that with a packet number. And here,
this packet number is called a nonce.
The packet number is incremented by 1 for
every frame, that is transmitted and the ID
here is, that by combining the session key
with the packet number we get a unique per
packet key for every packet that we want
to transmit.
The way the encryption now works is fairly
simple, we feed this per packet key as
input to a stream cipher. We get us output
some key stream, we simply XOR that key
stream with the plaintext and the result
is the encrypted data, the ciphertext.
Now we prepense a plaintext header with
some metadata and also the packet number,
the nonce value, that we used, so the
receiver will be able to decrypt the
packet. Essentially, this is just a stream
cipher, where a nonce is used to always
derive a unique per packet key. Now there's
one essential requirements in this
encryption key.
That is, that under a particular session
key, a nonce value should only be used once,
because if you ever reuse a nonce value,
you will generate the same per packet key.
You will generate the same key stream and
this will allow you to decrypt packets,
that are sent and depending on the
specific stream cipher that is being used,
it will also allow you to forge frames.
clears his throat
Now the question here is: Is this nonce
value indeed only used once? And we already
know, that it is incremented by one for
every packet that is transmitted, so the
only question that remains is: To what
value is this packet number initialized?
And the answer is quite simple: when the
PTK is installed, this transmit nonce is
initialized to 0.
At first sight, this makes a lot of sense.
I mean, you initiate that number to 0,
you increment it by one for every packet,
so surely this nonce is a specific nonce
value, is only used once.
Unfortunately, this is not the case. And the
reason this nonce value or a particular
nonce value is sometimes used more than
once, is because we can force
reinstallations of the PTK and those
reinstallations will again reset the nonce
to 0 and then nonce value will be reused.
So, how can we force these key
reinstallations as an attacker?
Let's again take the example where we have
a client on the left, that wants to connect
to the access point on the right and in
this case, we also have an attacker that
sits in the middle and this attacker will
assume a so-called channel-based man-in-
the-middle position and in this-man-in-the-
middle position, the adversary isn't yet
able to decrypt any packets. This man-in-
the-middle position is purely there, so we
can reliably block packets from arriving
and we can reorder the packet and so on. We
are not breaking encryption yet. And the
way we obtain this man-in-the-middle
position is, we simply take all the frames
that the access point which, e.g.,
is on Channel 6, we take all the frames
that it is broadcasting and as an attacker,
we capture them and we rebroadcast them, we
retransmit them on a different channel,
e.g. Channel 1. So we are effectively
cloning the real access point on a rogue
channel and then we force the victim into
connecting to this rogue access point on
this different channel.
So let's assume now that the attacker
obtains this position, this man-in-the-
middle position and the first stage of the
4-way handshake, we don't modify any
frames at all. So e.g. if the
client is using 802.1x authentication, we
simply forward all the frames between
these two different channels and we do the
same thing with the first three messages
of the 4-way handshake, we simply
forward them unmodified. Where the attack
starts, is if the client sends Msg4
of the 4-way handshake. Instead of
forwarding this message to the access
point, we don't forward it, which in our
situation is equivalent to blocking the
message from arriving at the access point.
Now what's interesting in this situation,
is that from the perspective of the client,
the handshake now successfully completed.
After all, it received Msg3, it
replied using Msg4 and it thinks that
the handshake is done, meaning it now
installs the encryption key and installs
the PTK for use. So, let's make some space
here - the client thinks, that the handshake
was completed, it has installed the key,
but the access point hasn't received
Msg4 yet and the access point will
try to recover from this situation and it
will do that by retransmitting a new
Msg3. And as the - as we, as the
attacker, will forward this message to the
client, the client will accept this
retransmitted Msg3 and then the Wi-Fi
standard says, that if you receive a
retransmitted Msg3, you will reply
using a new Msg4. After that you will
also install the encryption key again. Now,
one remark that I want to make here, is
that, when we receive the retransmitted
Msg3, we reply using a new Msg4,
however, this Msg4 will be already
encrypted at the link layer and the reason
it's already encrypted, is because these
handshake messages are normal data frames
and well, we already installed the
encryption key to encrypt data frames. So
nearly all implementations we tested, will
send Msg4, the retransmitted Msg4,
in an encrypted fashion. Now, I want to
remark here, that the Wi-Fi standard
actually demands that Msg4, if it is
retransmitted, should be sent in plain text,
so according to the specification, this
shouldn't happen. But nearly all
implementations we tested, sent a
retransmitted Msg3 using encryption,
and we will abuse this observation later.
So as I mentioned, after the client
receives a retransmitted Msg3, it'll
reply using Msg4, it will again
install the encryption key, and as a
result of that, this transmit nonce will be
reset, which means, that if the client now
sends another data frame, it will again
use this nonce value of 1 to encrypt the
frame, meaning we have nonce reuse, and we
have key stream reuse, meaning we can now
try to abuse this to decrypt the data
frame.
Now, how are we precisely going to abuse
this, because we do somehow need to
recover the key stream that was used? And
we go back to our observation, that we have
a Msg4 here, that is initially sent in
plain text, and a retransmission of
Msg4 is later sent in an encrypted
fashion. Now, there is a small difference
between these two messages, but
essentially we have a message sent in
plaintext, and we have a message sent
encrypted, and all we need to do, is we
need to XOR these two messages and we have
the key stream corresponding to the nonce
value of 1.
This data frame here at the bottom, it
also uses nonce value of 1, meaning it
uses the exact same key stream, so we XOR
this packet with the key stream and there
you go: We decrypted the packets and we
have now defeated WPA2. So...
Applause
Thank you. So, that describes the attack
against the 4-way handshake. And the
4-way handshake is not the only Wi-Fi
handshake that is vulnerable. There are
also other handshakes which can be
attacked in a similar manner, but I'm not
going to explain all of them in detail. If
you want all the nitty-gritty details, I'm
going to refer you to our academic paper.
Here, I'm just going to discuss more the
high-level concepts and the ideas behind
the attack. So, e.g., one handshake
that is also vulnerable, is the group key
handshake, and that handshake is used to
transport the group key from the access
point to the client. And that key is used
to encrypt broadcast and multicast
traffic. Then we also have the FT
handshake. The FT handshake is used, when
you roam from one access point to another
access point of the same Wi-Fi network.
It's used so you can quickly switch
from one access point to another without
a long timeout. And finally, another
handshake that's also vulnerable is the
PeerKey handshake, and that's used when
two clients want to communicate directly
with one another. Okay, so I'm now going
to discuss in a bit more detail, what the
practical impact of our attacks are. And
I'm first going to start with the general
impact that a key reinstallation attack
has. So, let's assume we have a device
that's vulnerable. This device can either
be a client device, e.g. it can be
a smartphone, or a laptop, or these days
it can even be a toaster. They have Wi-Fi
as well. Or it can also be an access
point. So if a client or access point is
vulnerable to our key reinstallation
attack, the first thing that generally
always happens, if this device ever sends
encrypted data frames, we can force it to
reuse the nonce, which in turn we can use
to decrypt frames. But that's not the only
thing we can do when a device is vulnerable.
Another thing we can do, is we can replay
encrypted frames sent towards this device.
Now, why is that the case? That's because
if a key is reinstalled, not only is this
transmit nonce reset to 0, but another
parameter, which is called the replay
counter, it is also reset to 0. And this
replay counter, as the name implies,
it's used to detect retransmissions, or
it's used to detect malicious replays. If
this counter is reset, we can also replay
frames towards a vulnerable device. So,
that's the general impact of a key
reinstallation attack, but there are a lot
of other factors which also influence the
exact impact of the attack, and one of the
things that probably has the biggest
influence, is the encryptions cipher that
is being used. So, e.g., these days
it is quite common that Wi-Fi networks use
AES CCMP. It's the most widely used
encryption algorithm in Wi-Fi networks.
Against this algorithm, the impact in a
sense stays limited to only decrypting and
replaying frames. It's not possible to
abuse our key reinstallation attack to now
forge frames. And really, we got lucky
here, because this is the most widely used
cipher, and against this cipher we cannot
start to forge frames. Because, if we
would have been using the older encryption
algorithm, which is WPA TKIP, against that
algorithm, we would be able to recover the
Message Integrity Check key, which is
basically just a fancy word for the
authentication key. And once we have that
authentication key, we would be able to
forge frames that appear to be sent by the
device under attack. Interestingly, lately
there's also been a new encryption
algorithm that is being introduced, and
that algorithm is
called GCMP. It's fairly new, so only a
few devices currently support it, and
currently it is being rolled out under the
name of WiGig. Against this algorithm, the
impact of a key reinstallation attack is
really the worst, because here we can
again recover the authentication key, but
when we use GCMP, the same authentication
key is used in both communication
directions. So against GCMP, we would be
able to forge frames that are sent from
the client to the access point and also
forge frames that appear to be sent
from the access point to the client, while
for the WPA-TKIP algorithm, we would only
be able to forge frames, that appear to be
sent by the device that is under attack.
So, my opinion - this is a bit surprising,
because GCMP is the latest encryption
algorithm that is defined in the Wi-Fi
standard, yet the impact against it would
be the highest. So, this is also why I
think we got lucky here, because if we
would have found the attack, say maybe
five or ten years later, and everyone
would be using this algorithm, the impact
would have been a lot worse. Another thing
that influences the impact of the attack
is, which specific handshake we are
attacking. For example, if we attack the
group key handshake, then the only thing
we can do is, we can
only replay, broadcast or
multicast frames. Now, why is that the
case? Why can't we decrypt broadcast or
multicast frames, if a key reinstallation
occurs? And the reason is, that if we
attack the group key handshake, we are
attacking the client, and the client is
never sending actual encrypted broadcast
frames, so will never reuse the transmit
nonce when it encrypts frames, because
it's never encrypting frames. Now, why is
it, that the client never sends real
encrypted broadcast frames? Well, the
reason is quite simple. Let's say, we have
the network layout shown here and the
client on the left wants to send a
broadcast frames to all the other clients.
Now, what happens here, is that this client
will send the data frame it wants to
broadcast as a Unicast frame to the access
point only, meaning it won't encrypt it
yet under the group key. It's the access
points that will broadcast this frame to
all connected clients, and only the access
point will then encrypt it using the group
key, and this is to assure that all
clients
within range of the access point will
receive this broadcast message. Now, for
us, this means that only the access point
is transmitting real encrypted broadcast
frames, and in the group key handshake we
cannot attack the access point. We are
only attacking the client, meaning in
practice, we can only replay broadcast
frames to the client, at least if we are
targeting the group key handshake. So,
really, the impact is limited in practice
if we attack this handshake, because
generally, replaying broadcast data doesn't
have a high impact. Though, I do want to
note, that some home automation systems use
broadcast traffic to, e.g., send
commands to turn the device on or off,
e.g. to turn your fridge on, or to turn
lights on or off, so although the
impact of replaying broadcast frame is
low, there are situations in practice,
where it does have some impact, but it
really depends on your network setup and
the devices that you use. So, the other
handshake that is vulnerable, is the 4-
way handshake, but we already discussed
that. Against a 4-way handshake we can
attack the clients and the impact, is that
we can replay and decrypt frames, and
depending on the encryption algorithm
being used, we can possibly forge frames
as well. The situation is a lot more
interesting for the FT handshake, though.
And remember, this handshake is used, when
you roam from one access point to another
of the same network. Against the FT
handshake, it's not the clients that we
can attack, but here we can attack the
access point. And on top of that, when
attacking the FT handshake, we no longer
need this man-in-the-middle position. Now,
why is that the case? Well, let's again
explain this using our common example,
where a client wants to connect and where
it is executing the FT handshake. And at a
high level, the FT handshake is the same
as the 4-way handshake, meaning you
also have four frames that are
transmitted, but the big difference here
is, that with the FT handshake it's the
client that sends the first message
in the handshake, while for the 4-way
handshake it was the access point that
sends the first message. So, the handshake
is practically the same as the 4-way
handshake, meaning, initially we have two
messages that transport these random
numbers, these nonces, between both
devices. Then, both these endpoints can
generate the fresh encryption key. Then
the last two frames, they are again used
to confirm that both parties negotiated
the same encryption key. Now, I want to go
in a bit more detail here on this last
phase, and what happens here, is that the
third frame of the handshake is now sent
from the client to the access point and
that is a reassociation request. And after
the access point receives this frame, it
will reply using a reassociation response
frame and it will install the encryption
key. Once it has installed the encryption
key, it can of course start sending
encrypted data frames. So, let's again
make some room here. What we can now do
as an attacker, is we can take this
reassociation request that the client
previously transmitted, and we can simply
replay it. That's because in the FT
handshake, there is no replay protection
against messages of the handshake. So we
can just take that frame, we can send it
again to the access point. The access
point will receive it, it will accept it,
and it will reply using a reassociation
response. Now, so far this is not a
problem. The problem here is, that again
the access point will reinstall the
encryption key, and here it goes wrong
because we are reinstalling this
encryption key. The transmit nonce is
again reset to 0, meaning if we now send
the data frame again, the nonce value of 1
is used to encrypt these data frames,
meaning the same key stream is used,
meaning we can start applying the same
tricks to first derive some known key
stream and to then abuse that to attack
the handshake. So, I want to highlight
here a few things. And the first is, the
reason why we don't need a man-in-the-
middle position, is because handshake
messages in
the FT handshake, they are not protected
against replays, while in the 4-way
handshake, every handshake messages
contains a sequence counter, where the
receiver uses the sequence counter to
detect replays, but for the FT handshake
that's not the case, so we can just take
these messages, we can replay them, and we
don't need a man-in-the-middle position to
block packets and to trigger
retransmissions. Ok, so that's the
explanation for the FT handshake. Another
factor that can influence the impacts of
our attack in practice, is which operating
system and which device precisely we are
attacking. And in particular, we see that
iOS and Windows, they are not vulnerable
against attacks against a 4-way
handshake. And why is that the case? Well,
that's because these two devices don't
really follow the standard, and they don't
accept retransmissions of Msg3,
meaning we cannot abuse these
retransmissions of Msg3 to trigger
these key reinstallations.
Now, I want to make two remarks
here. And the first one is, that
against these devices we can still attack
the group key handshake. And particularly
when looking at iOS, if we look at iOS
version 11, it does implement the standard
properly and it does accept
retransmissions of Msg3, meaning that
one is vulnerable to attacks against the
4-way handshake. Now, Linux is not much
better, because if we look at the Wi-Fi client
that is used on Linux, and for example on
Android, it's called wpa_supplicant, and
against wpa_supplicant 2.4 and higher, we
notice that, if we try to perform a key
reinstallation attack, it won't reinstall
the secret key that was negotiated, but
no, instead it will suddenly install an
all-zero encryption key, and then it of
course becomes very trivial to start
decrypting data that this device is
transmitting. Now, why does this happen?
I can actually sort of understand why this
went wrong. So, I'm going to explain what
the implementation does wrong, to... why it
installs this all-zero key. And to explain
this, I'm going to assume that we have an
Android device that is connecting to an
access point. And we're going to zoom in a
bit on the implementation of the Android.
And we're going to look at two entities.
We're first going to look at wpa_supplicant,
which is represented by the
handshake icon here, and we're also going
to look at another entity, namely the
Linux kernel. It's the Linux kernel that
will be responsible for encrypting data
frames, and wpa_ supplicant will be
responsible for executing the 4-way handshake.
And of course we assume, that we as an
attacker are nearby, and we again have
this man-in-the-middle position. So, what
does an attacker have to do to cause this
installation of an all-zero encryption
key? Well, again, we simply let the first
phase of the 4-way handshake execute
normally, and when the access point sends
Msg3 of the 4-way handshake, we
forward that to the Android. Android will
reply using Msg4. And we will
again block Msg4 from arriving at the
access point.
Now, completely similar to the case with
the 4-way handshake, the client thinks that
the handshake now successfully completed,
meaning it will install the encryption
key. How it will install the encryption
key is as follows: It commands the Linux
kernel into installing the encryption key
in the driver. And the driver itself will
make a copy of the encryption key. And it
will store it locally. And the driver can
then encrypt frames. Now this means that
wpa_supplicant, which is just a user land
program, no longer needs to store the
encryption key, meaning it will clear it
from memory. What will happen now, if we
continue with the attack, is that the
access point will retransmit Msg3,
because it did not receive Msg4. The
client will again happily accept this
retransmitted Msg3 and reply using
Msg4. And again it will instruct the
Linux kernel saying "Hey, please install
this encryption key that is located at
this address in the memory." But of
course, that memory is now all zeros,
because that key has just been cleared
from memory. So,
now it's basically commanding the Linux
kernel into installing an all-zero
encryption key. And the Linux kernel and
driver will happily obey this command and
they will install an all-zero encryption
key, meaning at this point, all the data
that the client is sending, is encrypted
using a known key, so we can easily
decrypt all the traffic, and of course we
can also send any traffic we want to the
client. Basically, we are now a rogue
access point and we can manipulate the
traffic of the client as we wish.
Applause
MV: Thank you. So, after this you might be
wondering, "Well, gee, is my device
vulnerable?" And you can test your own
device using the following script. It's on
github. I have tested the script on Kali
Linux, on Arch Linux, and also on Ubuntu,
so I could recommend using one of these
distributions, and I also recommend to use
a Wi-Fi dongle that we or someone else has
tested ourselves, because we noticed that
if you use our testing scripts with some
older
Wi-Fi devices, then there are some bugs in
these Wi-Fi devices which cause our
scripts to fail. And one way to also
prevent our scripts to fail, is to disable
hardware encryption. Now, how you should do
that is also explained on this page. Using
these scripts, you can test both your
client devices, you can test against
attacks against the 4-way handshake,
the group key handshake, and there's also
a script to test the access point, whether
it's vulnerable against attacks against
the FT handshake. Now, if you're going to
try to see which devices are vulnerable,
you are most likely going to see that
quite some clients are still vulnerable to
our attacks. Luckily, we can modify the
access point to prevent attacks against
the client. In particular, we can make
additional modifications to the access
point, such that the access points never
retransmits Msg3 of the 4-way
handshake, and that it also never
retransmits the first message of the group
key handshake. And if we do that, then
clients that are connected to such a
modified access points, they are no longer
vulnerable against most attacks. There are
still some edge cases where the device is
vulnerable, but these have a very low
impact. So, if we modify an access point
in this way, then connected clients are no
longer vulnerable. One downside here is,
that because we are no longer
retransmitting certain messages, it could
be that especially in a noisy environment,
because we don't retransmit these messages
anymore, that the handshake may fail
because the reliability is now less. Now,
one thing I also want to remark here,
that... if you have a router, which is
vulnerable against our attack and a
vendor says "Hey, we patched our router,
so we patched our access point to defend
against attacks," then this does not mean
that this access point implements these
countermeasures. Because these
countermeasures, they are additional
modifications on top of the normal
patches to defend against the attack. So,
only if a vendor explicitly says that "Our
patches of the access point also prevent
attacks against clients," then, only if
they explicitly say that, are attacks
against the client also prevented. Ok,
so now I want to cover some misconceptions
that have been floating around the
internet. And the first one is, that some
people claim, if you only patch the
clients, or if you only patch the access
point, then you're fine. But that's not
the case. Because if you only patch the
client and the access point is vulnerable,
then we can still attack the access point.
If the access point only contains these
normal patches, the normal patches to
defend against attacks, then connected
clients are also still vulnerable. So, as
I mentioned, connected clients are only
defended, if the access point contains
really extra modifications on top of the
default patches. Now, another common
misconception is, that some people might
say "But, yeah, it's a cool attack, but
you have to be close to the network in
order to pull off these attacks."
Unfortunately, that's not the case because
we can use special antenna. And this
special antenna, they can be made
really cheap out of, e.g. just a
tin can, and with this special antenna, we
can manipulate Wi-Fi traffic from up to,
say, 2 miles. And there are even leaked
NSA documents, where the NSA is able to
exploit a Wi-Fi network using other
attacks from up to 8 miles away. Now,
that's of course with a clear line of
sight, but still this shows that you don't
have to be physically close to the
network. You can still be relatively far
away. Another strange remark that I
sometimes hear, is that you need to be
connected to the network in order to pull
off these attacks, which would basically
mean, you need to know the password of the
network to carry out the attacks. But
that's not the case. As I mentioned,
during the attacks, you only need to be
close enough. You need to be able to
manipulate some encrypted packets. But you
don't need to know anything about the
network. You simply need to know the
network is there and there's a vulnerable
client and access point and then you can
start attacking them. One remark that I
can understand, is that some people
say that "Yeah, Ok, you can attack these
handshakes, and you can decrypt data that
is sent right after these handshakes, but
generally right after you connect to an
Wi-Fi network, you're not really sending
interesting data, because at that point
your device is sending e.g. ARP
requests, or it's sending DHCP requests,
or is just creating TCP connections. But
no useful information is transmitted at
this time." Unfortunately, at least for a
defender, this is again not true. Because,
what we can do as an attacker is, we can
first let the client connect blackout out
manipulating any traffic. The client, the
victim, will then, e.g. start
browsing the internet, start
opening TCP connections, and in the middle
of that, while the victim is e.g.
surfing the internet, we can
deauthenticate the client from the
network, and all operating system will
then immediately execute a new 4-way
handshake. And once that 4-way
handshake is then completed, it will
send all the buffered TCP packets again
to the access point and also in a reverse
direction. So, basically, what we as an
attacker can do, we can wait until we
expect the victim to send interesting
information. Then we deauthenticate the
victim. It will execute a new handshake.
And then we can decrypt the data that will
be transmitted right after that handshake.
Another thing that makes the attack
possibly hard, is that obtaining this
channel based man-in-the-middle is
difficult. For example, you might be
thinking that in order to force the
clients to connect to the rogue access
point, you need a stronger signal strength
than a real access point. But again,
that's not the case. And the reason this
is not the case, is because we can use
special Wi-Fi packets and so-called
channel switch announcements, which
command the client into switching to a
different Wi-Fi channel, and effectively
blackout to a rogue access point. So we don't
need a high signal strength, we can simply
command a victim into saying "Hey, switch
to this channel and connect to our access
point." And these frames are not
authenticated, so we can just forge them
as an attacker. Another thing you might
say, that the complexity of the attack is
hard, meaning it requires some expertise
to implement this. And this is true. You
do need to know a bit about Wi-Fi in order
to make a proof of concept reliable, but
as usual you only need to write this
attack once, and then people can use your
script in order to attack others. And this
is similar to, e.g., memory
corruption attacks, such as buffer
overflows or stack overflows. Writing the
proof of concept may be hard, but if you
then give it to someone else, or if you
put it in Metasploit or some other tool,
all the user has to do, is basically start
the script, and you can start attacking
people. One other misconception that I
sometimes encounter, is that people say "If
you use AES-CCMP, this mitigates the
attack." Again, unfortunately, this is not
true, because the only advantage of using
AES-CCMP is that
the attacker can no longer forge frames.
The attacker is still able to decrypt and
replay frames. And finally, the last
misconception is, that some people say that
enterprise networks aren't vulnerable,
because they e.g. don't execute
the 4-way handshake. But again,
unfortunately, that's wrong, because even
these networks use the 4-way handshake
and they can be attacked as well. So, then
you have some people that say "OK, WPA2 is
now completely broken. It's the end of the
world and we're all doomed." Let's not get
carried away, though. We can patch these
vulnerabilities in a backwards compatible
way. And as I illustrated here in my talk,
the impact also really depends on the
devices that you are using and your own
network setup. So, sometimes the impact is
actually really low, but of course
sometimes the impact can be very high,
e.g. if you have a Linux device, then
attacker can do what he or she wishes,
essentially. Now, for the last part of the
talk, I'm going to discuss some lessons
that we can learn from this attack and
also the research. I think one of the most
important and interesting observations -
it's also the reason why I really like
this attack myself - is that the 4-way
handshake was proven to be secure. The
encryption protocol, and in particular
AES, has also been proven as secure.
However, if we combine these two things,
then suddenly we lose all security. And
this is quite unfortunate. And what this
teaches us, is that even though individual
parts of a system were really investigated
and perhaps formally analyzed, we also
need to analyze the combination of these
different entities and models, and we also
need to prove that these combinations are
secure as well. And another way to look at
this, is that in the proof of the 4-way
handshake, the authors, they modeled the
handshake in a rather abstract way. And
their proofs, specifically, they did not
model retransmissions of handshake
messages. And that's one of the things we
abuse. So, on one hand we need to assure
that we also look
at the combinations of these different
entities, but we also need to assure that
the abstract models that we use reflect
reality. Another thing that we can learn,
is that we should keep the protocols and
also the implementations simple.
E.g., if we look at wpa_supplicant 2.6,
when we were studying this version
ourself, we thought it wasn't vulnerable
to key reinstallation attacks. However,
when we were notifying companies of the
vulnerabilities, another researcher found
an attack against this version which did
work. The reason we missed this attack
against version 2.6, is because
wpa_supplicant uses a fairly complex
implementation of the 4-way handshake
and the state machine is fairly complex to
reason about. And there are two ways to
combat this. The first is to keep the
protocol simple. The second way to combat
this, is to formally verify
implementations. Now of course, we cannot
formally verify all the code, but what we
can do is, really, these cryptographic
protocols which play a very important
role, at least we should pay enough
attention to that. What's also
interesting, is that I encountered a
document of the CIA which also agrees, that
complex implementations or protocols are
bad. Specifically, they have a document,
where the CIA advises people how to
properly implement backdoors, essentially,
and they're saying that "Yeah, if you want
to send data back to us, of course, use
encryption, but in that encryption
algorithm, don't enable re-key
functionality, because that enables
additional features of the encryption
algorithm. And these additional features,
they cause unnecessary complexity and that
generally leads to bugs." Another thing
that we can learn, is that the standard
needs to be specified rigorously and as
precisely as possible. Because the
original WPA2 standard, it was a bit fake.
It didn't really define a state machine.
Well, the state machine that it defined
says, what an implementation - sorry -
should do if it receives a message, but -
let's go back to the slides - but it
doesn't define what an implementation
should do when it receives an unexpected
message. So, it doesn't define the order,
in which messages should be accepted. Now,
there is an amendment of the Wi-Fi
standard which better defines how and when
to handle messages, but even that standard
is a bit fake. And I want to remark here
that because the original WPA2 standard
was a bit fake, I can forgive iOS and
Windows for deviating a bit from the
standard. Because the standard was
difficult to interpret correctly. Now, on
a bit of a related note, I want to briefly
mention a workshop that we are organizing,
which is exactly about how to implement
these security protocols properly, how to
e.g. fuzz security protocols, how
to prove that they are correct, how to
make sure that we specify them rigorously.
So, if you are working in this field, do
consider submitting to this. Now, the last
thing that I want to mention on what we
can learn from this research, is how we
can coordinate the disclosure of a
vulnerability like this. Because this is
not an ordinary vulnerability,
that is, just affects one
vendor, it really affects possibly every
Wi-Fi device that is around. So, how on
earth are you going to start notifying
companies? Who are you going to notify?
What would be the deadlines, and so on?
Well, I'm going to discuss a bit about the
strategy that we used, and what we used
first is... we first wanted to determine,
you know, is this really a widespread
issue? We wanted to be sure of that before
we started to notify a lot of companies.
And the way we tackled that problem is, we
first contacted a few selected vendors and
we told them that "Hey, we possibly found
this flaw in the WPA2 protocol, but we
weren't able to test your devices, but you
should check this out." And quite quickly
we got a few responses from vendors, saying
that "Yes, we looked at your attack and
indeed, some of our devices are
vulnerable," and this really confirmed to
us, that a device
that we didn't test ourself was
vulnerable to the attack that we found.
So, it confirmed that the issue is
widespread, and we also got a bit of
feedback on the report that we sent
towards them on the description of our
attack. So, at this point we were
convinced ourselves, that this really was a
flaw in the standard and that a lot of
companies will be affected. Then the next
question we had is, "Okay, who are we now
all going to notify?" We of course
notified the big names and the big
companies, but who else do we have to
notify? And at this point, our tactic was
to rely on a CERT team, specifically a
CERT from the US and they did all the
coordination for us.
But one other thing that you can do is,
that if you're not sure who all is
affected or what, who all the vendors are,
then you can just ask a vendor that you
contacted already for other
vendors, that also might be affected
by the bug that you found, e.g.
Now one thing that is more difficult here,
is that on one hand you want to notify as
much vendors as possibly, on the other hand
you also can't notify everyone because if
you are going to notify everyone, then the
chance of the details leaking, they become
close to one. Another difficult thing to
decide is, how long should you give time to
companies in order to patch this. And again,
here you're mixed between two decisions:
on one hand you can give give them a long
period to patch everything, but then again,
the risk of this details leasing... err,
leaking increase. On the other hand, if the
embargo period is too short, people won't
have time to patch it. So this is quite a
hard decision. In the end,
what we did is - and which I would
again do in the future - is, it's hard to
pick a deadline, but still do pick a
deadline to avoid any uncertainty and so
that people know, what to expect. And
finally, I want to thank CERT and ICASI
for helping with the coordination and you
also want to thank Cisco for some of the
advice that they give.
So, with that I can conclude the talk, so
what we discussed, is a flaw and the WPA2
standard itself and the most surprising
thing about this research is, that WPA2 was
proven to be correct, yet we still found
his attack after more than a decade.
And more than that, not only is this just a
theoretical attack, the attack has actual
impact and practice.
And finally, in order to defend against
this, you should update all your clients
and also check if your access points are
affected. So with that, thank you for your
attention and if there are any questions,
feel free to ask.
applause
Herald: So, do we have any questions?
There is mics everywhere, so please come
in front. And I think, we already have the
first question directly here in front on
mic number 1.
Mic1: You mentioned, that GCMP is most
vulnerable. Do you know if there's any
standardization going on, about switching
to nonce misuse resistant scheme like
AES-GCM, Synthetic Initialization Vector?
MV: Yes, so there have been
some proposals in order to make the
encryption algorithm defend against nonce
reuse. Now the impression I have, that this
is still a bit of ongoing research. So
there are proposals, where you have an
algorithm that you can use, but I'm not
aware of actual encryption protocols, e.g.
TLS or Wi-Fi, that are using them.
But they exist, but I... they're not yet being
really used.
Mic1: It is standardisation going on in
CFRG, so Crypto Forum Research Group in
IETF standardization, but I was asking about
Wi-Fi standardization, if they are planning
to use this? And [a] related question would be,
if you would use in AES-GCM instead of
the deterministic initialization vector,
there's a random IV possible, if you use
96 bit, then the impact wouldn't be
bounded.
MV: So to answer the first question: I'm
not aware of the Wi-Fi standard
from really modifying the standard to use
a nonce misuse resistant encryption
cipher. They are modifying the standard to
defend against key reinstallation attacks,
but I think they're not yet going to
incorporate a nonce misuse resistant
encryption cipher, because they still have
the impression that they're going to wait
probably a while and once that technology
is more mature they're going to use that.
If I understood your second question, you
also have encryption algorithms, where you
don't have deterministic nonce, but you
have a nonce, which for every encryption
operation e.g. is random.
Mic1: Actually in the GCM standard there
are two possibilities: one deterministic,
MV: Yeah.
Mic1: and the second random.
MV: So the risk of using a random
initialization vector is, that you may
have a bad random generator,
that it can go wrong there. On that, that
you still have nonce reuse, so even with a
randomly generated nonce it can
also go bad, but then there are different
attacks. And I think, there has been a
paper that analyzes a certain TLS
libraries, where they do find attacks, where
in that case the GCM algorithm can still
be attacked, not through key reinstallation
attacks, but because there is, because
basically the nonce isn't really random,
e.g. sometimes a bad implementation
always uses the same random nonce.
Person X: Um, direct answer...
Herald: Err, sorry,...
X: Direct answer to his question number
one: because he asked, whether there's
right now an approach to modify the
standard towards being resistant against
this attack, right now there is no IEEE
task group working on an amendment which
will fix this.
MV: Well, there is... they are working to
prevent the key reinstallation attack.
X: Well, there is no official
active task group right now.
MV: Okay that could be, but there are still
people working on that.
X: Yeah, they're working on that,
but no
task group, right?
MV: Ok. Thank you.
Herald: Okay thank you.
Here in number 3.
Mic3: Yes, thanks for your
amazing talk.
Just for my personal understanding:
could you briefly go back to
the slide with the 4-way
handshake, like, right in the beginning?
MV: Yup, so the attack or the handshake
itself?
Mic3: Yeah, yeah the attack.
MV: So let's go to this slide.
Mic3: Yeah so all you get from this, is the
keystream that is used to encrypt
the the Msg4, right,
that's all you get?
MV: Yes, but you can already use that to
start decrypting frames and what you can
do as an attacker, you have several options.
The first thing you can do is, you can keep
triggering new handshakes by
deauthenticating the client, so you can
always decrypt one packet at a time.
What you can also do is, you can wait with
sending this retransmitted Msg3
to the clients, because sometimes you know
the encrypted data that is sent. So you
know that a packet is an ARP request, you
know that the HTTP requests. You can capture
quite some packets where you know the
content, to derive some known key stream
and once you have that, you can forward
Msg3 to trigger a key
reinstallation and then you have collected
quite some key stream to be able to
decrypt several packets at a time. So you
can use tactics like that, you can rely on
the packet length to basically determine,
what the type of packet is, where you have
known plaintext and you can use that to
derive new key stream and there are a lot
of ways to play around with that.
Mic3: Yeah but, all you get here is the -
because the key stream that you get is
already being used immediately, because
it's being used to encrypt Msg4.
MV: Well, we know the content of Msg4
and we abuse, that Msg4 is
encrypted to derive known key stream and
we can then use that to encrypt data
frames, which we do not know and... we
should discuss this offline.
Mic3: Yeah.
Herald: Perhaps this is for later
discussion with more in detail. Now we
switch to number two... number four, I
think it is. Yeah, thanks.
Mic4: Yes. Great find really and an
awesome talk. Could you maybe elaborate a
bit on how to still use the advantage of
formal verification in the sense of, let's
say, the flaws that it has, it gives a very
false sense of security in your sense, how
can you still benefit from formal
verification?
MV: Well, I think the attitude we should
adopt is, that formal verification of code
or of algorithms increases the amount of
trust we can put into a program or into a
protocol, but it's not just because it's
formally verified that it's secure.
Perhaps one of the attitudes that people
had was: 'oh it's firmly verified, it must
be fine'. We should abandon that attitude
and instead we should say: "Ok, it's
formally verified but, you know, let's
check if the model they used reflects
reality. Let's see if the proof is correct"
and so on. So, we should still employ a
formal verification but we should just
treat it as additional evidence, that
something looks secure.
Herald: Ok, there's another question on mic 2
Mic2: The first part is on the slide
you're currently on. As far as I
understood it in the talk, the
retransmission of Msg4 is not
supposed to be encrypted by the standard.
MV: Correct.
Mic2: So if you follow the standards, you
shouldn't have a problem here.
MV: No, then you still have a problem,
because what you can then you do, is just
wait for a data packet where you know that
contents of, e.g.it can be an ARP
request, you can derive most fields of
that, it can be a DHCP request, it can be
be a TCP SYN packet, or it can be some
plain text HTML frames. E.g. there
has been work to fingerprint the length of
HTTP requests, to be able to determine
which page you are visiting, so purely
based on the length, we can determine the
contents of the website you are looking
for. We can then derive known plaintext
and basically there are a lot of ways to
predict the content of a frame, to then
derive known keystream and to then trigger
a key reinstallation attack to then abuse this.
Herald: Ok we have time for one last
question. Mic number 1?
Mic1: Um, so as far as I understood your
research, and so we, if we have like 11W
deployed in the network, we are still
vulnerable to the attack, because as 11W
specifies the encryption, I'm supposed by
this amendment, is also done by the
encryption use on the network like before,
so 11W is not really a way to secure
the network?
MV: Well, if I got it right, 11W is, one of
the things it does, is protect the
management's frames, if I'm correct?
Mic1: Yes.
MV: Yes.
MV: So using that does not defend against
these attacks.
Herald: Ok, I think there's still quite
details, where people are curious about,
because it's everybody starting this
question "as far as I understood". So I think,
this was a really nice comprehensive talk
and I want to thank you. And everybody who
has more questions, perhaps can find you
here and ask you more or have a look into
the paper, perhaps read everything in
detail there.
So, please another big round of applause
for Mathy and his amazing talk!
Thank you very much.
MV: Thank you!
applause
34c3 outro
subtitles created by c3subtitles.de
in the year 2018. Join, and help us!