Friday, December 11, 2009

Cross-domain search timing

I've been meaning to fiddle around with timing attacks for a while. I've had various discussions in the past about the significance of login determination attacks (including ones I found myself) and my usual response would be "it's all moot -- the attacker could just use a timing attack". Finally, here's some ammo to support that position. And -- actual cross-domain data theft using just a timing attack, as a bonus.

Unfortunately, this is another case of the web being built upon broken specifications and protocols. There's nothing to stop domain referencing resources on and timing how long the server takes to respond. For a GET request, a good bet is the <img> tag plus the onerror() / onload() events. For a POST request, you can direct the post to an <iframe> element and monitor the onload() event.

Why should an evil domain be able to read timing information from any other domain? Messy. Actually, it's even worse than that. Even if the core web model didn't fire the relevant event handles for cross-domain loads, there would still be trouble. The attacker is at liberty to monitor the performance of a bunch of busy-loops in Javascript. The attacker then frames or opens a new window for the HTML page they are interested in. When performance drops, the server likely responded. When performance goes up again, the client likely finished rendering. That's two events and actually a leak of more information that the pure-event case.

Moving on to something real. The most usable primitive that this gives the attacker is a 1-bit leak of information. i.e. was the request relatively fast or relatively slow? I have a little demo:

It takes a few seconds, but if I'm not logged into Yahoo! Mail, I see:

DONE! 7 79 76 82

From the relatively flat timings of the last three timings (three different inbox searches) and the relative latency between the first number and the latter three, it's pretty clear I'm not logged in to Yahoo! Mail.

If I'm logged in, I see:

DONE! 10 366 414 539

This is where things get interesting. I am clearly logged in because of the significant server latency inherent in a text search within the inbox. But better still, the last three numbers represent searches for the words nosuchterm1234, sensitive and the. Even with a near-empty inbox, the server has at least a 40ms difference in minimum latency between a query for a word not in the index, and a query for a word in the index. (I mailed myself with sensitive in the subject to make a clear point).

There are many places to go from here. We have a primitive which can be used to ask cross-domain YES/NO questions about a victim's inbox. Depending on the power of the search we are abusing, we can ask all sorts of questions. e.g. "Has the victim ever mailed X?", "If so, within the past day?", "Does the word earnings appear in the last week?", "What about the phrase 'earnings sharply down'?" etc. etc. By asking the right YES/NO questions in the right order, you could reconstruct sentences.

It's important to note this is not a failing in any particular site. A particular site can be following current best practices and still be bitten by this. Fundamentally, many search operations on web sites are non-state-changing GETs or POSTSs and therefore do not need XSRF protection. The solution, of course, is to add it (and do the check before doing any work on the server like walking indexes)!

With thanks to Michal Zalewski for interesting debate and Christoph Kern for pointing out this ACM paper, which I haven't read but from the abstract it sounds like it covers some less serious angles of the same base attack.


mh said...

Hi Chris.. You can also check out "Its all about the timing", our vegas 2007 presentation:

There is video online too, but the paper should cover *

Unknown said...

actually, you can also do something like < link rel=stylesheet src= >
< div class=cleafix > you are logged in on google < /div >

timing is too messy, CSS is cooler! :) works on ie/chrome/firefox/etc..

Unknown said...


Chris Evans said...

@sdc: I like the simple elegance of your example!
It looks like my more complicated MySpace example:
Since both seem to rely on loading non-CSS content cross-domain, note that this can and will be fixed in the browsers.
In the case where valid CSS changes (or appears) upon authentication, not really much can be done though :-/

Chris Evans said...

@sdc: re: your PoC and my comment "Since both seem to rely on loading non-CSS content cross-domain, note that this can and will be fixed in the browsers." - see :D

Anonymous said...

@sdc Your example doesn't seem to work in Opera.

Anonymous said...

Cool heart, and shot on the mercy Dragonica Gold of, Ling Po crazy way to EVE Isk kill, he began to love the taste of blood, like to see these cowardly FFXI GIL monsters in front of him like the poor, like the thrill of the muscles across the Bing Ren ... ...

He entered the 49th floor, the Lineage 2 Adena iron front of the room was familiar. The middle of the Last Chaos Gold room there is an old man sitting there, is close their eyes meditatively. It Knight Online Gold seemed that the advent of Ivy Ling Po do not know.

Ivy Ling Po stood there quietly, he Flyff Penya has felt the old man out of a strong body radiates a gas, he stared at the old man: "When I first arrived someone asked EQ2 Gold me to defeat the forty-nine-story monster, now left This last layer of the, no one thought was a powerful human masters, could I then, he 2Moons Dil takes a fight? "Ivy Ling Po Zi Cun," Although I experienced 48 times the fighting, but also learn many new moves can be With my present strength, but also far behind him, it appears was a World War II had.

Unknown said...

oh this new way for security my site.
My site have just down for DDOs.
I will reviewed code again.

Unknown said...

How can i add my phone number to my facebookaccount