Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Computer's Heat May Unmask Anonymized PCs

Zonk posted more than 7 years ago | from the i-seee-you dept.

Privacy 146

Virtual_Raider writes "Wired is carrying a story about a method developed by security researchers to identify computers hiding behind anonymity services. From the article: 'His victim is the Onion Router, or "Tor" — a sophisticated privacy system that lets users surf the web anonymously. Tor encrypts a user's traffic, and bounces it through multiple servers, so the final destination doesn't know where it came from. Murdoch set up a Tor network at Cambridge to test his technique, which works like this: If an attacker wants to learn the IP address of a hidden server on the Tor network, he'll suddenly request something difficult or intensive from that server. The added load will cause it to warm up.'"

cancel ×

146 comments

Sorry! There are no comments related to the filter you selected.

I didn't RTFA, but... (-1, Redundant)

Atlantis-Rising (857278) | more than 7 years ago | (#17406940)

Um... doesn't that require him to have physical access to the server anyway?

And we all know that old maxim- if you have physical access, you have it all.

Re:I didn't RTFA, but... (5, Informative)

KshGoddess (454304) | more than 7 years ago | (#17406952)

the heat-up causes a shift in how much the clock drifts, and you can query time from different servers to pinpoint which one it is.

See what reading the article gets you? A tiny nugget of useless information.

Re:I didn't RTFA, but... (1)

gslavik (1015381) | more than 7 years ago | (#17406962)

but what if the router happens to be an overclocked gaming system and the user happens to have fired up Prey/Doom3/others for an intence gaming session?

Re:I didn't RTFA, but... (5, Informative)

qbwiz (87077) | more than 7 years ago | (#17406980)

You measure clock skew before, during, and after you hit the hidden service. If the change in clock skew happens at the same time you load the server, that indicates that it's probably the correct server.

Re:I didn't RTFA, but... (2, Informative)

Tweaker_Phreaker (310297) | more than 7 years ago | (#17407104)

Read what you just said. Skew is a distortion of measurement. In normal operation there is no distortion, only when the crystal is heated. So by definition there is only one possible value for the skew and it's the change from before to after the crystal has been heated.

Re:I didn't RTFA, but... (1)

qbwiz (87077) | more than 7 years ago | (#17407142)

Sure there's clock skew normally. I know that my computer doesn't have a caesium-133 atom inside of it. As such, the clock is inaccurate and bound to vary relative to the correct time. I have noticed that it has been up to a couple of minutes off. Right now, as I updated it from an NTP server, it was 4 seconds off. It has to become inaccurate to have that problem.

Re:I didn't RTFA, but... (2, Interesting)

Tweaker_Phreaker (310297) | more than 7 years ago | (#17407188)

Yes but that's not the skew he's measuring. He's only measuring the skew caused by heating the crystal.

And if I suddenly load a video file (1)

bruce_the_loon (856617) | more than 7 years ago | (#17407224)

My CPU temp would spike more than what he's doing to me. Or if I'm playing a game.

Packet-rewriting firewalls, here we come :)

Re:And if I suddenly load a video file (0)

Anonymous Coward | more than 7 years ago | (#17407320)

My CPU temp would spike more than what he's doing to me. Or if I'm playing a game.

Mine will usually go at least from 114F to 135F just while loading acrobat reader. Meanwhile the fan goes from low to medium to high. I could hear the difference in the next room if I launched myself out of the chair immediatly after double-clicking the filename.

Re:And if I suddenly load a video file (1, Offtopic)

Sorthum (123064) | more than 7 years ago | (#17410078)

Foxit reader has a crap-ton less overhead.

Re:I didn't RTFA, but... (1)

Tweaker_Phreaker (310297) | more than 7 years ago | (#17406974)

You left out the part about how his method only has 64 unique "fingerprints" and so this is utterly useless.

Re:I didn't RTFA, but... (1)

Sorthum (123064) | more than 7 years ago | (#17410098)

And you must have missed the part that it's not the timestamp he measures, but the change in timestamp over a period of time that correlates to what he has the remote server do. That's a lot more telling.

Fix it with NTP? (4, Interesting)

Kadin2048 (468275) | more than 7 years ago | (#17406992)

Not that I think this sort of thing is really going to become anything more than an interesting proof-of-concept anytime soon, but couldn't you combat this by having a local NTP server for your server farm, and then setting the servers to update from that server at frequent intervals (say every 5 sec or so)? It would waste cycles on the machines and generate some extra load on the network, but it would keep the clocks from ever drifting far, and it would narrow the window in which you'd be able to detect drift to something pretty small.

Re:Fix it with NTP? (1, Informative)

Anonymous Coward | more than 7 years ago | (#17407164)

couldn't you combat this by having a local NTP server for your server farm, and then setting the servers to update from that server at frequent intervals (say every 5 sec or so)? It would waste cycles on the machines and generate some extra load on the network, but it would keep the clocks from ever drifting far, and it would narrow the window in which you'd be able to detect drift to something pretty small.
Or try a simple hardware upgrade [walmart.com]

Re:Fix it with NTP? (1)

Cramer (69040) | more than 7 years ago | (#17407302)

One word: MULTICAST

Every computer on my network (several dozen) are sync'd every 5 seconds by a single packet. (ok, 3... one from each NTP server.) That includes windows machines too. (forget w32time and install ntpd)

Re:Fix it with NTP? (4, Insightful)

Splab (574204) | more than 7 years ago | (#17407546)

The article is very low on information on how he proposes to locate a computer. Yes clock skew would help, but you need to locate the machine somehow. And on top of that he thinks that more traffic equals higher load on the cpu. This isn't necessarily true, in a closed environment you might be able to do it, but on a global scale I can't see how this would help you unless you got global knowledge of the network, and if you do, sybil [google.com] attack is a lot easier to do.

One must remember TOR doesn't guarantee strong anonymity, for that you need something like Herbivore [cornell.edu] .

Re:Fix it with NTP? (1)

dgatwood (11270) | more than 7 years ago | (#17408878)

Exactly. This is kind of like the whole NP-Complete space. It's hard to find the right answer, but once you've found the right answer, it can be verified in polynomial time. Same thing here. It's a verification exploit, not a location exploit. It can, with a sufficiently large number of tests, verify that the host you think is providing the information really is. However, unless you can simultaneously track the heat emissions from every computer in the world (and somehow process that much information in a useful way!!!) it isn't a tracking tool.

The most likely place where this could be used is to provide additional evidence when there is already some reason to suspect that a person is serving illegal material. It could thus make a difference when obtaining a search warrant for someone who is already suspected. However, the initial evidence gathering and location would likely have to be done using more traditional (word-of-mouth, email interception, domestic spying) ways.

Re:Fix it with NTP? (1)

sjmurdoch (193425) | more than 7 years ago | (#17409434)

The article is very low on information on how he proposes to locate a computer.
This is explained in the associated paper [cam.ac.uk] .

Re:Fix it with NTP? (2, Informative)

lky (246353) | more than 7 years ago | (#17409464)

While Herbivore sounds interesting, don't forget to mention its limitations as well.

In the Herbivore documentation, you will find this PDF: Eluding Carnivores: File Sharing with Strong Anonymity [cornell.edu]

From which we learn that: The system consists of approximately 27,000 lines of Java and C code, 2,000 of which comprise the GUI for anonymous filesharing and a helper application for k-anonymous chat while the rest form the core system. (Section 5: Performance)

So Herbivore provides anonymity for filesharing and chat. That is all it can do in its current implementation.

On the other hand, Tor works with any IP based protocol and can be integrated into the applications that a user currently uses.

The second weakness of Herbivore is that it is not ready for distribution yet. The only code available is if you request to be part of the initial rollout by non-anonymous email. Herbivore Download Page [cornell.edu]

Tor is not only available for download, it is in current use.

The third weakness of Herbivore is that it requires that a client application be run on the users system. If your system is ever confiscated and examined by the authorities, this can be judged to be evidence of potential wrong doing resulting in further examination (if you don't believe this is possible, just read: PGP Ruled as Relevant For Criminal Case [slashdot.org] ). A secondary weakness of the client is that it will limit the operating systems that Herbivore will run on to those systems that support Java and that Herbivore has been developed for (I2P [i2p.net] has the same problem).

On the other hand, Tor can be used by simply configuring the users application to use a known Tor entry point as a proxy server. This configuration can be removed when the user is done, leaving little or no tracks. In this way, Tor can be used by any system that supports TCP/IP and SSL.

And the fourth and last weakness I will mention is that since Herbivore has not been released yet, it has not undergone extensive peer review and testing. On the other hand, the reason we are aware of Tors weaknesses is because it has been released, tested and peer reviewed. As we've learned from many cryptographic systems, you should not trust them until this peer review is complete and any/all weaknesses are known (which is why Tor has the disclaimer that it should not be fully trusted yet).

While Herbivore may provide strong anonymity, in no way is it a replacement for a general anonymity tool like Tor. On the other hand the more tools we have, the better. So I look forward to testing Herbivore when it becomes available.

Re:Fix it with NTP? (2, Insightful)

tlund (42064) | more than 7 years ago | (#17407778)

The 1kHz clock driving the TCP timestamps in Linux is not NTP corrected. You should probably read his paper [cam.ac.uk] .

Re:I didn't RTFA, but... (1)

DaSilva_XiaoPuTao (1036976) | more than 7 years ago | (#17407136)

Sounds alot like the timing based attack on RSA. And it's very easily countered with adding some extra (random if you want) time padding.

Re:I didn't RTFA, but... (1)

Allicorn (175921) | more than 7 years ago | (#17406956)

You really should've read TFA in this case. Apparently, heating up the box causes fluctuations in system time which this chap claims to be able to detect in a meaningful way. There's more to it - interesting read.

Alli

Re:I didn't RTFA, but... (0)

Anonymous Coward | more than 7 years ago | (#17409600)

You really should've read TFA in this case.
Not to mention that the story submitter and the goddamn "editors" should also have RTFA.

Re:I didn't RTFA, but... (1)

dr.badass (25287) | more than 7 years ago | (#17406966)

Um... doesn't that require him to have physical access to the server anyway?

According to TFA, no. Now maybe you want to R it.

Re:I didn't RTFA, but... (4, Funny)

Arethan (223197) | more than 7 years ago | (#17406996)

According to TFA, no. Now maybe you want to R it.
You must be new here...

Re:I didn't RTFA, but... (5, Funny)

Hooya (518216) | more than 7 years ago | (#17407066)

consider the parent posters ID: 25287
consider your id: 223197

then, consider the fact that you found "You must be new here" a novel response - at least novel enough for you to use it. let me just say, *You* must be new here. :P

P.S. i hope the recursive irony - including my ID and the parent posters ID - is self evident. no need for recursive "*You* must be new here" replies. please think of the children.

P.P.S. i don't really think recursion is the right word. but the fact that an 'older' user is declared 'new' by a newer user on each child post should lead to a division by zero, a black hole, or at least a bazzarro world somewhere... or it might just be my bed time.

Re:I didn't RTFA, but... (1)

Short Circuit (52384) | more than 7 years ago | (#17407162)

P.P.S. i don't really think recursion is the right word. but the fact that an 'older' user is declared 'new' by a newer user on each child post should lead to a division by zero, a black hole, or at least a bazzarro world somewhere... or it might just be my bed time.
 
 
I'll take issue with your usage of the word "older"; I'll have you know that, at a measly 23 years old, I'm probably younger than /. users with a higher UID number.

And I'm too tired to really care that I really don't need to get involved in another log(UID)-based pissing match. (But hey, isn't that what posting on Slashdot at 2:30AM is all about? Besides, I already made a constructive comment over in the article about embedding DB authentication credentials on software.)

(And this ends my stupid and over-explained attempt at being funny May a future potential employer find this comment and giggle.)

Re:I didn't RTFA, but... (1)

ColaMan (37550) | more than 7 years ago | (#17407350)

I really don't need to get involved in another log(UID)-based pissing match. (But hey, isn't that what posting on Slashdot at 2:30AM is all about?

STFU, noob. :-P

Waiting, waiting, waiting.....

Re:I didn't RTFA, but... (3, Funny)

Toba82 (871257) | more than 7 years ago | (#17407180)

You must be new here.

Everyone knows that no number of P.P.P.P.P.P.P.S.s that you can add will prevent SOMEONE from posting this very comment.

Re:I didn't RTFA, but... (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17407216)

The word you're looking for is induction.

Re:I didn't RTFA, but... (5, Funny)

johnw (3725) | more than 7 years ago | (#17407296)

You must be new here...

Re:I didn't RTFA, but... (1)

jesboat (64736) | more than 7 years ago | (#17407532)

pwned

Re:I didn't RTFA, but... (3, Funny)

steveoc (2661) | more than 7 years ago | (#17407656)

You must be ....

awww .. forget it.

Re:I didn't RTFA, but... (1)

kfg (145172) | more than 7 years ago | (#17407502)

. . .the fact that an 'older' user is declared 'new' by a newer user on each child post should lead to a division by zero, a black hole, or at least a bazzarro world somewhere...

. . .in Japan!

KFG

Re:I didn't RTFA, but... (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17406994)

Someone finally posted the Saddam execution video:

http://lbn.threat.tv/Saddam_Hussein_Execution_aire d_on_Al_Arabiye_061230.wmv [threat.tv]

Re:I didn't RTFA, but... (1)

Scarletdown (886459) | more than 7 years ago | (#17407466)

Someone finally posted the Saddam execution video:


And here I thought he was executed via hanging. Instead...

Death by Boonga-Boonga!!!

Re:I didn't RTFA, but... (5, Insightful)

Barny (103770) | more than 7 years ago | (#17407064)

Close, but no cigar.

His software lets you pinpoint servers in the anon TOR network, good trick, but ultimately useless (since its the users computer you are trying to find).

Of course the other problem is "giving it a heavy load" define heavy load? is it just a little more than usual? or does it mean you have to heat board (he goes off system clock, maintained by a frequency crystal on the MB), most data centres I would think would be fairly efficient at routing even high heat loads out of enclosures and away from the machine.

And then, whoever he does this to can sue him for DoSing their machine, if they can prove (and its not overly difficult) that heat damages computer parts, he can be nabbed for wilful destruction of property as well, since his whole exercise heats the machine for no other reason than locating it.

Then of course, the only way to "heat up" said computer is to do it through the TOR api, which i am guessing most anon servers are built to handle very well (since that would be their primary task).

Oh, and this of course neglects to take into account that your TOR requests may be handled by many many servers in a cluster, each one heating and skewing at different rates...

Ok, its late on a Saturday afternoon and I can poke that many holes in his trick (even if only one is at all real), gimme a good 2-3 hours with some energy drinks in me and I can find more I am sure ^_^

If he can prove it works (and successfully do something usefull with it) in the real world, then it would be a better story.

Re:I didn't RTFA, but... (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17407710)

Close, but no cigar. His software lets you pinpoint servers in the anon TOR network, good trick, but ultimately useless (since its the users computer you are trying to find).
A foolish statement. Tor offers the facility of hidden servers, or receiver anonymity. Some servers wish to remain anoymous. In other words it is _not_ the user we are interested in for this attack.

Of course the other problem is "giving it a heavy load" define heavy load? is it just a little more than usual? or does it mean you have to heat board (he goes off system clock, maintained by a frequency crystal on the MB), most data centres I would think would be fairly efficient at routing even high heat loads out of enclosures and away from the machine.
Did you read the paper ? Again, obviously not. The clock skew is present even without the temperature affect, however minor changes in temperature do offer additional clock skew. The range of temperature causing skew is under 2 degrees.

And then, whoever he does this to can sue him for DoSing their machine, if they can prove (and its not overly difficult) that heat damages computer parts, he can be nabbed for wilful destruction of property as well, since his whole exercise heats the machine for no other reason than locating it.
An fine point, outstanding. Except we don't know who the person is, they are using Tor. Sender anonymity, it's great.

Then of course, the only way to "heat up" said computer is to do it through the TOR api, which i am guessing most anon servers are built to handle very well (since that would be their primary task).
No this is not the case, as in fact most 'anon servers' or tor onion routers are not built for Tor. Tor is an additional feature run on these machines, there are very few core tor routers, solely dedicated to tor. And of course by merely routing a number of streams, doing exactly what the application was designed to do, the temperature will build up.

Oh, and this of course neglects to take into account that your TOR requests may be handled by many many servers in a cluster, each one heating and skewing at different rates...
There is no support in Tor at the moment for load balancing, if that is what you are implying.

Ok, its late on a Saturday afternoon and I can poke that many holes in his trick (even if only one is at all real), gimme a good 2-3 hours with some energy drinks in me and I can find more I am sure ^_^ If he can prove it works (and successfully do something usefull with it) in the real world, then it would be a better story.
Read the paper and inform yourself. http://www.cl.cam.ac.uk/~sjm217/papers/ccs06hotorn ot.pdf [cam.ac.uk]

FTA: Clock Skew, not temp. (5, Informative)

Mr. Flibble (12943) | more than 7 years ago | (#17406964)

The temp increase is the method to cause the clock to skew as the chip heats up due to added server load. The heat itself is not detected, so the summary is very misleading. The idea is to load the server enough so that the timestamps begin to change, and these changes can be detected.

Of course, the defense to this attack is probably something along the lines of:

$ man nice

Re:FTA: Clock Skew, not temp. (5, Informative)

jd (1658) | more than 7 years ago | (#17407298)

There are several defenses.
  • First, if the computer is sensibly cooled (ie: not by convection currents) then heating will be minimal.
  • Second, if you use a high-precision clock-chip, the chip will be tens or hundreds of times more accurate than the system time, so the drift will be entirely absorbed through the loss of accuracy.
  • Third, a defender worried about such an attack would use an oven-controlled oscillator for the clock, which means the temperature is whatever you want it to be. You can deliberately vary it to produce errors, or compensate for external temperature changes. Either way, you can be quite invisible to this method.
  • Fourth, the TOR network should be using an external time source (eg: NTP) that is not included in the TOR tunnel - ie: it's out-of-band - which means that the computers can automagically correct drift. If the computers are REALLY good, they'd correct drift on a second-order or third-order basis, rather than as a constant, so that you adapt how you read the clock to the shift in drift.


The idea of using some sort of timing attack against such a network is interesting. There are probably better methods, though.


One idea that springs to mind is that such P2P systems use caches. If you could generate enough requests to flood the cache system, you can force any computer to query nearby computers, where the latency will be roughly equal to the number of hops along the critical path. It then becomes similar to the game of "Black Box", where you try to map particles by throwing rays in and seeing what happens. If you have a sufficiently large latency map from a sufficiently large number of entrance points, you should be able to derive the whole of the exposed topology of the P2P network and be able to identify which of those servers carry what data.


(Think about it. Those of us in Open Source have all done reverse engineering, we have all tried to wrest the secrets of some black box we can't see the inside of, and eventually we have all succeeded in doing so. Our interpretation may not 100% match the internals literally, but they WILL 100% match the internals logically. And in the end, that's all that matters.)

FTA: Easier, faster, not temp. (0)

Anonymous Coward | more than 7 years ago | (#17407390)

Gee, all this braintrust and everyone missed the part were he says that there are easier and faster ways to attack Tor. Maybe you all should be worrying about THAT, instead of how to keep your clocks from skewing?

Re:FTA: Clock Skew, not temp. (1)

sjmurdoch (193425) | more than 7 years ago | (#17407912)

First, if the computer is sensibly cooled (ie: not by convection currents) then heating will be minimal.

The computers I tested it with were normal desktop machines. They all had fans, and in some cases were thermostatically controlled. The differences in temperature were only 1–2 C, but that could be remotely detected.

Second, if you use a high-precision clock-chip, the chip will be tens or hundreds of times more accurate than the system time

An oven-controlled crystal might be accurate enough (<1ppm) but it still needs to be integrated at the hardware level. Plugging it into NTP is not enough since non-NTP synchronized clocks are exposed remotely. The same applies for using NTP normally. Moreover, NTP is explicitly designed to react slowly (to handle latency), so faster effects, like the ones I measure, will still be visible.

Re:FTA: Clock Skew, not temp. (1)

Gordonjcp (186804) | more than 7 years ago | (#17408116)

Let me know if you want to try it with an oven-controlled clock. I'm sure I can sort out something that will hold a reasonably steady temperature (better than free-space at least).

Re:FTA: Clock Skew, not temp. (1)

arevos (659374) | more than 7 years ago | (#17407956)

One idea that springs to mind is that such P2P systems use caches. If you could generate enough requests to flood the cache system, you can force any computer to query nearby computers, where the latency will be roughly equal to the number of hops along the critical path. It then becomes similar to the game of "Black Box", where you try to map particles by throwing rays in and seeing what happens. If you have a sufficiently large latency map from a sufficiently large number of entrance points, you should be able to derive the whole of the exposed topology of the P2P network and be able to identify which of those servers carry what data.

Nice idea, but it wouldn't work on Tor. The topology of the router network depends on who is using it, as routing paths are decided by the machines using the Tor network to remain anonymous, not by the routers themselves. In the case of a hidden service on Tor, a directory server is used to associate a .onion TLD with several routing paths the clients can use to contact to the server. Little information can be derived from the routing paths themselves, as the address of each router in the sequence is encrypted with the public key of the previous router. Because there are only a finite set of routes published that can lead to the server, and because none of the routes can be dissected due to the encryption on them, testing their latency would tell you relatively little.

Your system would work fine on a decentralized P2P system not designed for anonymity, but none of the anonymous P2P systems I can think of would be caught out by your flooding attack.

(Think about it. Those of us in Open Source have all done reverse engineering, we have all tried to wrest the secrets of some black box we can't see the inside of, and eventually we have all succeeded in doing so. Our interpretation may not 100% match the internals literally, but they WILL 100% match the internals logically. And in the end, that's all that matters.)

In order to reverse engineer a black box, one needs to gather a sufficient amount of information. Tor limits what information you can gather. You can know that there are N routes that lead to a hidden service; you can know that M routers make up a particular route; you can know that the total latency of those M routers at any one time is L; and finally you can know that a particular route starts with the router R. This is the sum total of the information you have access to, and from this you have to work out what single server on the entire net is the one you're searching for. Good luck!

Re:FTA: Clock Skew, not temp. (1)

Instine (963303) | more than 7 years ago | (#17408318)

"(Think about it. Those of us in Open Source have all done reverse engineering, we have all tried to wrest the secrets of some black box we can't see the inside of, and eventually we have all succeeded in doing so. Our interpretation may not 100% match the internals literally, but they WILL 100% match the internals logically. And in the end, that's all that matters.)"

In many ways I agree, but literal != logical. If I spoof the behaviour you look for, I could 'frame' another server for my processes. Logically, it would be they that served it, but literaly, it would be me. If I can detect and filter the flood from the attact, in order to avoid the timeing offset, but imediately start a similar attac on another server in the system, ....

Unlike most webservers, most servers on Tor are desktops. They're not their to serve, but to browse. So unlike a web server, you can afford to deflect flood attacts, and effectively do without service for a while, dureing an attack.

So if you REALY want anon, this is not the end of Tor (an similar) as a solution.

Re:FTA: Clock Skew, not temp. (1)

pla (258480) | more than 7 years ago | (#17408914)

There are several defenses.

You forgot the simplest one that will defeat all attempts at timestamp fingerprinting...

Lie about the time. As long as it monotonically increases between packets, and stays within a few seconds of accurate, everything goes smoothly (for most general-purpose data traffic - Obviously this would completely screw up something like an NTP query).

Re:FTA: Clock Skew, not temp. (0)

Anonymous Coward | more than 7 years ago | (#17407816)

How is "nice" going to help? Nice only reduces the priority of a process. A CPU intensive process will still keep the CPU busy at 100%, whether it's spawned at normal priority or at a nice priority.

So nice has no impact on heat, it only improves responsiveness of other processes.

Re:FTA: Clock Skew, not temp. (0)

Anonymous Coward | more than 7 years ago | (#17409758)

so the summary is very misleading.
This is Slashdot. Mod parent -1, Redundant.

Run Distributed.net or SETI@Home etc. (0, Redundant)

Lord_Breetai (66113) | more than 7 years ago | (#17406976)

They'll peg the CPU, that way it'll be warm all the time. And since they can be set as an idle process they'll step aside as needed.

 

Randomize the clock (4, Insightful)

Mal Reynolds (676267) | more than 7 years ago | (#17406982)

Randomizing the clock of systems serving Tor traffic would render this attack worthless.

Since this and other such attacks are based on analyzing very small changes in the target system clock, even a tiny amount of randomization or pseudo randomization would be effective.

Re:Randomize the clock (2, Informative)

Baricom (763970) | more than 7 years ago | (#17407062)

Other potential solutions include preventing machines from reporting local time (through HTTP? - I'm not clear the attacker learns the time in the first place; neither TCP nor IP have time information in the headers, it seems) or preventing hidden servers from talking on the public Internet.

For most hidden services, either should be feasible. Timing doesn't seem that important anyway, given the inherent latency of the Tor network.

Re:Randomize the clock (1)

Psychotria (953670) | more than 7 years ago | (#17407220)

It's probably easy for the "attacker" to note the time they "attack".

Re:Randomize the clock (1)

kasperd (592156) | more than 7 years ago | (#17407310)

neither TCP nor IP have time information in the headers
I think they do. I don't know exactly how it works, but netcraft [netcraft.com] use it to report the uptime of servers. There is also a feature in nmap which does something similar, though it doesn't seem very reliable to me.

But this whole thing seems unrealistic anyway simply because you don't know which machine to be monitoring, and you can't be monitoring every machine on the internet.

Re:Randomize the clock (1)

Fweeky (41046) | more than 7 years ago | (#17407430)

RFC1323:

This memo presents a set of TCP extensions to improve performance
  over large bandwidth*delay product paths and to provide reliable
  operation over very high-speed paths. It defines new TCP options for
  scaled windows and timestamps, which are designed to provide
  compatible interworking with TCP's that do not implement the
  extensions. The timestamps are used for two distinct mechanisms:
  RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped
  Sequences).
Section 4:

The timestamp value to be sent in TSval is to be obtained from a
      (virtual) clock that we call the "timestamp clock". Its values
      must be at least approximately proportional to real time, in order
      to measure actual RTT.

Re:Randomize the clock (1)

whoever57 (658626) | more than 7 years ago | (#17407124)

If I read this correctly, it requires the enclosure to heat up, since the clock oscillator is on the motherboard, not on the CPU. Thus, randomising fan speeds would have the same effect.

Even if the clock oscillator were part of the CPU package, adding some random variation to the CPU cooler fan speed would defeat this.

Re:Randomize the clock (4, Insightful)

KermodeBear (738243) | more than 7 years ago | (#17407170)

What about always using 100% of your CPU? I run the BOINC [berkeley.edu] client for the Rosetta@HOME [bakerlab.org] project and tell it to crunch as much data as it can with idle CPU time. It is ALWAYS up and running. So, if I have this running on a machine that also uses Tor then the "create extra CPU load" method would fail.

Re:Randomize the clock (1, Insightful)

evilviper (135110) | more than 7 years ago | (#17407486)

So, if I have this running on a machine that also uses Tor then the "create extra CPU load" method would fail.

Not necessarily.

If you have your CPU-intensive app running at a low priority, and TOR running at a higher priority, then your CPU will become slightly hotter when TOR is doing heavy processing.

It may make it much harder to detect than it already is, but there you go.

Re:Randomize the clock (2, Insightful)

Anonymous Coward | more than 7 years ago | (#17407834)

What has priority got to do with it?

Why would heavy processing by TOR make the CPU run hotter than heavy processing by $SOME_APP ? It's still just heavy processing, CPU at 100% usage.

Re:Randomize the clock (1)

Zogg (238055) | more than 7 years ago | (#17408828)

Not necessarily. Not all CPU loads are equal, especially in terms of heat. For example, using the floating point unit as opposed to doing integer processing will produce different temperature changes.

This was my first thought as a defense while the researcher was presenting at the CCS conference this year, but he did a good job of tearing that idea apart during the question and answer session.

Re:Randomize the clock (0)

Anonymous Coward | more than 7 years ago | (#17408982)

I`d think harddrive activity to be more of a load on the system, but maybe it won`t make the clock drift? I don`t know, but people tend to forget the harddrive as the slowest bottleneck in the system.

Nope. (0)

Anonymous Coward | more than 7 years ago | (#17407234)

Never randomize what you can remove. They'll do a bunch of attacks, then average out the randomness.
Best to try to correct for the clock skew more often, instead.

Re:Randomize the clock (2, Insightful)

sjmurdoch (193425) | more than 7 years ago | (#17407856)

Have a look at this blog posting [lightbluetouchpaper.org] for why adding random noise will not prevent the attack. Essentially, random noise doesn't change the average skew, since the computer doesn't have an independent reference clock. By taking a moving average over time, the noise can be detected and removed.

Trivial Solution (-1, Redundant)

Bios_Hakr (68586) | more than 7 years ago | (#17406984)

If you run TOR, run Folding@Home also. F@H will slack off a bit while TOR does its thing. After TOR finishes, F@H picks back up.

There will be a small delay in there. Maybe big enough to pick up. But I doubt it.

Of course, you could combine this with EM spectrum sniffing and easily pinpoint a particular PC.

Re:Trivial Solution (1)

jandrese (485) | more than 7 years ago | (#17406990)

What if your servers are busy with other tasks, like decoding other people's TOR traffic? It seems to me that busy servers are pretty chaotic and this attack would be pretty dicey in the real world.

Re:Trivial Solution (2, Informative)

Bios_Hakr (68586) | more than 7 years ago | (#17407040)

I picture this attack being used as part of an ongoing investigation. They have a target and they just need some pattern analysis to secure the warrant. Over a month-long investigation, they could glean a lot of info by throwing up very specific requests and seeing if your hard drive springs to life or your CPU spikes.

In most cases, the wouldn't even need to be near your house. A well-positioned amp-meter with remote sensing could tell you if the CPU suddenly needed more power.

Re:Trivial Solution (1)

Lehk228 (705449) | more than 7 years ago | (#17407168)

folding@home running at low priority will suck up the unused cycles on your machine giving a pretty much flat power draw in response to "extra" work since you are always doing extra work

Re:Trivial Solution (1)

MBHkewl (807459) | more than 7 years ago | (#17407268)

Plus other distributed projects, like the ones from http://www.distributed.net/ [distributed.net]

Re:Trivial Solution (1)

MBHkewl (807459) | more than 7 years ago | (#17407222)

There are CPU frequency-shifting programs (for Linux: cpufreq) that allow the computer's user to change the CPU's frequency to his/her liking...
One could easily set the frequency lower than the original maximum, so that spikes can't be detected.

Add to the above approach, keeping the clock in sync, as others have noted.

Re:Trivial Solution (1)

evilviper (135110) | more than 7 years ago | (#17407538)

A well-positioned amp-meter with remote sensing could tell you if the CPU suddenly needed more power.

Somehow I don't think that would meet the standard for evidence...

You need to measure tiny variations in current caused by one device, mixed in with the haystack of all the other electric devices in your house... Most of which can vary significantly from moment to moment.

Re:Trivial Solution (0)

Anonymous Coward | more than 7 years ago | (#17408232)

It shouldn't be too hard to isolate the power usage of your basement.

Read it yesterday on Wired already... (-1, Offtopic)

thedarb (181754) | more than 7 years ago | (#17407014)

Ugh, here you go again, citing Wired. If you are going to do it, at least do it when the article is brand new, like *before* I've read it. Regurgitated news... nice.

Too easy to defeat (0)

Anonymous Coward | more than 7 years ago | (#17407016)

So the next iteration of TOR will inject random +/- tick into the timestamps. Making it impossible to decorrelate.

Not to mention that anonymous browsing are not servers. They will not respond to load.

What is needed - better protocols for mail and other services making anonymous services moot.

WHA!?! (1)

illeism (953119) | more than 7 years ago | (#17407018)

I'm changing my heatsink from copper to fiber...

Eli Lilly Internal Memos Leaked using Tor (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#17407028)

The internal Ely Lilly memos have been leaked to the intenet using Tor [pbwiki.com] . See zyprexakills.us [zyprexakills.us] for details.

Great heat source (1)

edwardpickman (965122) | more than 7 years ago | (#17407032)

I miss read the title the first time, the joke being I do heat my office with computers. I have three of them in the room and the 4800 dual core puts out a fair amount of heat on it's own keeping it toasty compared to the rest of the house. I used to have a dual 300 that got so hot you couldn't touch the side of the case. I literally put a box fan on that one to keep it running.

Re:Great heat source (1)

Gordonjcp (186804) | more than 7 years ago | (#17408134)

I have a PDP-11/73 [kicks-ass.net] that warms up the workshop quite nicely. I don't know why, but despite drawing around 400W (just the same as my PC) it throws out a lot more heat. Of course if you fire up the big RL02s it gets a lot noisier and the current draw goes up. Just the PDP-11 on its own is quieter than my PC, too, despite having four 5" fans.

April already? (0, Offtopic)

daveb (4522) | more than 7 years ago | (#17407058)

It's amazing how fast the year flies. It seems like Christmas was just this week and we're already at April 1.

utterly useless? (3, Interesting)

pavera (320634) | more than 7 years ago | (#17407116)

Ok, so if I am using Tor, presumably I've got clients behind these servers.... so according to the article, he can detect a server? What good does that do him? That doesn't identify *MY* machine the client which is actually doing the browsing. So, he can see which server is running Tor... couldn't he just portscan to find that out?

Re:utterly useless? (2, Informative)

Anonymous Coward | more than 7 years ago | (#17407186)

TFS mentioned "servers" and then jumped to "hidden servers".

Hidden services are something different than a Tor user. A hidden server is reachable via some hostname in the .onion TLD and provides services like HTTP, just like in the non-Tor network. It's basically an anonymous server instead of an anonymous client.

More info on Murdochs talk (2, Informative)

tlund (42064) | more than 7 years ago | (#17407156)

More info on Murdochs talk can be found at the congress website [congress.ccc.de] .

Utter Bullshit (0)

imag0 (605684) | more than 7 years ago | (#17407230)

Apparently written by someone whom has never stepped in a well stocked data center before.

Re:Utter Bullshit (1)

dfoulger (1044592) | more than 7 years ago | (#17407290)

Obviously someone who is unaware of the millions of machines that are routinely overheated by overload ... most machines running graphics intensive applications and all machines running BOINC. Bad thinking, but wishful thinking often is. Davis

Easy solution... (1)

AmiMoJo (196126) | more than 7 years ago | (#17407354)

Just run Folding 24/7, max out your CPU. Also, monitoring heat requires physical access to the server. Oh well, nice try though.

please read the other posts before posting (1)

name*censored* (884880) | more than 7 years ago | (#17407608)

You are the lucky eighth person to post this very same idea (almost word for word) :)

Please read the other posts :)

Curiously (1)

Jacques Chester (151652) | more than 7 years ago | (#17407448)

All the anonymised computers which heated up had Pentium 4s.

Sounds like a ... (1)

genmax (990012) | more than 7 years ago | (#17407452)

lot of hot air to me ! *ducks*

LOL (1)

wickedsteve (729684) | more than 7 years ago | (#17407518)

You need to query a list of suspects and there are only at best 64 unique fingerprints.
Should I be scared now?

Hold on (1)

fred911 (83970) | more than 7 years ago | (#17407530)

It looks to me like this can (somewhat) finger print a given machine but I sure don't see how it can discover an IP on TOR.

Far simpler method... (1)

Kjella (173770) | more than 7 years ago | (#17407744)

1. Create a minor botnet
2. DDoS a server, not enough to kill it but slow it down a lot
3. Measure response times to hidden service
4. If all requests using different paths now are slow, you got it

Also, that attack scales to detect multiple hidden sites simultaniously - hit one server, request ten sites and see who answers quickly and not. It's just a consequence of depending on one machine. The only way you could totally avoid that is to not have services at all, only distributed datastore like e.g. Freenet. That would severely limit the possible applications though.

Simple Defense (4, Insightful)

Cbs228 (596164) | more than 7 years ago | (#17407770)

Since date and time information isn't included in TCP/IP packets, this kind of attack won't work for all services. Assuming that the "hidden servers" in question are HTTP servers, there is a rather simple workaround: simply disable sending the "Date" header. This can probably be accomplished with mod_headers [apache.org] in Apache, but I've never tried using it myself. Oddly enough, the server would still be standards compliant [w3.org] . Obviously, servers that leak the current time by some other means would still be vulnerable.

A simpler, less precise attack of this nature would simply be to continuously ping the suspected server via both Tor and the public internet. If they (reproducibly) fail at the same time (and we could launch a denial-of-service attack to make it fail), they're probably the same machine. Attacks of this nature might even be able to confirm if a hidden server is on the same network as another computer.... But any of these attacks require someone to suspect you of running the server in the first place—and if they do, you probably have bigger problems to worry about.

The bottom line is, as Tor's manual clearly indicates [eff.org] , having a hidden server machine accessible from both Tor and the internet is a bad thing. Operators of hidden services should use a dedicated machine and block all incoming traffic (on all TCP and UDP ports) that is not via Tor.

Re:Simple Defense (1)

sjmurdoch (193425) | more than 7 years ago | (#17409334)

Since date and time information isn't included in TCP/IP packets
Actually, it is [ietf.org] , and this what I mainly use, but initial sequence numbers also incorporate a timer. If both are unavailable, the link between packet emission and timer interrupts will still show up the clock skew.

Anyone got a tin foil hat? (0)

Anonymous Coward | more than 7 years ago | (#17408096)

That's it, I'm removing the NSA logo'd temprature monitor from my PC.

The answer is RC5, or SETI (1)

Bert64 (520050) | more than 7 years ago | (#17408178)

If you leave a process running in the background consuming 100% of your cpu all the time, like setiathome or distributed.net, then your system won't get hotter, rather it will just be processing something else to load the cpu and still generating the same amount of heat.

Time Sync Early And Often (1)

martyb (196687) | more than 7 years ago | (#17408328)

What if there were a time sync server in the setup whose whole purpose in life is to keep track of the time?

Have no other apps running on it, so that it has negligible system load. All the other systems in the TOR could be set up to sync their time with it every few seconds, i.e. before clock drift becomes detectable. Might check each and every second so as to intentionally cause a collision on the time server and add some randomness. Or, do a time sync every random(1..10) seconds. Or, use multiple NICs going to different ports on the switch/router where one NIC has a short ethernet cable, and the other one is quite long, so as to introduce different delays in the comms with the time server. I'm sure there are other ways.

Run Seti@Home for your privacy (1)

Skylinux (942824) | more than 7 years ago | (#17409052)

Here is a simple way of beating this attack, run Seti@Home to keep your computer cooking at all times.

Use NTP to defend against all clock skew attacks (4, Interesting)

Terje Mathisen (128806) | more than 7 years ago | (#17409466)

This theoretical attack is based on using (previously covered on /.) clock skew to identify systems.

The correct defense is the same as the last time:

a) Make sure that there is no system clock skew, by running Network Time Protocol (NTP) on all servers.

b) Make sure that all externally visible timestamps are based on the system clock.

Part (b) is the only difficult step, since many current IP stacks use a private counter/clock instead of the system clock, presumably to reduce the overhead of providing timestamps. I know that Linus T have discussed using user-level library code to provide microsecond resolution (or better) timestamps, with very low overhead:

The library code can just query the cpu/system timer, multiply by the current scale factor (which depends on things like dynamically variable cpu clock frequency), and add the base time which was stored by the OS on the last HW clock interrupt: Total runtime, including call/return overhead can be below 100 clock cycles, which is fast enough to use it everywhere timestamps are needed:

BTW, I wrote asm code to do exactly this inside Novell's NetWare OS a little over 10 years ago. In NetWare these timestamps were used by the Packet Burst algorithms which optimized packet transmission rates.

Terje

Somewhat Major assumption here.. (1)

FrostyCoolSlug (766239) | more than 7 years ago | (#17410108)

Ok, I read the article, and it essentially says.. "Do something intensive, the clock slows down marginally, then use the differences potentially created to find which machine it was".

In his TOR network test, he apparently found the machine, but.. How many of them were receiving "Normal Day to Day" use? On how many of those machines were people playing first person shooter or real time strats? even once the TOR request is complete, if people are still gaming, in the time it takes to find the IP, that skew more than likely would have increased more.

In a real life situation, the time it would take to find a tor server, would be easily long enough for a different skew to have developed.

Apparently it's difficult to defend against it, but it's also difficult to actually PROVE it.

what if (1)

hurfy (735314) | more than 7 years ago | (#17410338)

What i haven't seen mentioned yet is:

Won't this break down if more than one investigator is running this attack on a network? What if several people try this trick against a group of servers? How would they know the time skew was due to THEIR query? What if this is the best trick ever so everyone trying to track down a computer uses it ;)

Couldn't they detect whatever the popular trick is to increase temp and have the computer try and skew others on the network. I don't suppose you would want to do it randomly against your own network as it may slow everything down but it seems you certainly could.

Seems like a lot of variables in there along with the other ideas presented.

Sounds like a good theory that runs into real world speed bumps pretty quickly.

Having a flying car to get around traffic sounds great, until everyone else gets one too....

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>