-
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!