Cenzic 232 Patent
Paid Advertising
web application security lab

Res Timing Attack

David Byrne sent over an interesting proof of concept to use the same res:// attack I talked about that Billy Rios found the other day, but he put an interesting spin on it. The amount of CPU cycles (timing) it takes for the process to run depending on if the file is there or not are pretty significantly different. Click here to see the demo.

I’m not sure if this provides additional value over the original res:// attack, but certainly it shows that timing attacks are really very possible for this. The results on my machine were dramatic (over double the time for existing verses non-existing files). Your mileage may vary. Cool trick, nonetheless.

14 Responses to “Res Timing Attack”

  1. Awesome AnDrEw Says:

    My average response for a failed file was around 1600 ms where as files that actually existed produced a result within 2400 ms. I’m not quite sure how it’d be any more beneficial than the original, but it is interesting.

  2. David Byrne Says:

    The main advantage that it can be done on any type of file, for example: c:\windows\system32\eula.txt. My understanding (it could easily be wrong) is that the first method will only work with a file containing mapped resources.

    For slower computers, the current loop setting is overkill. I got consistent results when an existing file returned in about 500ms.

  3. David Byrne Says:

    The method can work for smaller files, but the time threshold would need to be tweaked. Windows formated executables (.exe, .dll, etc. probably .ocx) seem to respond faster than a similarly sized text file, but that could be taken into consideration.

  4. hackathology Says:

    My results are as below:

    c:\windows\system32\telnet.exe - 437

    c:\windows\system32\msimsg.dll - 438

    c:\windows\system32\xcopy.exe - 437

    c:\windows\system32\wuauserv.dll - 360

    c:\windows\system32\asdf.dll - 344

    c:\windows\system32\1234.dll - 328

    c:\windows\system32\asdf.exe - 328

    c:\windows\system32\1234.dll - 250

    Average good time is 418ms
    Average bad time is 312.5ms

  5. Jethro Hemmann Says:

    For me it also doesn’t work… The times are quite the same…

    c:\windows\system32\telnet.exe - 63
    c:\windows\system32\msimsg.dll - 47
    c:\windows\system32\xcopy.exe - 63
    c:\windows\system32\wuauserv.dll - 78
    c:\windows\system32\asdf.dll - 47
    c:\windows\system32\1234.dll - 47
    c:\windows\system32\asdf.exe - 47
    c:\windows\system32\1234.dll - 46

    Average good time is 62.75ms
    Average bad time is 46.75ms

  6. David Says:

    Yeah, I’m not sure how accurate this can really be:

    Average good time is 21.75ms
    Average bad time is 17.75ms

    C:\1 appears to exist - 27ms
    C:\2 doesn’t appear to exist - 18ms
    C:\3 appears to exist - 21ms
    C:\4 doesn’t appear to exist - 18ms
    C:\5 doesn’t appear to exist - 19ms
    C:\6 appears to exist - 20ms

    Wouldn’t it also depend on how the hard drive is being hit at the time amongst other factors? Maybe it’s just because my good and bad times are pretty close, but I couldn’t replicate this with any accuracy.

  7. Vinicius K-Max Says:

    c:\windows\system32\telnet.exe - 1391

    c:\windows\system32\msimsg.dll - 1360

    c:\windows\system32\xcopy.exe - 1328

    c:\windows\system32\wuauserv.dll - 1390

    c:\windows\system32\asdf.dll - 1125

    c:\windows\system32\1234.dll - 1203

    c:\windows\system32\asdf.exe - 1062

    c:\windows\system32\1234.dll - 1016

    Average good time is 1367.25ms
    Average bad time is 1101.5ms

  8. anathema Says:

    Average good time is 50.75ms
    Average bad time is 78ms

    asdf.exe doesn’t appear to exist - 109ms
    notepad.exe doesn’t appear to exist - 109ms
    text.txt appears to exist - 47ms
    telnet.exe appears to exist - 47ms
    aaaa.aaa appears to exist - 31ms
    aaaaaaaaaaaaa.aaaaaaaaaaaaa appears to exist - 32ms
    asdf.exe appears to exist - 31ms

    Look at asdf.exe it gets first a negative hit which is correct and then a positive - would the request be cached by the browser giving a quicker reply the second request?. hence the positive?

  9. hackathology Says:

    wow David, your time is so much faster..

  10. Ronald van den Heetkamp Says:

    I’ve been playing with this as well before, but found out that the time differences in milliseconds where too great to be conclusive.

    It really has to be counted in seconds to be sure, milliseconds are just too small to determine network connectivity, anything could scramble it, network traffic, DNS location, and even your browser.

    You could do it in theory, but it would require a constant benchmark while scanning and adjusting.

  11. David Byrne Says:

    Anathema & David: Are you running it on Firefox or IE? It only works on IE. Low numbers like you described are usually associated with FF.

    Ronald: This is all on the local computer, so network latency won’t have an impact. CPU utilization will, but that is common to all timing attacks.

  12. Ronald van den Heetkamp Says:

    Uhm… let’s re-think this: network latency doesn’t matter?

    Since when does this not involve CPU cycles? everything I do costs CPU cycles. It all depends on what I run at that particular moment, so it’s too unstable to be certain. That’s why we all get very different results back. That’s why I said milliseconds are too small for exact analysis.

  13. Ronald van den Heetkamp Says:

    I tested a couple times in different settings, reloaded a couple of times but it’s way to uncertain, it ranges from 20ms to 700ms here with no obvious patern at all.

    Maybe it’s an idea to let every file run into a for loop 10 times until it reaches a certain horizon, because the stability of the browser is at stake also, just to be sure all browser assets are dealing with this script alone, think => denial of service which consumes all assets because of instability.

    It would be a cool trick if it’s stable though.

  14. Sergei Shelukhin Says:

    It constatnly makes mistakes here, with one HDD always getting “exists” for any file, and two others at about 50/50 rate (e.g. random hit I suppose)