- Hello.
I am Mathy Vanhoef
and together with Tom Van Goethem,
we will be presenting Timeless Timing Attacks.
Tom Van Goethem is a researcher
at the DistriNet group in KU Leuven in Belgium.
He is a fanatic web and network security enthusiast,
and he likes to exploit
side channel leaks in browsers,
and more general in Web platforms, as well.
I am Mathy Vanhoef.
I'm a postdoc at NYU, Abu Dhabi,
and I'll, later this year,
be starting as a professor at KU Leuven in Belgium.
I'm interested in wireless on network security
and software security,
and also a bit in applied crypto.
Previously,
I discovered a KRACK attack against WPA2,
and the RC4 NOMORE attack.
And in this presentation
we'll be talking about timing attacks and timing leaks.
Let me start with some examples of timing leaks.
In the top left corner
we can see a straightforward timing leak
where depending on some secret condition,
extra computation is performed.
And here, the execution time,
so also the response time of, for instance,
the web application will leak
whether the condition was true or false.
The top right,
we have a for-loop that iterates
through all the elements in an array
and the for-loop is terminated
once an element is found with a certain secret condition.
In other words,
the number of iterations that are being executed,
depend on some kind of secret information,
and this, again,
also means that the execution time of this for-loop
leaks sensitive information to an adversary.
Finally, at the bottom,
we have an if test that checks
whether an array is empty or not
and if it is not empty,
extra computation is performed.
And here, you can imagine a web app
where you can search
through secret documents using a key word
And then this code would leak
whether this keyword is present
in a secret document or not.
How are these timing leaks exploited in practice?
Well, the attacker would first need to connect
to the target server.
The attacker then sends
a possibly large amount of requests to the server.
And for each request,
the server will measure
how long it takes to receive a response.
And then the attacker will compare
two sets of
timing measurements,
namely the baseline on the target.
And what do I mean with baseline here?
Well, with baseline,
I, for instance,
mean the first example here,
where then the secret condition
evaluates to false,
and the adversary knows
that the secret condition evaluates to false.
And the adversary will use that as a baseline
and the target request is then a request
where the adversary doesn't know
what the secret condition evaluates to,
but based on the response time,
the adversary can then derive
whether the secret condition and the target request
is also false,
or whether it is in fact true.
And to check whether there is a difference
between the baseline of the target request
we will be using statistical tests
to determine whether there really is
a significant difference or not.
There are several factors
that influence the success rate of a timing attack.
The first one is the network connection
between the attacker and the victim server.
And in particular,
the higher the jitter of this connection,
the worse the performance of the timing attack.
Now, the attacker can mitigate this
to some extent by,
for instance, moving closer to the target.
So in practice that could be renting a server
in the same cloud provider
where the victim is also located.
And I also want to remark here
that the jitter is present both on the upstream path,
so in the requests,
and in the downstream path,
so in the responses.
Another important factor is the size of the timing leak.
So it's much easier to exploit a large timing leak,
say, of 50 milliseconds
than it is to exploit a small timing leak of,
say, five microseconds.
And finally,
the last important factor
is the number of measurements that on adversary can make.
In particular,
the more timing measurements that an adversary can make,
the better the performance of the timing attack will be.
And Tom will now show
a graphical illustration of a timing attack.
- Thank you for that introduction, Mathy.
So now let's see how
such a remote timing attack works
with a visual representation.
So we have our attacker on the left side,
sending the request to the server.
And this request goes over the Internet,
then is processed by the server,
a responses is generated,
and sent back to the attacker
and the attacker will then measure how long it took
between sending the request and receiving the response.
And in this case,
this was a bit over three seconds.
Then the attacker stores this timing value,
and then he will probably need to make multiple requests.
So he starts sending the next request.
But here on the third hop,
there was a small delay,
also causing a delay in the arrival of the response.
So this means that because of this jitter
the attacker will need to make multiple measurements
and then
apply some statistical analysis
in order to reveal
the true processing time of the server.
We did some measurements
to see how many requests
the attacker would actually require.
We varied
the number,
or the difference in timing
of the processing time
between five microseconds and 50 microseconds.
And then we determined how many requests
an attacker would need to achieve a 95% accuracy.
Our attacker was located
in our university network
located in Belgium,
and then we set up servers across the world.
And then we performed the attack
to see how many requests were required.
To detect a timing difference of 50 microseconds
with a server in the EU,
with the attacker also located in the EU,
a total of 333 requests were required.
Now when the server was further away,
so for instance,
when it was located in the U.S.
more requests were required.
In this case, for 50 microseconds,
well over 4,000 requests were required
to detect this difference.
You can also see
that as the timing difference became smaller.
also the attacker required more measurements.
For 20 microseconds,
it was close to 3,000 requests that where needed
for the server in EU,
growing to
23,000 for 10 microseconds.
And for a timing difference of five microseconds,
we found that it was not possible to do this
with the maximum set to 100,000 requests.
We were thinking how can we
improve these remote timing attacks?
And that's how we came to timeless timing attacks.
We know that if we rely on
absolute response timing,
this will not be very reliable
because there will be always
this jitter that's included in every request
because the request
needs to traverse over the Internet,
and so does the response.
Then we thought, okay,
then maybe let's get rid of the notion of time.
That's why we call these attack timeless.
So instead of relying on
the sequential timing measurements,
we can try to explore to concurrency
and only consider the order of the responses.
We don't use any
absolute timing measurements anymore
in these timing and measurements.
We just look at the response order.
And this means,
as a very important side effect
is that these timeless timing attacks
are completely unaffected by network jitter.
So let's see how this works in practice.
Again, we have our attacker on the server.
But now the attacker is not just sending one request,
but he will be sending two requests
that are contained in the same packet.
These two requests
arrive simultaneously at the server
and are processed concurrently,
and because the light pink requests
took less time to process
the light blue response will be generated first
and sent first to the attacker,
allowing the attacker to detect that
these requests required less processing time.
If in this case,
we have some jitter on the way to the server
it will not affect
anything
because both requests will still arrive
exactly at the same time at the server,
because they're contained in a single packet.
And then they can be processed simultaneously
at the server site.
And again, we see the same result.
- Thank you, Tom.
So what are the requirements of a timeless timing attack?
Well, first of all,
the requests need to arrive
at the same time at the server.
The server needs to process these requests in parallel,
so, concurrently.
And the order of the responses
needs to reflect the difference
in the execution time on the server.
Now let's explore these three requirements in more detail.
The first requirement
that both requests arrive simultaneously at the server
can be fulfilled in two manners.
Namely,
we can either rely on multiplexing
or on encapsulation.
And with multiplexing,
our example is the HTTP/2 protocol,
and this is because with the HTTP/2 protocol,
two requests can be sent simultaneously
over the same connection.
In fact,
a single TCP packet can carry multiple HTTP/2 requests
that will be processed concurrently
once they arrive at the server.
For encapsulation,
there our example is the HTTP/1 protocol
because the HTTP/1 protocol on its own
does not allow you to send two requests in parallel.
However,
when we exploit HTTP/1 over Tor,
or over VPN,
then we can send two HTTP requests
at the same time over Tor
or over the VPN network.
Let me illustrate these two cases graphically.
For multiplexing,
we have the HTTP/2 example
where, here on top,
you can see the two HTTP/2 requests in gray,
and the adversary will assure
that these two HTTP/2 requests
are sent in a single TCP packet.
This assures that these two requests
will arrive simultaneously at the server.
For the encapsulation case,
we have the HTTP/1 example where,
here again at the bottom,
we have two HTTP/1 requests shown in gray.
These two HTTP/1 requests are sent
in different TCP connections,
meaning they're also encapsulated
in two different TCP packets shown in red here.
And each TCP packet is then encapsulated
in a different Tor cell.
Now what the adversary now does
is the adversary assures
that these two Tor cells
will be aggregated into a single TCP packet
and once this TCP packet arrives
at the Tor union servers that we are targeting,
then the union servers will process these two requests
effectively, in parallel.
For the second requirement,
the second requirement is that these two requests
then have to be handled in parallel by the server
and whether this is the case is application dependent.
We have found that in most cases,
applications can handle requests in parallel.
One possible exception
is when you target cryptographic operations,
because those often have to be handled
in a certain sequential order.
The third requirement then,
is that the order of the responses will reflect
which requests finished processing first.
And, in practice,
that means that the server
must immediately send a response
after it finished processing a request.
Additionally,
the adversary must be able to reliably recover
the response order.
In other words,
when the responses are sent back
from the victim server,
to the adversary,
the network should not be reordering these responses.
Now, in our experience,
in our experiments,
we noticed that these two responses
generally follow the same network paths,
meaning the order is maintained.
But even if for some reason,
the order of the responses is switched
along the network path,
then the adversary can still rely on TCP shields,
such as the TCP sequence numbers,
or the TCP timestamps
to recover the order in which the server
sent both responses.
What is now the performance
of a timeless timing attack?
Well,
let's first, and for all,
recall the performance of a traditional timing attack,
where Tom explained the first part of this table here.
On this slide we also added
the performance of a traditional timing attack
over the LAN and the local host.
For instance,
we can see that if we want to exploit
a timing leak of five microseconds
over the local host,
this would require a bit more than 40 requests
in a traditional timing attack.
In contrast,
if you look at our new timeless timing attacks,
we can, for example,
exploit a timing leak of five microseconds
using roughly 50 requests pairs.
And important here,
is that the timing leak can then be exploited
no matter where the adversary is located on the internet.
And this is in contrast to traditional timing attacks
because with traditional timing attacks,
we were not able to exploit
a timing leak of five microseconds
over the internet,
while for our timeless timing attacks we can.
On top of that,
I want to highlight
that with the timeless timing attacks,
we were able to exploit
a timing leak of just 100 nanoseconds
while with the traditional timing attacks,
the best we could exploit
was a timing leak of 150 nanoseconds
when the adversary
was in the same LAN or local host.
And, in fact,
over the internet a traditional timing attack,
at best could exploit a timing leak of 50 microseconds.
And this really shows that timeless timing attacks
are an order of magnitude more powerful
than traditional timing attacks.
That covers how direct timing attacks work.
It's also possible to perform
timeless timing attacks in a cross-site setting
and to perform timeless timing attacks
against Wi-Fi authentication.
And Tom will now elaborate
on the cross-site timing attack scenario.
- So these cross-site timing attacks,
they're a bit different from the direct timing attacks
that we were talking about before,
because in this case
it will not be the attacker
who's directly connecting to the targeted server,
but it will be the victim sending requests,
but still these requests
are triggered by the attacker
by launching some malicious JavaScript code.
This could happen
when the victim lands on a malicious website,
for instance,
by clicking on a link,
or if there's a malicious advertisement being shown,
or if this victim has a really urgent need
to look at some cute animal videos,
and then ends up on the website of the attacker.
So these requests
that are triggered by the attacker
with the JavaScripts,
they will include the cookies.
This means that the server will process the requests
using the victim's authentication.
Once that request has been processed,
the attacker can still observe
the order of the response.
For instance,
when he's using the Fetch API,
he can look at which promised results first,
and this will leak,
or this might leak sensitive information
that the victim has shared with the website.
We actually applied this timing attack,
this cross-site timing attack
to the search functionality in HackerOne,
where we were able to leak information
about private and disclosed reports.
One of the key differences
is that with direct timing attacks,
is that here,
the attacker does not have direct control
over the network.
Just because the browser
can choose how to send requests to the kernel
and the kernel will then send it to the server.
So we will need another technique
to make sure that the two requests
are joined into a single packet
and in order to do so,
we can leverage TCP congestion control.
This mechanism will prevent
the client from sending
very large number of packets at once
and it sets that attacker won't have,
sorry,
the client will need to wait for an acknowledgement
from the server before more packets can be sent.
As soon as the client is waiting for
acknowledgement from the server,
any other requests that are made,
all their data will be stored in the queue
and they will be merged together into a single packet.
So the attack looks fairly simple.
First we make
post requests with a sufficiently long body,
and then immediately after
we make the two target requests.
So the one will be for the baseline
and then the other one is
the target URL for which we want to see
if it matches the same timing as the baseline
or whether it takes longer or shorter.
Okay.
Let's see how this works in practice then.
Here we show the victim's packet queue.
The TCP packets sent that are being queued
to be sent to the server.
First the attacker makes this post request
which already sends off a number of TCP packets,
but there will be also some packets
that cannot be sent yet,
because we need to wait
for the acknowledgement from the server
and they'll be added to the queue.
Here every square
represents a single TCP packet.
Then the second line of codes
is where the attacker will
make a request for the baseline URL.
And as you can see here,
it's represented with this pink,
light pink.
And then,
second,
the third line of code will be
the attacker sending the request
for the target URL,
represented as the darker pink.
As you can see,
both requests will be added to the same TCP packet.
And then later on,
when
the client has received enough,
or sufficient acknowledgements from the server,
it's possible to send all the remaining packets
that are in the queue.
And as you can see,
the light and dark pink
requests
will be both in a single TCP packet,
which is exactly what we need
to perform our timeless timing attacks.
In this presentation,
we already discussed the direct timing attacks,
where the attacker connects directly to the server.
Then what I was just talking about
are the cross-site timing attacks.
And then now,
Mathy will be talking about a third attack scenario
where we use a timeless timing attacks
to break a Wi-Fi authentication.
- So it is also possible to perform
timeless timing attacks against Wi-Fi,
and in particular,
we're going to exploit the EAP-pwd protocol
that can be used in WPA2
or even WPA3 enterprise networks.
Most enterprise networks,
they use certificates to authenticate the server
and sometimes also to authenticate the user.
However,
this can be quite annoying to configure.
So in practice,
a small but significant amount of networks
rely on the EAP-pwd protocol and stats
to authenticate a user
using a username and password.
And when using these
enterprise authentication protocols,
the authentication happens between the clients
and the authentication server.
There the authentication server
is commonly a free radius server,
and the access point will simply forward messages
between the client and the authentication server.
And because of the authentication server
can be located anywhere on the internet,
the communication between the access point
and the authentication server
is typically protected using a TLS tunnel.
on the TLS tunnel is called a RadSec connection.
Now the EAP-pwd protocol
that we will be targeting uses the so-called
hash-to-curve algorithm to verify a password.
Unfortunately,
a timing leak was discovered in this algorithm.
This was called a Dragonblood attack.
However,
against EAP-pwd this timing leak was fairly small.
And it did not appear possible
to combine multiple timing measurements
in a more powerful attack.
So in other words,
it seemed almost impossible
to exploit this timing leak
at least against EAP-pwd.
However,
by using the timeless timing attack,
we are able to attack the EAP-pwd protocol.
And how does this work?
Well,
the adversary will spoof three clients
shown here on the right.
And
first, the first two clients
will associate to the access point.
The access point will request the identity of the client.
The client will reply with their identity
and send the identity through the FreeRADIUS server,
and then the FreeRADIUS server
will tell these clients,
okay,
I recognize you,
and both of you now have to perform
the EAP-pwd authentication algorithm.
Now up to this point,
nothing special happened.
Instead,
the attack only starts now.
And in the first part of the attack,
the third client
will send a special authentication frame
to the access point.
And the access point
will forward this authentication frame
over the TLS tunnel.
So over the RadSec connection
to the FreeRADIUS server
and this will cause the buffer of the access point
to slowly fill up with RadSec frames,
and as a result,
when Client 1 and 2
now sends their EAP-pwd authentication response,
then because the access point
already has some frames in its buffer,
these two frames will be combined into one TLS record.
Before I explain that in more detail,
I want to highlight that
the server here will send both
these EAP-pwd authentication responses
in a single physical Wi-Fi frame,
and this single physical Wi-Fi frame
is called an A-MPDU frame.
This means that these two authentication responses
will arrive at exactly the same time
at the access point,
and because the buffer at the access point
is slowly starting to get full,
the access point will combine
both authentication requests in a single TLS record
that is sent to the FreeRADIUS server.
The FreeRADIUS server will then process
both authentication
requests simultaneously
and parallel,
and it will reply
using whichever requests finished first,
and then it will reply
using the other request that finished processing second.
So here,
the request of the first client
finished first at the server.
So the server also sends it's reply first,
and then the reply of the second client is sent.
And we can see that this order
is also reflected
at the adversary site.
Namely,
the adversary will first receive
the reply of the Client 1,
and then it was received the reply
for Client 2.
And the order of these replies
allows an adversary to bruteforce
the password of the victim.
And in this case,
the probability of them
successfully bruteforcing the password of the client
is higher than 99%,
or to put it differently,
the response order correctly reflects
the execution time at the FreeRADIUS servers
in 99% of the time.
So only in less than 1% of the cases
does the response order
incorrectly reflect the execution time at the server.
And we can use this information
to then perform a off-line dictionary attack
against the password.
So for instances,
if we take the RockYou password dump,
which contains about 140 million passwords,
then we need to perform 40 measurements,
and with those 40 measurements
we have an 86% success probability
of correctly recovering the password.
At least if the password
is inside this password dump.
And this bruteforce search costs about $1 on,
for instance,
an Amazon cloud server.
So as a quick recap,
we now explained direct timing attacks.
We explained cross-site timing attacks,
and we explained timeless timing attacks
over Wi-Fi authentication.
And with that,
I hand the word back over to Tom.
- All right.
And that brings us to the demonstration.
So for this demonstration,
I created
an application called The Vault,
which is basically a place
where people can securely share
their text documents with military grade protection.
So users can enter the title of the document
and then select
the required security level of the other users.
It's required to access the document.
So it ranges from one,
which is for public documents,
up until five,
which is for really top secret documents
then the user can enter their content
and finally post the document.
Another functionality provided by The Vault
is the search functionality
where we can search for strings like "hi",
and then get a bunch of results.
We can also look for other strings,
like for instance,
"Vegas".
And then we can see
that there's this one single result,
or we can try some more secretive
things like the string "DEFCON",
but unfortunately,
we don't find any documents
containing that string.
Well,
I did create
this application.
So I know that there's at least one document
with the string "DEFCON",
but the reason why we're not shown
this document is because
we don't have the right security level.
In this demonstration,
what we will try to do is leak
the password,
that is in the same document
as the one that contains
the string "DEFCON".
And in order to do so,
we will be using these timeless timing attacks.
But before I go into the details there
of how the attack works,
I'll first explain
how the search functionality works.
Basically,
what we do is we do a textual search
on the contents of all the documents
using the query provided by the user.
And then if there's at least one document,
we need to be able to tell
whether the current user,
their security level is
high enough to view
one of the documents.
So getting the security level
is done by launching
a simple SQL query
on the database that's located
on the same server as the web server.
So that the timing
or the latency there is very minimal,
but still,
this is where the timing leak is
because if there are no documents,
which means that there's no match for the text,
we don't have to launch this SQL query.
So this means that
if there's at least one document,
the timing will take slightly
a few microseconds longer.
This is what we leverage in our attack.
So we use PYTHON here,
and we are using the H2
H2 time library,
which is the one
that we also use in our research.
It's made public
and I'll be sharing the link
later on in the presentation.
So what we do is
we define the URL prefix,
so we know that the actual password
is prefixed by DEFCON_PASSWORD=.
And then we guess
the current character one by one.
If the guess is incorrect,
we don't get shown any,
there will be no documents
matching the text search.
So this SQL query will not be executed.
And then we compare this to
the baseline request
where we use a character
that's not part of the character set.
So we know that
it will never have any matching documents.
And then we run
this with the H2 time library and we get
the response order
for 15 request pairs.
Basically,
we determine how many
negative results there are.
Negative means that the order
in which the response arrived was reversed.
So if we get
for
the response of r2
before the response of r1,
the order is reversed,
because r1 is sent before r2
typically,
or the request is sent before,
but then the response
is received in a different order.
And then
we determine the percentage of
how many responses were received in reverse order.
And then see if this
is above or below a certain threshold.
And in this case,
the threshold was set to 80%.
Okay?
So I think now
we are ready to actually run the attack,
which is done using just PYTHON.
(suspenseful techno music)
And we will be guessing the
passwords character by character.
So on the top most line,
we can see
all the characters that have been found so far.
So we are at T and 1.
Now we're also guessing,
or correctly guessed the letter m.
Everything here is being shown in real time,
of course,
to make the demo a bit shorter,
not the entire character set is used,
but we just use some
random guesses,
but as you can see,
so far,
it's going pretty well.
On the bottom line
we show
for each character that's being guessed,
the percentage of the responses
that arrived in the reverse order
and
for the characters that were guessed incorrectly
the percentage is
somewhat close to 50%
because there's a 50/50% chance
for every request that's being sent
that it will
arrive before or after
(techno music)
the other request.
So whether the response order is the same or different,
the chance is around 50%.
Of course,
there's still a bit of randomness.
So that's why it's not always 50,
but it's sometimes 40 sometimes 60.
And
I believe that we're
already getting quite close to
extracting the passwords.
And yeah, there it is.
So we've managed to
in just under two minutes,
find that the password is TimeLessTiming.
Of course,
in a real world scenario,
it would take a bit longer
because we would have to
guess all the characters one by one,
but still,
I think it shows that the tech works very,
very well.
All right.
And that brings us to the conclusion.
So we find that these timeless timing attacks
are not affected by network jitter at all,
neither on the upstream,
nor the downstream.
This allows the attacker to perform
these remote timing attacks
with an accuracy that is similar to
as if the attack
was launched against a local system.
And in order to do so,
we need to ensure that both requests are,
they arrive at the same time at the server,
in order do so,
the attacker can leverage multiplexing,
or if that's not available,
it might still be available
to leverage
a transport protocol
that enables encapsulation of the requests.
We also find that all the protocols
that meet these criteria
may be susceptible to timeless timing attacks.
And we already,
in our research we created practical attacks
against HTTP/2
and EAP-pwd
for Wi-Fi authentication.
Okay.
So with that,
I would like to thank you
for listening to the presentation.
If you have any additional questions,
or remarks, or ideas,
don't hesitate to reach out to us on Twitter.
And then finally,
you can find this,
H2 time
library that we used in our research,
but also in the demo,
in the following link.
And then on the right-hand side,
you can find the sources,
or the source code of the demonstration,
so you can play around with it as well.
Okay.
Thank you.