Slashdot Mirror
Computer's Heat May Unmask Anonymized PCs
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.'"
http://knuttz.net/hosted_pages/USB-Cooking-2006082 2
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.
It's a little wrong to say a tomato is a vegetable. It's a lot wrong to say it's a suspension bridge.
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
Try to hack my 31337 firewall!
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.
Ewige Blumenkraft.
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.
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.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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.
I'd rather you do it wrong, than for me to have to do it at all.
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.
...
consider the parent posters ID: 25287
:P
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.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.
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.
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?
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.
I pretend to know more than I really do by mooching off google and wikipedia.
Yes but that's not the skew he's measuring. He's only measuring the skew caused by heating the crystal.
You must be new here...
You must be ....
.. forget it.
awww
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 in Apache, but I've never tried using it myself. Oddly enough, the server would still be standards compliant. 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, 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.
At our school, we don't earn a degree when we graduate—we earn pi/180 radians
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
"almost all programming can be viewed as an exercise in caching"