Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/661 Thanks!
OK, so our next
speaker for the day has
just finished his PhD
on security of yeah,
I think that deserves a round of applause
on the topic of security of a WPA
atlas and ask for
he's now doing his postdoc and focusing
on wireless security.
So, um, and the next talk,
the title is predicting and abusing WPA
to eight to 11 a group.
Kids, please give a big round of applause
to Matthew Bahnhof.
OK, thank you for the nice introduction.
So I am indeed a multivolume and I'm
going to present predicting on abusing
WPA to ingroup group Kice or
more officially entered into that
11 group.
So first, a quick introduction
to Wi-Fi security.
What was the state of Wi-Fi security
before I did this research?
Well, essentially, Wi-Fi
security has been thoroughly
investigated. There have been a
lot of results.
For example, we know at the very first
security algorithm of Wi-Fi wired
and encrypted privacy,
it was Web.
It was horribly flawed.
You probably all noticed that you can
crack a whip network
within mere minutes.
In fact, if you download the latest tool
suite of earthquake, Anji
aren't there is enough traffic on the
network. You can really
obtain the preset key of the network
within only a few minutes and
sometimes, if you're lucky, even seconds.
So the first
attempt by the L.A.
and Teutul 11 group to introduce a
security protocol, it didn't
really went that well.
We also have other attacks recently
against wireless networks and in
particular against WPA.
To one example,
which is quite recent is that
some vendors or some ISPs,
when they hand out their router,
they initialize it with default
passwords, with a default passphrase
on it. Turns out that these are rather
predictable and particular
this default password, which
should be shown somewhere here on the
back of your router or in the car to
receive what it it was derived from
the Mac address.
So if you want to attack one of these
networks, you simply have to sniff the
network, determine the Mac address, and
from that you could derive the
shared key depreciate key
of the network.
And similar to this, you also have
dictionary attacks against the WPA
to handshake.
So these are all known
attacks. And the way that this dictionary
attack work works is essentially
you can force a client to disconnect
from the network and then it will
reconnect with the network.
And if it reconnects, it, of course
performs a fresh handshake with
the access point to negotiate
session keys.
Now, the bad part about this
handshake is that as an attacker, you can
capture the four messages that are
exchanged in this handshake and
then you can perform offline guessing
attacks at the passwords of
your network.
Now, if the handshake would have been
better designed, this kind of dictionary
attacks would not have been possible.
Unfortunately, the way the handshake was
designed, you can make a capture
of the handshake.
You can process this offline on this
kind of dictionary. Attacks are
unfortunately possible.
Um, I think a few years ago, there
was also a tech which shows that
using a bit of social engineering as
well, you can even attack WPA to
enterprise networks.
And these are networks where you have to
type in your username and password.
So think of Airdrome or your company
network or also
the CCC network.
You also have one of these enterprise
networks as well.
And the idea behind this attack, I'm
not going to go into detail here because
these are known.
But one of the parts that they use is
they broadcast a network with the same
side name as the Target network,
but they include a small space bar behind
the name.
And if you then look at the
network name in your operating
system, you won't notice that the network
is, for example, Airdrome and then a
space bar after it.
So it's essentially a completely new
network. And if you connect to a
completely new network,
it's your operating operating system
won't really complain because
otherwise it would say, OK,
previously you connected to it.
Now it suddenly uses a different cert.
This is bad, but because the space
was after after that, as I said,
your operating system will think, oh,
it's a new network, everything is fine.
But as I mentioned, I'm not going into
detail, just mentioning
it as related to work.
In the sense lately
there have also been a few more
theoretical attacks against WPA
type.
They are similar in spirit to the text
on the Web, except cracking WPT
takeup is much, much more difficult,
even though there are also other
weaknesses. And so
you should not use it.
But you are theoretical attacks that
allow you to recover the session keys as
well, though they are very hard to
execute and practice.
So why am I telling you all this?
Well, if you look at all this previous
research about the security of wireless
networks.
We can see that a lot of this work is
focused on the security of the preset
keys or of the negotiated
session keys, so that has
received a very large amount
of attention from the research community
and also from hackers.
However, the keys that are used to
protect broadcast traffic, so
the group keys, they are not
widely used.
So here is something strange with slight.
For some reason, one slight is
missing, but anyway, so
this group case, they are used to encrypt
broadcast on multicast
traffic and that is in contrast
with session.
So, for example, if you see here
your access, point it as a group
on it also has a session key for every
client that is connected to
the network.
And so what we noticed
is that the security of this
negotiated session is properly
studied, but the security of the group
is not studied. So what I did
during my research is that
I investigated
how these group keys are managed during
their full lifetime.
So what do I mean with the lifetime
of a group?
Well, we have our access point here.
And when you start your access points
or when you start your router, the
first thing that happens is that it
generates a fresh and random
group.
And here we notice that the random number
generator, so the orangy
that is used to generate this group
is flawed.
So the standard suggests
a random number generator as a reference
implementation.
And we will see in practice that certain
vendors also implement a random
number generator. That is predictable
and this will allow us to predict the
group.
So that's essentially the first stage of
the lifetime of the group when it is
generated.
The second part is when a client
connects to the network, when it connects
to the network, it performs this four
way handshake.
It negotiates the session keys.
These are sometimes also called the
Paradise Keys.
And during this handshake, the
group is also transported to
the client because, of course, it
needs to know the group key to be able to
decrypt broadcast on multicast
traffic.
What we found here is that
we can manipulate, manipulate this
handshake as a man in the middle attacker
and we can then use, uh,
we can then force you Shites of
our C4, meaning the
group key, when it is being transmitted
from the access point to the client is
encrypted.
Using our C4 on our C4
is an insecure cipher.
You should not use it on in this context.
We will see that we also currently it's a
theoretical attack, but we do have an
attack against the way our C4 is used
in this situation.
Now, also, one of the more interesting
parts is also let's say that
we now as an attacker have the group.
What can we do with the group?
Because, of course, if we know that key,
we can decrypt broadcast on
multicast frames.
We can inject broadcast on multicast
frames, but can we do even more?
And we're going to show that
using some clever tricks, we
can use the group to inject unicast
IP traffic. So not just broadcast
traffic, but also unicast traffic.
And we will even show how we can
decrypt nearly all Internet
traffic of the network.
And then at the last part of the
presentation, I'm going
to propose a new idea
on how to better generate
random numbers if you have a Wi-Fi
device.
But the main part of the presentation
will be these first three steps
on a particular predicting the
RNC and then using it to
decrypt traffic on Internet traffic.
So before I get to the main content of
the presentation, I'm going to give a
little bit more background on how this
group keys are used.
So let's say we are in the following
situation.
We have our access point here, which
has the group key of the network
and which has the two session keys of
the two connected clients here.
And let's assume that in this situation,
Client A wants to send a broadcast
network over the complete network.
Now, if Client A which
sends this broadcast frame
itself, then there is a problem
because there are certain situations
where clients are out
out of reach of each other.
So that's the hidden terminal problem of
Client A would broadcast the message
Client B would not receive it.
So this was, of course, anticipated by
the designers of the Wi-Fi protocol.
So instead, what happens if
if the client wants to send to broadcast
free at first, sends it to
the access point and
it will essentially sent this frame,
which as the immediate receiver to access
points. However, the final destination
is the broadcast Mac address
because the immediate receiver is the
access point.
It will be encrypted using the session
keys.
And when the access point receives this
frame, it will also use a set of keys to
decrypt this frame.
But then it will see. OK,
the final destination is actually the
broadcast Mac address, meaning I will
have to forward it to all clients.
And of course all clients are in range of
the access point. So in this case, all
stations will receive it.
And when the access point sends
the broadcast from the immediate receiver
on the final destination are both
the broadcast Mac address, meaning in
this case the group is used
to encrypt on sentence frame.
So the important takeaway message here
is that only the access point
normally it will sends real group
frames because the client will
first forward it to the access points
as a unicast frame.
So that's for a quick
introduction.
So as I mentioned, the talk will mainly
be about predicting the orangy
and then decrypting all traffic.
So let's start with
predicting the orangy.
So the first question is, OK,
this is the Wi-Fi standard.
Specify some methods on how to best
generate these groupies.
And it turns out that, yes,
they do specify a method
on in particular, they have a certain
procedure for generating a group
that will be used on the
crypto.
People call this the key hierarchy
that is being used.
So it's actually fairly
straightforward.
When your access point starts up,
it will generate a public account or
value. So a random counter does not start
at zero. It can start at any value
you want, but it's public.
So an attacker or outsiders are
allowed to know this variable.
Apart from it. It also generates a
private master key on
this has to stay secret.
Otherwise all your security guarantees
are gone.
So once you have generated
these two fields, we simply
take a hash of both of them on
the output of that hash is the current
group and the current
group is also called to Group Temporal
Key. And the reason they call it temporal
is because you can refresh it every hour
or every day or every ten minutes.
And that's also the advantage of this
construction, because if you want to
generate a grouping, it's very simple.
You simply increase the public counter
by one. You recalculate this
hash value and then you get
a new group.
So this design seems
very nice because if you want to generate
a new group, you simply increase this
public counter by one and you calculate a
new hash.
Unfortunately, this design is actually
quite bad.
Why is that?
That is because these two values
are only randomly sampled
when your device boots and new entropy
is never introduced into
the system.
So if for some reason and a decorator
compromises the scheme and knows
it, he can predict all future keys.
Or in our case, if the random number
generator is bad, we can probably
predict all future keys that are
generated.
So this is a bad design
and should be avoided.
Unfortunately, a.
It is officially specified this way
and the standard so in principle,
well, the standard recommends everyone to
use this key hierarchy, this procedure.
So, OK, now we know that if we can
predict these two values,
we can derive our group.
So the next question is, how are
these random numbers generated?
And again, the Wi-Fi standard
provides us with an answer because
it suggests an example,
random number generator.
And if you read the standard, it
actually sounds quite promising because
it says the orangy
that we use should generate
a cryptographic quality randomness.
And to show you the quotes
and detail,
a station must be able to generate
cryptographic quality random numbers.
And you can look at the appendix at
Section five to see how
you can achieve this.
So this sounds very promising
until you actually go to
the appendix and there it says,
well, wait a minute, what we're going to
so show is just an example
solution.
Ideally, you should extend
it yourself.
And of course, that's not really
that this is a strange situation because
the standard itself, it says this arangi
and the appendix is secure.
But if you actually read the appendix, it
says this is just an example solution.
It may not be that secure after all.
So we have an inconsistency in the
standard here.
And just to come back to
the text that is shown in the appendix,
it says that, OK, you probably
should combine it with other
recommendations on how to generate random
numbers. This is expository only.
Again, you should probably improve
this, which is very strange
to see this kind of language in a
standard.
So we basically have an inconsistent,
inconsistent description here.
It says that
it should be secure. Then it says it's
not really secure. So the question is,
how secure really is this random
number generator on?
The next question is how many platforms
implement that?
So let's look in detail at how
the random number generator is
implemented.
And here we see that the standard
basically defines a
function, which is the orangy.
And first of all, it's a statelets
function. I'll come back in a minute.
Why that? It's a bad idea.
But first and for all, it has a very
vague description, even if they
only meant that this to be like an
example solution to get people on
the way. Because if you look at the code,
there is a main Y loop here,
a main loop, and it simply says,
repeat this algorithm until it's
random enough.
They don't specify what this means.
So that's very strange
and suspicious,
a bit suspicious as well as also at the
end of the algorithm, at the end of the
loop.
So during certain parts of the loop, they
say if the time is set to as if
the time is not available, you can simply
set it to zero.
So this this line might not
be that bad if they include something
like if you set the time to zero, maybe
you should include should do more
iterations of the main loop.
But they simply say, oh, well, if it's
not available, you know, just skip it.
So.
Like I mentioned, the standard is
a bit hard to interpret because
they say it's an example solution,
but in other parts they say it's
supposed to be good.
But even if they only meant it
as an example for
the vendors, this description is still
just too vague.
Now, to come back to this status part
here, the random
number generator is executed on the math,
on only when this function is being
called as random.
This collected.
Again, this is a very strange design,
because if you have a proper orangy, for
example, the one in OpenBSD or
the one in Linux or the one in
any decent design, basically
there entropy is constantly collected
in the background.
For example, you have your timing of
interrupts, timing of packets,
you have clocks. Q and so on are
normally all this randomness and
collected in a so-called entropy pool.
And then if you need randomness, you can
extract a random number from this entropy
pool, for example, using a hash or any
other construct.
But the fact that this function is
executed on demand
is also a very bad sign.
So all that is
not that promising.
And if we then look at
the actual events where it extract
randomness from, we can see that is
mainly based on the timestamp
of that frames are arrived and
also on Clock Jetter.
So let's look at these two sources
in detail.
We have our frame arrival times.
So if you're Rotaru would be connected to
an Internet cable and there would be
a sufficient amount of traffic, then you
could simply collect this based on
Internet traffic.
However, you don't
always have the guarantee that there is
sufficient traffic available.
And
the standardization committee, the people
realize this like there may not be
that much traffic available.
So what they said this now, if
there is not that much traffic, simply
wait until a client wants to connect
and then send a few messages of the
handshake. Then about the handshake,
restart the handshake, then abort the
handshake, restart the handshake until
you captured enough frames.
So this, first of all, would be very
time consuming.
The second bigger problem is if you
are a client and you are constantly
trying to connect with a network, but it
fails a few times, then your device
will simply blacklist the access point
and this will not work.
So the fact that they even simply
suggested using this is my
opinion, absurd.
So the second source is the
clock Getaround Dreft.
So if you have a clock and an
implementation, it is never completely
accurate. There is also a small
amount that you can't predict as an
attacker.
The problem here is that they don't
specify a minimum resolution
that the clock should have so a
vendor can use any clock at
once, even one with a very low
resolution, meaning only a very
low amount of entropy is
collected. And of course, that's quite
bad. So after I saw
this, I thought to myself, OK,
this is just basically
a big mistake of the standardization
people. Surely everyone realized
that this was bad.
Aren't they implemented something big,
something better?
But when I actually looked at codes,
so, yeah, this is really like, what the
hell are they doing?
So if you look at vendors,
we have, for example, mediatheque,
it was used to be called also Rawling.
They implement this random number
generator almost
as specified with a few changes.
And those changes actually
weaken it a bit more.
They also did one good part, by the way.
I'll come back to that in the minutes.
Then there's also Broadcom.
The random number generator debuts
depends on the operating system
that is being used.
And then there is also open firmware,
which is a good example of an embedded
system on there as host APD, which
is the open source implementation of
Linux.
And you can see they do it properly.
So we did a very rough estimate of
how many networks are
run using this mediatheque or
Broadcom implementation.
So this was just using a very quick
word drive around my city.
And I determined whether the VISUS
using mediatheque or Broadcom based
on the fingerprint of the beacon.
How that works is explained in a
different paper.
But essentially I did a very,
very rough estimate.
And they at most,
let's say 25 percent
of networks could be vulnerable to this.
I would say maybe five or 10 percent
could. Attacked using attacks
similar to the one we're going to present
just to show that these are
a bit popular and you might be able to
use this and practice.
But anyway, let's look at the first
implementation, the one of mediatheque.
So what did they do?
Well, first of all, they implemented
the key hierarchy sort of
procedure on how to generate these GIs
as proposed by the standards.
So just to recap, this is this
construction where you generate two
variables, one which is secret,
the other which can be public,
then a hash is taken and the output is
shown.
They do improve this
slightly, actually.
So they do one thing that is good,
namely, instead of when they want to
generate a new group, instead of
simply increasing the counter by one,
they actually constantly generate a
completely new random value for the
counter. And that's that's actually a
very good decision because then you are
introducing new entropy every time
you generate a group.
However, this group, Moustaki, that
one is only sampled at time.
Um, OK,
so we now know how their
construction works.
Now the question is, how do they
implement this random number generator
and can we then try to attack it?
Well, this is the bad part of their
design. They only use clock
jitter to extract
randomness, to collect entropy.
And particular, it uses the so-called
Jeffy's counter of the Linux
kernel. So the Jeffy's counter
is something that is increased every
tick, but not every processor tick,
but every logical tick.
And I'll come back to that in a minute.
So.
This orangy is likely quite bad.
This is good for us because at least for
us as attackers, because we
simply have to protect the group, Masaaki
and this public counter, which is also
count denounce the group
Nons.
And if we can predict both of them,
we can derive the group key.
So let's try to attack this
orangy.
As I mentioned, it uses this Jeffy's
as the counter.
The problem is these Jeffy's have at best
millisecond accuracy, which is
rather low.
In fact, it's really low.
So this means in practice that the
JMC so this secret
key which is generated at but
generally it always uses the same
Jeffy's value. So to claim the same
values.
So that means in practice for
gym K, there are say around
200 to 300 possible values,
at least if you have it.
I tested this on my device on for a
specific device, on specific firmware
version.
Then you have a limited set of
possibilities.
Of course, if you run a different
firmware version, then
some other things might happen during the
boot process influencing the
time when these jiefu chip values
are collected.
But if you know the implementation, your
attacker attacking you have a very
limited set of values.
Then the second part is we have to
predict Jennens value
on most routers.
It is the group we
regenerate at every hour, meaning this
Jennens value is also sampled every
hour. So in order to predict this value,
we need to know the uptime of the router
to predict the range of possible Jeffy's
values that we're used
to. How do we do?
How do we determine the uptime of the
router? Well, it's quite simple.
The uptime is lit and the beacons
of most routers.
So we simply have to sniff beacons
that we can estimate the uptime of the
router and then we can estimate the time
of when this jennens was generated.
So basically, what do we have to do
for a successful attack?
We need to capture one encrypted
broadcast or multicast message.
We have to capture also a few beacons
to estimate the uptime and then we can
do a search through a hole
through the whole key space.
We tried this against our own
router. So that's this
one here.
We noticed well, we implemented
a program on the GPU in particular
on open call to make sure we
can do this in a timely manner.
And we found that using
the GPU in my laptop, which is just
standard GPU, you can even
get better use or even multiple
ones. But even just on my normal laptop,
I can crack the case within three to four
minutes. And this.
Thank you. So this is assuming
the roads are also as uptime of one
year, if the uptime is
around one year, then there is also a lot
of klukowski, meaning predicting the gene
is harder.
So if I'm going to demo the attack
in a few minutes, then
I know that the uptime was very low,
meaning I can reduce this number even
further because there hasn't been
that much klukowski meaning predicting it
will be easier.
So it is in a sense, is also
a worst case estimates.
However, I do have to note that this is
only if you are attacking one specific
device, if you know which device you are
attacking, let's say you don't know the
exact firmware that is running, then you
have to perform a bigger search.
So the end result here is that you get
both the master key and the current
group.
So I planned a demo
here. Now, wi fi demos are always
very risky, especially
in a situation like this.
So fingers crossed.
So let me first
try to mirror the screen.
That's what we don't already fail here.
OK.
So here
I have a Wi-Fi device that is running and
the monitor remote, and they
have a script that will capture
the frames sent by my
router. So I already put
it in monitor mode.
So that is simply this script just
executes some commands to put
it and monitor remote.
And I'm now going to capture packets that
are sent by my router.
And they made a Python script for that.
So let's execute that and
capture packets from my router.
As you can see, it's now trying to
capture packet's, but nothing is received
yet that is normal because the router
is not yet started.
So let's put it on.
This was planned, by the way, to show you
it's real.
So now the router is booting up in
a few seconds.
It should be receiving a
beacon from which it can derive
the uptime of the router.
You can see. There we go.
We got a beacon and now it's waiting
for an encrypted broadcast packet.
Now, this is one small
limitation of the attack
up.
As you can see, it was waiting until my
laptop connected to this network
because if no one is connected to
the network, then there is,
of course, no traffic.
So there must be at least one client or
for some reason, the router has to send
one broadcast frame that
is encrypted using the broadcast scheme
because otherwise there is nothing
to crack. We don't have any data.
So in this case, we captured
this frame. So let's
try to open this capture file
so you can see here we captured
a lot of beacon frames and this
beacon frame has a field here,
which is called the timestamp
on.
From this, we can determine the uptime.
So here you can see it here it's very
close to
zero.
And every time it increases on from this,
we can determine the uptime of the
router.
There you go on
that, the very end of this capture, we
have this broadcast packet,
which we want to decrypt,
so let's try that.
So as I mentioned, this works on
the GPU.
So first I have to type Opteron
to enable my Jeep while
executing the next commands.
So I simply have a script here.
I'm attacking the mediatheque
implementation and I'm using
the capture I just made.
So now it's part of this
file here, at least all the networks
that we captured in this case because
we are in a crowded room, I made sure
that I only capture frames
from my network
to try to make sure that the demo indeed
works. And you can see now it's
trying to predict the group master
key under this estimate that the
values that were used there, where
around this number on the Jeffy's values
that were used for the Junon
that's estimated around this value.
Now, you may be wondering, why is this
Jeffy's value so high?
Doesn't it start at zero?
This is actually very interesting.
In my opinion.
The Linux kernel starts at the
value of minus five minutes.
Why do they do that?
Well, that's because if you are a
developer on, there somehow
is a book in your driver that after
five minutes when you're gifty, values
overflows. There is a problem that the
developers would very quickly detect
issues. If you were, Jeffy's value would
overflow.
This is just to explain why this number
is so high, even though we just booted
the router.
And anyway, you can see that we
successfully found the group
key here and even
decrypted the packets for us.
So that worked and
it wrote the single decrypted packets to
a file as well. So let's
open that as well so you can see that
that indeed works.
Here, that's the wrong file.
Decrypts, that's unair, you can see the
decrypted broadcast, it was on
our packet,
on the air, you can see the decrypts
packet so we can correctly predicted
the group key, aren't we?
Were able to decrypt this packet.
So let's now try to switch back
to the presentation.
O kay.
I will have to go through these slides
again, probably.
Oh, OK, so
that was the demo the Democrats
have praised us.
Thank God it worked.
So
now let's come back to the other vendor,
the Broadcom vendor.
So, as I mentioned, this depends
on the operating system that they are
using.
In particular, if they are using Linux,
then they implement the Gruchy hierarchy
as specified in the standards,
but they simply reads random.
This from def you random.
So that is much better than
the random number generator proposed in
the standard.
However, a few years ago there was a
paper called Minding Your PS
and Qs by Heininger at all,
and they showed that on
specifically on embedded devices
and on are older Linux kernels
that if you ran them, might be
predictable.
So this means that on certain devices
are few random is predictable, and in
turn all the group keys might be
predictable as well.
Now, if you run a new Linux kernel,
this should no longer be an issue,
however, because a lot of routers use
an old kernel.
This might be an issue.
I haven't tested this.
This is simply based on their
paper that therefore random is not
ideal and for all the kernels,
essentially.
So that's for Linux.
This Broadcom implementation also runs
on Vieques, works on the
coast. So for those of you who don't
know what these operating systems are,
Vieques works on the East Coast.
They are both essentially real time
operating systems.
Vieques works is proprietary.
It's used a lot in aerospace.
So it's used in the Mars lander.
It's used by SpaceX.
It's also used in drones.
And of course, it's also used on certain
routers and access points.
Then there's also Eco's, which is
essentially similar.
It's also a real time operating system,
except it's open source and
it is again used in aerospace and it's
also used by the military
in certain situations.
But of course, we focus on when she was
in the router and when it's used as
an access point.
So we see that in this case,
Broadcom again implements
the ADA on a two Gruchy
and four random numbers.
It has it simply takes
the modified hash of the current time
and microseconds.
So, again, that's not ideal
at all.
There is also another
disadvantage of their implementation
on their use. This public countered
in the handshake and the four
way handshake that you use to connect to
the network.
Now, this is perfectly allowed.
There is nothing wrong with that,
but it does make it easy for us as
attackers because we can.
Collect the value that was used here in
the handshake, answer the one that was
used while generating the group will be
only a few numbers away from this value
that was leaked.
So really, the only thing we have to
predict here is the group
Master Key.
And if we have the group master key, we
can then again predict the group.
So one popular router
which is vulnerable to this is
the team
54.
At least. If you have one that uses
version five or higher, then
it uses the word kernel.
So if you have a router which is version
four or lower, it runs on the next
on. Of course, if you run, we are
added to you on this.
You're also fine.
But if you have a version
five of this device or higher, then
you might be vulnerable.
Unfortunately, I only had
older versions of this router at home,
so I simply assimilated this attack
again, using open codes
and even with simply quite modest
assumptions.
I predict that you need around four
to five minutes on my CPU
to crack it.
Let's say that for some reason my
simulation is not perfect.
Then you can use a more powerful GPU
to still predict.
But again, taking the life of the current
time and microseconds, it's simply
not sufficient to collect
enough randomness.
So that concludes both
these implementations.
Then we also have two other examples.
The first is called open.
Fermor are the as is
so open firmware,
essentially, it's simple.
It's a simple open source bio system.
And what was really surprising to me
is that during the bias, these
people have very basic
support for Wi-Fi functionality.
At least as a client, you can even
collect connect through a WPA to
secure network.
Now, for me, that was very surprising to
see that BIOS supports Wi-Fi,
but they do.
Now, I do have to say that they only
implement Clayne functionality so they
don't implement access point for
functionality, so
they don't actually generate a group.
However, they do use a random number
generator to generate other values
that are used during the Wi-Fi handshake
aren't very, very simple
methodology.
They simply take the amount of text that
have occurred since Boutte's.
They run that to a linear
differential generator, which is
simply a deterministic function
and that's used as the random number
generator.
The output of this is hashed
to gather sufficiently long outputs,
but still this is very easy to
predict.
And we included this because
this is a very good example of
an implementation that is running on an
embedded system where there is no kernel
available to provide you with random
numbers. So in this case, we are in the
bias. There is no kernel, there is no
libraries we can use to generate random
numbers. And we see that in that
situation, very bad solutions
are used on at the end of
them. At the end of the presentation, I
will show a way where even
in these scenarios, an embedded system,
we can still try to come up with good
ways to generate random numbers.
So as a last example, we have
a host, Abdeh, which is
essentially the most used
access point on Linux, for example,
it is used by Android.
If you set up a hotspot
and they have a very good implementation,
they implement the either on a 2.0 11
group key.
They extended it to include entropy
every time a new group is generated.
So that's very good.
Even better than that, they read from
Def Random ombuds and
for some reason there is not enough
entropy available.
It will simply wait until the first
client connect and then it will try to
read again from the referendum.
And if there still isn't
enough entropy available, it will simply
reject connections.
So in other words, if you
host Abdeh, everything should
be fine.
Of course, if the colonel and
everything works properly,
so that concludes how we can generate
and predict this group.
We will now explain how we can.
So this is the second main part of the
presentation, how we can exploit
this group to inject on decrypt traffic.
So let's start with a simple case.
We want to inject a unicast IP
packet and we
want to send it towards a client.
So.
Your initial idea may be OK, you
have your IP packets right here,
you simply put that into a broadcast
wi fi frame.
So here we have the Wi-Fi header, of
course, very simplified.
Basically, we are flex in the header,
which says that this broadcast broadcast
frame is sent towards clients of
our network.
And the receiver is the broadcast Mac
address because the receiver is the
broadcast Mac address this IP packets
and everything is encrypted, unprotected
using the group.
However, this will not work.
And why is that?
Well, the client notices that
this unicast IP packet
is received on a group addressed
Wi-Fi frame, and
this is the so-called whole
one hundred and ninety six check
and basically says you
should reject packets that are sent
on that group, addressed then Linklater,
but are sent to a unicast IP address.
In other words, this technique will not
work.
So how can we try
to bypass this technique?
Well, the realization we have
to make is that this check occurs
when a link layer packet is being passed
on to the network layer where we have
these unicast IP addresses
on an access point only works
at the link layer.
So if you can somehow abuse the access
points, then we might be able to bypass
this check.
So let me simply explain the technique
that we're going to use.
So we have our network here with the
victim, with the attacker, which wants
to send a packet to the client.
But what the attacker will do at
will first send this IP
packet towards the access point.
So, again, we have our IP
packet here.
Now we add a bit more complicated Wi-Fi
header, which says this group from
this broadcast frame is sent to the
access points.
The immediate receiver is, in this
case, the broadcast Mac address.
However, the final destination of the
frame is the victim.
So what will happen if the access points
receives this frame?
Well, it will notice the frame
is indeed destined for me.
I will use the group key to decrypt it
because I did receive it on the broadcast
Mac address. Everything is fine
and then it will notice while it's still
operating at the link layer.
Oh, but the final destination
is actually the victim.
So I have to forward this packet to the
victim. And the access point of
course has the section keys to pairwise
keys of the client.
So it will simply take this IP packet,
it will encrypted using the session keys
for us and then it will simply
send it to the victim for us.
And now when the victim received this
packet, everything seems OK.
We have our unicast receiver addresses,
unicast IP address.
It is properly encrypted, so everything
is OK and the attack works.
The second part is that we want to also
decrypt packets of the idea behind
this is very simple.
It's also very simple to explain we
simply are poisoned the router on
the client so that the IP address of the
gateway on the IP address of the client
or the broadcast Mac address
and then both the roads are on,
the client will send unicast IP
traffic through a broadcast Mac address
on the table, encrypted using the group
free Gruchy, which we have
so we can decrypt this packets
and then forward them to assure that
connectivity stays on,
that the client doesn't notice anything.
So that's actually quite simple.
How we can we prevent this?
Well, the first thing is that if the
access point receives a broadcast stream,
but with a unicast final destination,
it should not forward this
on an even better countermeasure.
Is that in an infrastructure
network, so not necessarily
in a mesh network, but in an
infrastructure network where you have an
access point, the access points
simply ignore frames
that are received on a broadcast MAC
address, and then these issues
would be avoided.
So I would say that was the most
fun part of the research,
we're now going to look at a theoretical
attack against a handshake
that is being used where we can force
usage of our C4.
So, OK, let's first quickly explain
how the handshake works.
So we have our client here, which
sometimes is also called to the
supplicant during the handshake, aren't
we have our access point?
So the beginning is very simple.
Your access point is constantly
transmitting beacons.
Those beacons contains the futures,
the futures of the access point,
for example, whether it supports
either 802 dot 11
or whether it supports AC, and
it also includes the support of
the ciphers of the network and
practice. This basically means whether it
supports WPT Chip or
a CAMPI,
then the client will select a dirty
cop or a yes no will
send an association request to the
network on this.
Becket's here basically tells the
network, I want to join on
this is the cipher I want to use
and reply to that the access points
generates generates around them nonce.
The client will also generate a random
NUNC. So these random
nonsense are used to prevent replay
attacks. Ontari used to assure that
fresh session keys are negotiated.
So here we have the access point,
non-store to einen and we have the supply
Norns also the client.
So it's the same as the client, which
is of the essence.
Once they both have received this as
nonsense, they can receive, they can
arrive the session keys
on. After this first stage of the
handshake, we are essentially going to
confirm that everything
was OK, that there was no attacker
on the access point is going
to accept the Gruchy,
the group temporal key in the message
of the handshake and
message. Three, it also includes an
authenticated cipher list of
the cipher that the access point
supports.
So this is to prevent downgrade attacks
that say that we have a man in the middle
attacker, which here says, OK, I
only support the old TCP
cipher, then the client
would connect using takeup.
However, at this stage,
the real access points, which
sent a message which includes
the real cipher list, which is
authenticated using the passwords
of the network, essentially meaning an
attacker cannot modify the spigot,
the client would notice after receiving
message if there was a possible downgrade
attack because this authenticated
cipher list might not match the
ones that was received in unprotected
beacon's.
So the problem with this
design is that the group key
here is transmitted aren't encrypted
before the client can prevent
or detect downgrade attacks.
So what can an attacker do here?
An attacker can put up
a rogue access points.
It can modify the beacon messages and
say, hey, I only include I
only support Kipe,
which means that the client will connect
using takeup arms
in case that the session cipher
takeup. Then there's group here
when it is transmitted to the client
is encrypted, unprotected, using
for if a
yes would have been used, then we also
would use a yes to protect a group and
everything would be fine.
However, in this case we are using
our C4 if we can, if we are performing
this attack on our C4 is
of course quite
bad.
So for the crypto people around here,
I'm very quickly going to explain
how our C4 is used.
You basically have 16 bytes
initialization factor, which is public.
You have a 16 byte secret key on the
first. Two hundred and fifty stream bytes
are dropped.
This is actually a very strange
construction if you're a bit used to ask
for.
I'm simply going to intuitively explain
the problem with RC four in this case
and also the problem with RC four
in general.
Here you see a graph
which kind of illustrates the behavior
of our C4 in this case.
So normally, if
you make these kinds of graphs for
a secure cipher, for example, for a
yes, this would be completely
white.
So what does this graph illustrate?
Well, see, for example, here you are
at keester position, say,
300.
If we then go look at
XStream value, let's say around 90,
we can see that there is a blue dot here.
What does that mean?
That means that
the key stream by acquisition 300
is. Slightly less likely
than uniform to contain the value
90, normally, this
should be uniformly around them.
Normally, if you have a proper
cipher, every key stream
should occur as
often as all the others.
However, you can see here and the colors
that these blue keys invites at certain
values occur less often on
these red ones occur more often
than others.
This graph depends on the specific
analyzation vector that is being used.
So the only thing I would take
away from this slide is that if
you use RC for some key stream, values
occur more often than others, although
we can abuse that in an attack.
So if we were to perform
similar attacks against the ones that
were executed against
SSL on HTTPS and the few
recent years, then we
can see it's still a theoretical attack
because it would take around 50 years to
execute.
The reason is because we need to collect
a lot of encrypted traffic to perform our
cryptanalysis aunt in a case
of wi fi. This is very time consuming
to do.
However, attacks only get better.
In fact, a few weeks ago I
found a trick to execute these
handshake's more frequently, meaning
this time would be, I think, at least
divided by two or three.
So let's say that someone would put more
time in this.
We could probably lower this value
more and more every year.
So the takeaway messages from a
cryptographic standpoint, our C4
is broken and you should simply not
use it anymore.
So the counter measure is if you have a
network at home, simply disable
WPA to keep.
So if you have a network network,
not only should you select that, it
has to use WPA too.
You have to explicitly configure
it to only use A-s
on. In that case, you are safe against
this specific attack.
So finally, the last part
of the presentation is just a very
short, short suggestion on
that, how we can we improve
the random number generator and
we want to make sure that the improvement
that we suggest even works
on embedded systems where there is no
kernel available
on the is very little chance
of collecting randomness.
Well, our observation is essentially,
well, OK, we have a Wi-Fi chip
on this Wi-Fi chip can monitor
all the Wi-Fi signals around.
So why not simply extract randomness
from all the Wi-Fi frames that we
receive, not our words.
Why not collect randomness from
background noise and.
We actually found one device,
it is this one, this has
a so-called spectral scan feature,
and this means that this
chip is able to collect a lot of
samples of the current
Wi-Fi background noise, even if there is
no traffic or nothing is going on
and we can generate a very large amount
of samples every second.
The current downside is that
this is a bit energy.
This takes a lot of energy.
So you can run this very long.
But we did implement this idea to
extract randomness from
the noise of the Wi-Fi
channel, and we did a
few statistical tests on this
and our results were promising.
It shows that we can indeed extract
randomness from background noise.
Now, this is just a proposal.
Some more research here is needed.
But I do think that Wi-Fi vendors
should provide the features that
common Wi-Fi chips exports
some of this randomness which can then
directly be used or it can be used by
the kernel to strengthen the current
pool of randomness.
So that concludes
my talk.
There are a few important lessons
to take away here.
The first is if you have a random number
generator, always check the quality
of the output on, especially
if you put in the standards.
Don't put a very bad example
algorithms which are really
bad. If you design a specification,
what you put in there should be good and
it should work.
Otherwise, just reference an external
source where it is explained
better and to
protect to defend against the attack,
where we decrypt all traffic of a
network.
Like I mentioned, the access point should
ignore any frames that are
received on broadcast mac address
or which should simply not
forward unicast frames that are
sent on a broadcast Mac address.
Finally, regarding the protocol
that is used in the handshake, you should
try to avoid sending sensitive data
before trying to protect
downgrade attacks.
So that concludes my presentations.
If there are any questions, feel free
to ask.
Thank you, Marty. We have a few minutes
left for questions, so if you have any
questions, please line up next to the
microphones
and ask your questions.
Make good use of our time
if we have any questions from the
Internet. Yes, please.
Yes, two questions from the Internet.
The first one, uh, would you consider
WPA two with appreciate
Kenya still safe?
Um, if the
key is good on unpredictable,
then this type of dictionary attacks,
they are no longer possible.
However, you still have the issue of the
group. And in fact, this group,
which is Batley generated.
This applies to both enterprise
networks and networks that use
appreciate.
Currently, I believe that
the handshake that is used in wi fi can
be improved. So if you use appreciate
key, I don't consider
it as strong as an enterprise
network where you have proper
credentials.
So I would say that an enterprise network
is more secure in most cases.
However, as a general user, if you have a
complex, pre shared key, then
you're still good.
OK, let's hear from you
for the spoofing, did you consider
Gratitudes our offer on the networks
because you already have access to the
broadcast? So,
um.
Well, I think that's what we used to
poison the interests of the
clients. So we send a broadcast
our packet to poison the
client on the router, if that explains
your question. Yeah, but you can you can
explain the clans in the network.
You send gratuitous art.
So you basically broadcast
to our injury to anybody on the network,
just not one single client.
We've the well, you can send it to any
client you want.
You can say, I want to inject traffic
of this client or you can maybe
try to send it to all clients.
I haven't looked at that much in detail.
I just said, if you want to attack one
client that works, if you want to take
another client, you can just do the same
attack. OK, thanks.
Yes,
we regarding your problem,
I have access points and the broadcast
packets. So that's a unique aspect.
Is it the demand and the standard to do
it this way, or have you checked
if all implementation do it this way
or only son?
That's a good question.
I don't know exactly what the standard
says.
What I do know is that not
even all implementations implement this
whole 1996
attack. So there you can even directly
send frames to the client without needing
to abuse the access point.
So I don't think that this idea of
forwarding packets is explicitly
mentioned in the standard.
I think they just haven't
thought about that.
But I would guess that most
implementations would be vulnerable to
this forwarding trick through the access
point.
I mean, I would be surprised if certain
vendors thought about protecting against
that. It could be, but I think the
chances are low.
OK, let's talk a last
question. Sorry, no, no.
OK, then I think we're done again.
Big round of applause for a great the.