
Researchers exploit HTTP/2, WPA3 protocols to stage ‘timeless timing’ attacks - wglb
https://portswigger.net/daily-swig/researchers-exploit-http-2-wpa3-protocols-to-stage-highly-efficient-timeless-timing-attacks
======
punnerud
Summary: “[For HTTP/2], we just need to make sure that both requests are
placed in a single packet (e.g. by writing both to the socket at once)“ And
then looking at the order of the packages when they get back.

Now you have a way to measure computation time at the server, that opens up a
whole range of attacks.

~~~
Matthias247
> “[For HTTP/2], we just need to make sure that both requests are placed in a
> single packet (e.g. by writing both to the socket at once)“ And then looking
> at the order of the packages when they get back.

It's not that simple however:

What most web servers will do do when getting HTTP/2 HEADERS frame is
initiating new "requests" and setting up associated request handlers. Those
are often a bunch heap allocated objects and callbacks, but you could also
have individual threads for each request. Those will then all be scheduled in
a more or less independent fashion. E.g. in a Go based webserver each request
which serves a HTTP/2 stream is still an independent Goroutine, which gets
scheduled indpendent from all other HTTP/2 streams.

Now even if all the request handler is doing a returning a static "hello
world" response, it would still not guaranteed that the response for request B
which was sent behind request A would immediatly follow response A - there
could still be other requests handled in between - or they could be handled in
reverse order. Chances of ordering being maintained are highest with a rather
primitive singlethreaded webserver.

The next thing is however that most webservers will perform some kind of
useful work which prevents them from responding immediately - they will wait
for an upstream webserver, database, or just for a filesystem operation to
complete. These will all introduce time variations that are rather high.

~~~
the8472
Timing attacks generally don't perform a single probe. You might have a
million tries to comb through the noise. What this does is reduce the noise
from the network, not from the server.

------
runeks
So, how much closer are we to an actual exploit with this attack?

> The main advantage of the timeless timing attacks is that these are much
> more accurate, so much fewer requests are needed.

How much fewer? And how close is this to what is achievable in practice?

~~~
robocat
They used it to exploit 2 known timing attacks that were not previously fixed
because they were thought infeasible to attack:

From article: In case of the HackerOne bug, it was already reported at least
three times (bug IDs #350432, #348168, and #4701), but was not fixed, as the
attack was considered infeasible to exploit. I then created a basic PoC with
the timeless timing attacks.

From article: Mathy Vanhoef, one of the co-authors of the paper, had
previously discovered a potential timing leak in WPA3’s handshake protocol.
But the timing was either too small to exploit on high-performance devices or
could not be exploited against servers. “With the new timeless timing attacks,
we show that it is in fact possible to exploit the WiFi authentication
handshake (EAP-pwd) against servers, even if they use performant hardware,”
Van Goethem says.

