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.
July 25th, 2007 at 6:20 pm
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.
July 25th, 2007 at 6:50 pm
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.
July 25th, 2007 at 7:02 pm
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.
July 25th, 2007 at 9:08 pm
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
July 25th, 2007 at 10:40 pm
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
July 25th, 2007 at 10:56 pm
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.
July 26th, 2007 at 12:08 am
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
July 26th, 2007 at 12:33 am
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?
July 26th, 2007 at 12:49 am
wow David, your time is so much faster..
July 26th, 2007 at 2:16 am
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.
July 26th, 2007 at 6:21 am
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.
July 26th, 2007 at 8:52 am
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.
July 26th, 2007 at 9:12 am
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.
July 27th, 2007 at 7:22 pm
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)