Why is this possible put simply the time stamps etc are (in most OS’s) derived from the same clock source be it hardware or software. This is due simply to trying to minimise the use of resources by the OS.

There are certain security areas where this is of great concern over and above anoymous hosting of services.

First off think of Honey Nets, these are designed to trap the attempts of skilled crackers trying to break in, so that what they do can be anyalised. More often than not these Honey Nets are not made up of a host per IP address, they often use one set of hardware to look like multiple hosts. A Honey Net is only of use if it cannot be detected as such.

Now if you assume you are an intelegent cracker who does not want your latest tricks revealed. Performing what looks like a bad network scan several times (ie script kiddy type behaviour) and harvesting the time stamps and doing comparisons will show that the time skew is possibly the same. Opps play safe you have probably found a Honey Net, time to move on and try somewhere else.

The Honey Net Operator just sees it as one more Skript Kiddy and does not realise that his network has been found by Timestamp Enumeration (it might not even make it past his IDS detectors threshold). The Cracker meanwhile may let their (very few) trusted colleages know their suspicions, meaning that the Crackers the Honey Net Operators are realy after will not knock on their door so no data to analyse (which is not good for the rest of us).

Why do I say “may let” well the best of the crackers these days do not do it for fun they do it for comercial advantage be it either for the write up and subsiquent consulting advantage. Or worse from the ordinary users prespective for snooping Maleware. Eitherway the last thing the cracker needs is for their money making crack to get publisized / rumbeled before they have made good value from it.

As a secondary atack again of value, it is not unknown for Hosting organisations to run more than one customer companies services on a single host but with different IP addresses or URLs.

Now on the assumption you are a cracker for gain, youwill want to get at details on a particular companies website as the data held there is of value to you or your employer.

The target website it’s self may not present any available oportunities to break in. But another companies site on the same host might well do so (actually quite likley for small and startup companies using hosting organisations, why spend money on making a secure site if it a couple of static pages and an emailing script).

So as the cracker you get a time/frequency skew for the site of interest, then scan all the other sites within the hosting organisations domain looking for a match. Even if the Host organisation use the same IP address and different URLs this will be productive as sometimes they move sites from host to host (there are various ways a Cracker can find this information but it’s not relevant to the argument).

As the cracker you can then investigate the other websites on the host of interest, the chances are atleast one will have an exploitable weakness. At this point you are in to the host with the priveladges of the web software. For a poorly implemented host this may be all you need to get to the data you could not otherwise get. If not the chances are that you can escalate your priveladges up to a point where you can. Either way you get what you are looking for no matter how securly the target company produced it’s web site.

Also of note the only way to trully hide a site from time stamp enumeration is to make the timestamps of no use for the attack. That is you lock them to a national standard so that there is no measurable time skew to use as a fingerprint.

This by the way does not mean simply installing NTP software, some of it is poorly writen and the time correction “error signal” will be visable almost like a triangular wave on the time stamps. Again it’s visable and identical on all the IP addresses and URLs on the host due to the use of a common clock source for the network ticks.

To understand why the correction signal is visable imagine
(for arguments sake) the rising slope of the waveform is the time skew of the CPU clock it will carry on rising unless corrected. When the NTP software detects a sufficiently large time error it makes the correction this would be the downward slope, the pitch of the slope is dependent on how hard the NTP software makes the correction. Also the point at which the correction is made is usually not at the minimum detectable time difference but at some greater point as this minimises the NTP softwares use of the hosts resources.

If you look at a NTP software often the writers do make attempts to make the correction slope gradual not a step, this is mainly because a suden step effects other software etc detrimentaly.

Some NTP software is predictive, in that it tryies to apply small corrections prior to them being detectably necesary again this is to minimise the effect on other software, however it usually uses a long time window as the assumption is the time skew is effectivly constant (effectivly an adjustable low pass filter on the previous correction data).

However NTP software is not usually dynamicaly predictive therefore changes in system load etc may take the system quickly to a point where a visable error signal would appear on the interfaces. At which point somebody doing a timestamp enumeration sees a change that they can start corelating against.

