As long as it is a real attack nobody cares about my opinion - it is a vulnerability. But I recently realized all timing attack scripts I saw in the blog posts can be a little bit more efficient.
I have no idea if this is a known tactic, but if it is why don't we use it every time we write about Frightful Timing Attack?
Given, somewhere on the server side there's hash == params[:hash] comparison and hash is e.g. 123234.
Strategy we see most of the time:
Probe 000000 N times
Probe 100000 N times
Probe 200000 N times
Probe 300000 N times
Probe 900000 N times
The idea is to go deeper.
Tree #1, N=100 checks
Tree #2, N=100 checks
As you can see the second tree will have not just usual +N operations, but extra +N/A for all 12***** and +N/A^2 for 123***, where A is Alphabet length (10 for 0-9 digits, 16 for 0-9a-f).
In our example we will have 211 operations in the tree starting with "1" and regular 100 operations in others, making it 11% easier to distinguish which pattern is the right one. We can go even deeper and never probe the pattern we checked before but it looks like only first two chars have a significant impact on performance, next N/A^3 and N/A^4 will not make it much better: 11.11...%
The other perk of this technique is when you are starting to probe next character you don't need to repeat the job you've done already (probing 10*000, 11*000, 12*000, and others ending with 000), which makes your job 1/A easier (10% less requests).
For hexadecimal values A=16 successful tree is 6.66..% easier to detect and attack is 6.25% faster.
I believe there are better timing tricks, will appreciate if you can share a link!
Because we hash passwords. Therefore there is no way this timing attack would work.ReplyDelete
That's not entirely true, https://github.com/aj-code/TimingIntrusionTool5000Delete
It works if you know the hash algorithm and parameters used.ReplyDelete
Say for example a password that hashes to "a..." is consistently slower than one that hashes to "b..." or "c...", then I know that the hash likely starts with a. Continue this untill you can just brute-force all the possibilities.
Not if they're salted tooReplyDelete
HAS NOTHING TO DO WITH PASSWORDSReplyDelete
Interesting, I'm sure it's possible to build in some simple heuristics to determine the ideal number of bytes to brute-force at a time, and change it dynamically based on a number of things.ReplyDelete
As an aside, I have /no/ clue what the other retards on this thread are commenting about.
they think "hash" i used in the post is password hash. But here hash means an api_key.Delete
This attack can only improve working vectors. Web apps timing is not working and 11% improvement of 0 is still 0. But binary / local exploits can really get faster