 Hello, I am Mati van Hoef and together with Tom van Goetheem, we will be presenting Timeless Timing Attacks. Tom van Goetheem is a researcher at the Disturnet Group in KU Leuven in Belgium. He's a phonetic 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 Mati van Hoef, 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 and network security and software security and also a bit in Applied Crypto. And previously, I discovered Crack Attack against WPA2 on the RC4 Nomore attack. And in this presentation, we'll be talking about timing attacks on timing leaks. So let me start with some examples of timing leaks. The top left corner we can see is straightforward timing leak where the pending 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. On the for loop is terminated once an element is found with a certain secret condition. On 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 keyword and then this code would leak whether this keyword is present in a secret document or not. Now 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, on the adversary knows that the secret condition evaluates to false, on the adversary will use that as a baseline, on 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 on the target request, we will be using statistical tests to determine whether there really is a significant difference or not. Now 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, on 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 5 microseconds. Finally, the last important factor is the number of measurements that an 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 Mati. 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. Responses generated and sent back to the attacker. The attacker will then measure how long it took between sending and 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. And 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. So we did some measurements to see how many requests the attacker would actually require. So 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. So 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. So to detect a timing difference of 50 microseconds with a server in the EU, 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 US, more requests were required. So in this case, for 50 microseconds, well over 4,000 requests were required to detect this difference. And also see that as the timing difference became smaller, also the attacker required more measurements. So for 20 microseconds it was close to 3,000 requests that were needed for the server in the EU, growing to 23,000 for 10 microseconds. And for a timing difference of 5 microseconds, we found that it was not possible to do this with a maximum set to 100,000 requests. So we were thinking like how can we improve this remote timing index? And that's how we came to the Timeless Timing Index. So 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. So then we thought okay then maybe let's get rid of the notion of time and that's why we call this attack Timeless. So instead of relying on this sequential timing measurements, we can try to exploit concurrency and only consider the order of the responses. So we don't use any absolute timing measurements anymore in these timing 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. So again we have our attacker and 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. So these two requests arrive simultaneously at the server and are processed concurrently and because the light pink request 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 this request required less processing time. So 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 side. And again we see the same result. Thank you Tom. So what are the requirements of a Timeless Timing Attack? Well first and for 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. So let's explore these three requirements in more detail. So 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. Along with multiplexing, our example is the HTTP2 protocol and this is because with the HTTP2 protocol, two requests can be sent simultaneously over the same connection. In fact, a single TCP packet can carry multiple HTTP2 requests that will be processed concurrently once they arrive at the server. For encapsulation, there our example is the HTTP1 protocol because the HTTP1 protocol on its own does not allow you to send two requests in parallel. However, when we exploit HTTP1 over Tor or over VPN, then we can send two HTTP requests at the same time over Tor or over the VPN network. So let me illustrate these two cases graphically. So for multiplexing, we have the HTTP2 example where here on top you can see the two HTTP2 requests in gray. And the adversary will assure that these two HTTP2 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 HTTP1 example where here again at the bottom, we have two HTTP1 requests shown in gray. These two HTTP1 requests are sent in different TCP connections, meaning they are also encapsulated in two different TCP packets shown in red here, and each TCP packet is then encapsulated in a different Tor cell. And 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 onion servers that we are targeting, then the onion 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 request finished processing first. On 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 experiments, we notice that these two responses generally follow the same network path, 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 fields such as the TCP sequence numbers or the TCP timestamps to recover the order in which the server sent both responses. So 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 land on 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 request pairs. What important here is that the timing leak can then be exploited no matter where the adversary is located on the internet. This is in contrast to traditional timing attacks because with traditional timing attacks, we were not able to exploit the 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 the 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 land or local host. And in fact, over the internet, a traditional timing attack at best could exploit a timing leak of 50 microseconds. This really shows that timeless timing attacks are in order of a magnitude more powerful than traditional timing attacks. So that covers how direct timing attacks work. It's also possible to perform timeless timing attacks in a cross-site setting on to perform timeless timing attacks against Wi-Fi authentication. Anton will now elaborate on the cross-site timing attack scenario. So these cross-site timing attacks, they are 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. And 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 JavaScript, they will include the cookies. So this means that the server will process the request using the victim's authentication. And once the 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 promise results first. And this might leak sensitive information that the victim has shared with the website. So we actually applied this timing attack. This cross-site timing attack to the search functionality in Hacker 1, where we were able to leak information about private undisclosed reports. So one of the key differences is that with direct timing attacks is that here the attacker does not have direct control over the network. This is because the browser can choose how to send a request 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. So this mechanism will prevent the client from sending a very large number of packets at once. And instead, the client will need to wait for an acknowledgement from the server before more packets can be sent. So once as soon as the client is waiting for acknowledgement from the server, any other requests that are made, their data will be stored in the queue and they will be merged together into a single packet. So the attack looks fairly simple. So first we make a post request 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, so let's see how this works in practice then. So here we show the victim's packet queue, the TCP packets that are being queued to be sent to the server. So 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. So here every square represents a single TCP packet. So 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 the third line of code will be the attacker sending the request for the target URL represented as the target pink. So 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 acknowledgement 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 time index. So in this presentation we already discussed the direct time index, where the attacker connects directly to the server. Then what I was just talking about are the cross-site time index. And then now Mati will be talking about a third attack scenario where we use timeless time index to break Wi-Fi authentication. So it is also possible to perform timeless timing index 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. So 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 instead to authenticate a user using a username on password. And when using these enterprise authentication protocols the authentication happens between the client on the authentication server. And here the authentication server is commonly a free-radius server on the access point will simply forward messages between the client on the authentication server. Because the authentication server can be located anywhere on the internet the communication between the access point on the authentication server is typically protected using a TLS tunnel on this TLS tunnel is called a Rotsack 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 dragon blood 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 to the free-radius server and then the free-radius server will tell these clients okay I recognize you on 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. On the access point will forward this authentication frame over the TLS tunnel so over the RADSEC connection to the free-radius server. On 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 send 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. On the single physical Wi-Fi frame is called an AMPDU frame. This means that these two authentication responses will arrive at exactly the same time at the access point on 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 free-radius server. The free-radius server will then process both authentication requests simultaneously and parallel and it will reply using whichever request 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 its 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 side namely the adversary will first receive the reply of the client one and then it will receive the reply for client two and the order of these replies allows an adversary to brute force the password of the victim and in this case the probability of then successfully brute forcing the password of the client is higher than 99% or to put that differently the response order correctly reflects the execution time at the free-radius 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 an offline dictionary attack against the password. So for instance if we take the rock you password dump which contains about 140 million passwords then we need to perform 40 measurements and with those 40 measurements we have 86% success probability of correctly recovering the password at least if the password is inside this password done. On this brute force search costs about $1 on for instance on 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. Alright 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 that is 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. And the user can enter the content and finally post the document. Another functionality provided by the vault is the search functionality where we can search for strings like high 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 is 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 is 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. So 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 how the attack works I'll first explain how the search functionality works. So 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 where the current user, well 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 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 well 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 like a few microseconds longer. And this is what we leverage in our attack. So we use Python here and we're using the H2 time library which is the one that we also used in our research. And 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 underscore password equals. And then we guess the current character one by one. So if the guess is incorrect we don't get shown any, well 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. So 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. And we will be guessing the passwords character by character. So on the topmost line you can see all the characters that have been found so far. So we are at T and 1. Now we are also guessing or correctly guessed the letter M. So 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. So 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 well there's a 50-50% chance for every request that's being sent that it will arrive before or after 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 password and yeah there it is. So we managed to in well just under 2 minutes find that the password is timeless timing. 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 deck works very well. Alright and that brings us to the conclusion. So we find that these timeless timing tags are not affected by network jitter at all neither on the upstream nor the downstream. So this allows the attacker to perform these remote timing tags with an accuracy that is similar to as if the attack was launched against the local system. In order to do so we need to ensure that both requests are well they arrive at the same time at the server so in order to 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. And we also find that all the protocols that meet these criteria may be susceptible to timeless time index and we already in our research we created practical attacks against HP2 and EAPWD 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 issue 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.