13

Potential timing attacks are always brought up in one context or the other but I don't think I've ever read a case where someone has actually executed such an attack over the internet.

joseconte2018
  • 139
  • 3

3 Answers3

9

It might be tempting to assume that network latency (jitter) makes these attacks impractical. This is not the case because TCP timestamps are often used by the vulnerable machines, where the precise time the packet was generated is encoded into the TCP header. No matter how long it takes the traffic to arrive, the exact time it was created is still present. Even on systems with timestamps disabled, it is possible to get an accurate idea of the packet timing by repeating the test multiple times and averaging the result to account for network jitter. So, with that in mind...

Yes, timing attacks can be done over a network. The most prominent example was a long-lived vulnerability in OpenSSH that allowed trivial user enumeration. The issue was caused by the fact that an invalid user would trigger password comparison using Blowfish, the default. When a valid user was used, SHA-2 would be used instead. While normally the timing difference is minimal, sending a large password (several kilobytes) would cause the difference to be noticeable.

From the original bug disclosure:

When SSHD tries to authenticate a non-existing user, it will pick up a fake password structure hardcoded in the SSHD source code. On this hard coded password structure the password hash is based on BLOWFISH ($2) algorithm. If real users passwords are hashed using SHA256/SHA512, then sending large passwords (10KB) will result in shorter response time from the server for non-existing users.

Attacks against these types of bugs often exploit the fact that a different code path is taken depending on the input you provide, causing a significantly greater timing difference than is typically seen with low-level architectural timing attacks where the differences are measured in nanoseconds and come from instructions not executing in constant time (flush+flush, etc).

forest
  • 64,616
  • 20
  • 206
  • 257
1

Yes, of course, because one of those attacks is Spectre! The attack against the CPU cache timing is known for its potential of being carried out with Javascript, revealing critical user data, stored in a browser, to an arbitrary Web site.

(By the way, this illustrates the idea: remote timing attacks might sometimes be viewed as something almost harmless, but they might play a role of a solid ground for more sophisticated attacks, build on top of other vulnerabilities and too hard to be tracked down. E.g. if at some point there will be even an apparently harmless clientside vulnerability, a timing attack may easily evolve into a severe problem.)

The reason timing attacks were always believed to be infeasible over the Internet was, basically, the round-trip time which adds a considerable margin of error, which in turn is assumed to make timing issues very obscure to a remote party. However, generally, RTT is something which, in most cases, given a good connectivity both on the victim's side and on the attacker's side (which is something too easy to achieve), statistically, is stable enough. Timing issues are also stable for that matter.

If an attacker is able to do a lot of attempts to collect enough data to do statistic measurements, they can generally make an adjustment for RTT, effectively removing this vague obfuscation of the execution time measurements. Here's another practical example of how it can be done.

Timing issues are not something to underestimate.

ximaera
  • 3,395
  • 8
  • 23
  • 3
    I'd argue that this doesn't count as a *remote* timing attack because it's just local JS that may be fetched from remote once. – Arminius Apr 15 '18 at 22:53
  • @Arminius well, if I wanted to be picky about it, I'd say that, e.g., *remote* code execution basically ends up in something being fetched from a remote entity once and then executed. In case of Spectre/JS, the attacker is clearly a *remote* entity, and, anyway, here, an attacker doesn't need to have a local account to exploit the vulnerability. But one thing is true: the difference between "local" and "remote" isn't *discrete* anymore. And -- as something that can be used as a base to determine the severity of a vilnerability -- it becomes more and more subtle as time goes by. – ximaera Apr 15 '18 at 23:36
  • 4
    Well, I'd think OP's main point is what you rightly picked up in your answer yourself - whether high RTTs make timing attacks impractical. However, you gave an example where latency is irrelevant, which seems like a bit of a bypass. :-) – Arminius Apr 15 '18 at 23:48
  • 1
    @Arminius I've just discovered that I'm dumb enough not to read the question carefully. The question is explicitly phrased to be about the attacks "executed **over the Internet**". The discussion about Spectre being local or remote may last long, but, as a matter of fact, it definitely can be executed over the Internet ;-) Your comment about adjacent attacks is completely valid. – ximaera Apr 16 '18 at 00:17
  • 1
    Spectre is not executed over the internet and cannot be. Malicious code can be sent over the internet, but it will only ever be executed on the client. If a server-side language could exploit Spectre on a remote client without that client locally executing a client-side language, _then_ this would be correct. – forest Apr 16 '18 at 10:01
  • 1
    Come to think about it, you could make an argument that _any and all exploits involving execution are remote_, which would be plain silly. This answer is just misleading. – forest Apr 16 '18 at 11:29
  • @forest calling Spectre/JS a local vulnerability is equally misleading. Here's an example of a similar vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2017-5121 . Just as with Spectre, a remote client must locally execute a fetched JS code to be affected. And, note "AV:N" in the CVSS score. – ximaera Apr 17 '18 at 05:41
  • @forest no, I don't see how I can make such an argument. – ximaera Apr 17 '18 at 05:48
  • "Exploitable by a remote attacker" is quite different from timing attack exploitation over a network. This answer may be correct if you take a very liberal interpretation of OP's question, but to me at least it seemed to be specifically about timing attacks _over a network_, not timing attack exploits _sent_ over a network. – forest Apr 17 '18 at 08:51
  • @forest "AV:N" means "access vector: network" ;-) – ximaera Apr 17 '18 at 08:53
  • @forest and it's sort of clear for me that the question is mostly about risk assessment, i.e. are timing attacks really severe if they are hard to exploit "over the Internet". My answer is "yes, and here are *a number* of reasons how". – ximaera Apr 17 '18 at 08:56
  • I know what the CVSS score means. Like I said, exploitable by a remote attacker != exploitation over a network. If OP was only asking about the exploitation vector, then that makes sense, but the majority of the time I hear timing attack over a network discussed, it's about a timing attack _over_ a network, not exploit code which utilizes a timing attack sent over a network and executed locally. Additionally, all the comments to the OP seem to be excluding things like JS (otherwise it would make no sense to ask if LAN is in-scope). – forest Apr 17 '18 at 08:58
  • 1
    @forest okay, now that the author has two different views on the topic, he's able to choose. – ximaera Apr 17 '18 at 09:00
1

As the discussion on this question about a user enumeration threat based on a timing attack illustrates... timing vulnerabilities can crop up any time a different amount of work is needed to return a result, even if the rendered page is not designed to disclose the information that was used in processing the request.

The linked question refers specifically to a user enumeration vulnerability, but similar timing differences could happen in any authorization scheme that requires a resource to be fetched and permissions checked before it can be determined if the authenticated user has permission. It might be possible to discern, for example, if a user has a certain feature enabled on their account, because the authorization logic is more complex and takes longer to run.

The severity of such a vulnerability would depend entirely upon the sensitivity of the information that would be disclosed by the attack.

nbering
  • 3,988
  • 1
  • 21
  • 22
  • It seems user enumeration vulnerabilities are common with timing attacks. Your answer reminded me that OpenSSH recently had such a vulnerability! – forest Apr 16 '18 at 11:39