Timing attacks are an interesting part of computer security.
As an extreme example, imagine that your computer took one second to verify each character in your login password.
And now imagine that it stopped checking at the first wrong character, for reasons of efficiency.
You could quickly figure out the right password by timing how long it took for an error to appear:
AAAAA - 1 second (the very first A was wrong)
BAAAA - 1 second
CAAAA - 2 seconds (C was right, A was wrong)
CBAAA - 2 seconds
CCAAA - 2 seconds
CDAAA - 3 seconds (C right, D right, A wrong)
...
Instead of having to try all 26x26x…shy;x26x26 letter combinations, your worst-case attack needs just 26+26+…++26+26 attempts.
The safe approach is to abandon efficiency and go for consistency: always check all the characters in the password, and report an error unless they are all correct.
A real world example: the Lucky 13 attack against secure HTTP, if you remember that one, relied on the fact that the HMAC-SHA1 checksumming algorithm takes 25% longer to checksum 56 bytes of data than to checksum 55 bytes.
Usually, that doesn’t matter, because data is checksummed in blocks, and the more blocks there are, the longer it’s supposed to take.
But in Lucky 13, the cryptanalysts were able to use the timing cutover at 55/56 bytes to make inferences about how the data was organised, which violates the principle that encrypted data packets aren’t supposed to leak any hints about what’s inside.
A web history timing attack
Here’s another example, from Yahoo! security researcher Yan Zhu.
→ She’s very keen about being called a “crypto witch,” which is a moniker we find surprisingly unscientific for a field as rigorous as cryptography, but it’s her call.
Many sites these days – Naked Security included – use a security feature called HTTP Strict Transport Security (HSTS), which is a way for a security-conscious server to tell your browser to use to HTTPS for future visits to the site.
The problem is that whenever your browser is configured to connect differently to different websites, there’s a chance for crooks to exploit those differences to make educated guesses about your digital life.
Indeed, the HSTS documentation warns of these risks, in a theoretical way:
[HSTS] information can be retrieved by other hosts through cleverly constructed and loaded web resources,causing the [browser] to send queries to (variations of) the encoded domain names. Such queries can reveal whether [you] had previously visited the original HSTS Host (and subdomains).
HSTS as a “supercookie
Zhu set out to find a way to use HSTS to leak information about where you’d been.
Her idea was to look for timing differences between the very first time you visit an HSTS site (before your browser knows that it should use HTTPS) and any subsequent visits.
She wondering if this might act like a sort of “supercookie” that would detect whether you’d used the site before.
What she did was create a web server to generated web pages that:
- Tell your browser to load images from a list of target sites using HTTP.
- Tell your browser to prevent images from loading via HTTPS, using HTTP headers that implement a feature called Content Security Policy (CSP).
- Set a JavaScript function called an onerror handler to monitor whenever an HTTPS image was blocked.
So when your browser tries to fetch an image from, say,https://example.org/, under the instructions of Yan Zhu’s site, this is what is supposed to happen.
Case A. If you have never been to the site before:
- Your browser connects to the HTTP image link first.
- The server redirects the request to the equivalent HTTPS image link.
- Your browser blocks the redirect because of the CSP setting saying “No HTTPS images.”
- Your browser calls the JavaScript onerror function, which records the exact time.
Case B. If you have been to the site before, under your own steam, the server will have used HSTS to tell your browser not to bother with HTTP at all next time.
So you get this:
- Your browser rewrites the HTTP image link to HTTPS, based on its locally-stored HSTS list.
- Your browser blocks the connection because of the CSP setting saying “No HTTPS images.”
- Your browser calls the JavaScript onerror function, which records the exact time.
Zhu’s theory was that Case A would be detectably slower than Case B.
Case A involves one network connection, albeit a short and quick one that returns an HTTP redirect instruction, while Case B doesn’t use the network at all.
The trick worked with varying degrees of inaccuracy in practice, but it did work at least in part.
Therefore your browser could give out some of your browsing history, thanks to HSTS!
Source:nakedsecurity.sophos.com
Information security specialist, currently working as risk infrastructure specialist & investigator.
15 years of experience in risk and control process, security audit support, business continuity design and support, workgroup management and information security standards.
