Researchers exploit HTTP/2, WPA3 protocols to stage ‘timeless timing’ attacks | Hacker News Reader

Researchers exploit HTTP/2, WPA3 protocols to stage ‘timeless timing’ attacks

portswigger.net

241 pointswglb26 comments

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.

> “[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.

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.

Why does having a way to measure computation time at the server open up a whole range of attacks? I’m ignorant on the topic.

If the webapp compares hmac digests, for instance, with something like (a == b), the comparison is short-circuited the sooner it hits an unmatched byte (the more left-ward). So, an attacker can go byte by byte left to right. There's a lot of noise over HTTP/1.1, but these attacks are at least theoretically possible over the wire.

If you can do it without noise and with 10s of microseconds of resolution, your attack just got much more efficient. And it probably opens the door to timing things more crazy then simple equality.

If your crypto code doesn't use constant time functions for timing attack sensitive stuff (like digest comparisons) then you have more serious problems already. Relying on HTTP or other noise is not a good idea.

Right, the question being answered above was "what is a timing attack."

Well, lots of web apps don't use constant time comparisons when checking $password == $actualPassword. Whether there exists enough timing difference to do something with that is very unclear even in ideal conditions

If they're hashing the password, then the actual password should be already hashed in the DB, and even if the hash comparison is not constant-time, the avalanche effect should make it difficult to "safe-crack" the password one character at a time, because each change in the password will change half the hashed bits.

Passwords are a bad example, but think of a simple signed cookie for example.

It's signed with a key that is only known to the server, and the cookie is sent as signature + content.

The server has to hash the content using the key, and then validate the signature matches the signature the server just created.

If you don't use constant time comparison for this you leak information about the valid signature.

Generally true, but digest comparisons are a bad example. If you are hashing inputs on the server side, you can not determine a suitable pre-image through a timing attack without cracking the hash function.

Timing attacks are a problem when the server is checking a value the attacker can control bit-by-bit. Hashed values do not meet this requirement.

It still helps though, let's assume they're using MD5 without salt, if the attacker has a rainbow table, this leads to a speed up, since the attacker only has guess bit-by-bit instead of trying every possibility.

Right, what you've got is an oracle that will tell you how many prefix bits of MD5(password) were correct. I suspect bytes is more realistic than bits but the same principle.

Rainbow tables don't seem like a very applicable technology for this. I think you'd want to pre-process a dictionary of passwords you want to be able to guess (either from known passwords or just obeying some rule) so that you can group and order them by MD5 prefix.

Using the oracle lets you narrow down 50% at a time, so if you've got a dictionary of 1 billion passwords, after 30 iterations you've either rejected all the possibilities or found a correct password.

NB This makes no difference against a strong random password, since a hypothetical dictionary of such passwords is far too large, it only impacts ordinary human passwords that you could brute force if you had the hash.

What you’re talking about is more like a hash table not a rainbow table. If you’re looking for a pre-image for the first 8 bytes of MD5 that would be a table with 2^64 rows * at least 8 bytes or at least 144 exabytes of data.

Using such a table would allow you to select guesses that matched the first n bits of the stored hash and then use timing to try to guess the right choice for the n+1’th bit... up to the first 64 bits. You would then have limited the number of guesses down to just another 2^64 possibilities. So that’s not really a valid approach.

A different approach would be to try to figure out the first ~32 bits of the hash using a much smaller (34GB) table and use that knowledge to screen potential candidate passwords offline.

Again, all this works only as long as there isn’t a salt, and the value you are trying to discover is a guessable password and not a randomly generated key.

https://en.m.wikipedia.org/wiki/Timing_attack

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?

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.

Reply on news.ycombinator.com