A recent Defcon talk by Tom Van Goethem and Mathy Vanhoef, “Timeless Timing Attacks” made significant progress on ways to create timing attacks over a network. Timing attacks work by extracting data form devices based on how long it takes to respond. To successfully run a timing attack, the attacker usually must be directly connected to the computer since the smallest latency or jitter over a network can make the attack impossible. The talk discusses two ways to resolve jitter and latency in a network when performing a timing attack on a device.
To resolve network jitter issues the attacker can send two requests at the same time and find the relative timing between the packet responses. If the server processes these requests in parallel, then we can see what response returns faster in the reply packet, eliminating the need to measure latency over a network.
One way to do this involves using TCP congestion control. A malicious server can tell the client to wait for the ACK response before sending a reply, causing all requests to send at once. When unpacking the responses, we can examine the order to determine what request finished first. If one request consistently returns after and therefore slower than our baseline request, then we can extract passwords and data this way. They showed this used in a cross-site timing attack.
Another demonstration can extract Wi-Fi passwords using Dragonblood. Previously the timing for the Dragonblood exploit wouldn’t allow enough detail to find the correct password when using “eap-pwd”. However, if we can get the access point to send multiple requests to a Radius server at once then we can read the response order with a baseline request. By sending multiple “PWD-ids” requests containing possible passwords in a signal physical frame we know the access point will receive the frames at the same time. If we also make a re-authentication request to the access point, then the access point will buffer all requests and send them as a signal packet to the Radius server for processing. The server then responds to the access point where the PWD-id responses are forwarded back to the clients. By measuring the timing between the responses we know how long the Radius server took to process the request. Obviously, the AP still needs to process the response from the Radius server, but this doesn’t affect the timing that much.
We didn’t see any demonstration for the Wi-Fi attack, so we don’t know the practicality of the attack. As for cross-site timing attacks, the basic step by not allowing cross site scripting to occur would block this from happening.