Sorrey for not getting back to you put I ended up in hosiptal due to complications with an earlier visit

I will send you an EMail to discuss further your proposel.

Clive

Also, I imagine if you have some reference data over time on a machine you could detect things like hardware replacement and other potentially interesting events by comparing the age drift of the oscillator.

Given the wealth of information and suggestions outlined in your Schneier posts and in the thread here, have you considered putting together a paper of your own? Maybe the time constraints are prohibitive, but it seems to me all these ideas would benefit from coming together in a more formal whitepaper layout, even if the mechanics of a formal publication and review process are not necessarily followed.

Just a thought; and on the possible overlap between such techniques and “tempest” emissions attacks, sadly this is another area where the academic literature is thinner on the ground than it should be too, imho!

Mike

I appriciate that at the moment the attack works.

However I suspect that now it is out in the open as an attack system operators will start to look at the traffic on their machine via the logs etc (and vendors will code the appropriate filters into their IDS/P systems etc if sufficient customers ask for it).

As the attack requires the target machine to be very heavily loaded for a couple of hours (or more) then lightly loaded for an equivalent time with this cycle repeated several times, this behaviour is very likley to give a clear signiture in the system logs (along with several other related indicators if the atack is not skillfuly put together).

As you pointed out in your artical the attacker might have several hundred or more potential targets to attack before localising the network address of the machine. This makes it a clasical time/resource trade off. It is therefore quite likley the attacker will give away their precence to network operators and the TOR ops long before they have succeded.

As I indicated previously there is a very workable solution to the problem, briefly and without getting bogged down in details (and counter attackes),

Firstly you implement delaying tactics on the host to make the attackers time to probable target identification sufficiently long say a week or more. This then moves the advantage over to the system op as they can probably average the system logs more quickly to identify an attack than the attacker can average out the delaying tactics.

Secondly you move the service around various host machines in a more frequent time than target identification takes, again this moves the advantage over to the alert sys ops as they can look for changes in averages across all the machines used.

However the current TOR system does not support the second option, the question is how long before it does (assuming the good will of alternative host system owners).

All in all you have done a very nice job of taking an idea and turning it into a practical attack and then publishing the result, which others have not done. So all credit to you for your work.

Now you (or others) need to do the counter measures as in the old ECM ECCM game. In my experiance offering a possible solution to a problem you have discovered getts a more attentive audiance

I deal with most of your points in the linked paper.

Very creative, but not particularly useful.

I would disagree; in fact I used this technique in anger last week with good results. This will hopefully be described in a blog post of its own, later.

Firstly, this relies on having a server or a list of servers that might be hosting the hidden service

“Many hidden servers are also publicly advertised Tor nodes, in order to mask hidden server traffic with other Tor traffic, so this scenario is plausible.”

Also, this attack is orthogonal to other analysis techniques. If one of these produces a list of candidates, the attack presented can narrow down suspects.

Secondly, you have to (D)DoS the target server to get results – a good firewall or some proper throttling would make it nearly useless, and it is hardly subtle.

This is not necessary; an attacker can be as subtle as it likes, it will just take longer. Over time even slight signals will become apparent. A firewall will not help, since the traffic to the hidden service is encrypted so the firewall will not see the source.

Also, I imagine multiple CPUs would screw with this.

I tried this and there was no problem. Multiple CPU machines still have only one clock crystal.

And, of course, any other system load would contribute – if anything intensive is running, the results would be very unpredictable.

This was not my experience with “Low-cost Traffic Analysis of Tor”. Noise like this disappears rapidly when you average the results over time.

The hidden service operator could just ensure that no one has any reason to suspect that their server is hosting the service, or use a properly configured firewall to prevent attacks like this

The first point is unrealistic because the operator must have some motive to set up the hidden service in the first place. The second is a lot more difficult than it sounds. Firstly the operator, would have to block all incoming traffic, which precludes running a Tor node so loses the plausible deniability. Secondly this works for outgoing connections, so web-bugs and Javascript could work as well. An attacker could even snoop in outgoing traffic not destined to him. If all the candidates traffic could be monitored, other attacks will work better, but suppose the attacker could sit at a web proxy or DNS server.