Ping and please give me your system time.

Ping and please give me your system time.
A reader noticed ICMP echo request packets attempting to enter their network yesterday with the IP timestamp option set. Upon closer inspection, the payload of the ICMP echo contained a URL which was http://iplane.cs.washington.edu/ That link lead to a University of Washington research project site that measures Internet path performance. Based on their website they have been doing this since 2006. They are employing IP options in their echo request packets which many folks may noticed in their IPS/IDS logs. Echo requests with timestamp option allow you to do things like: "Measuring link attributes: Existing techniques for measuring loss rate, bandwidth capacity and available bandwidth are employed in a scalable and efficient manner to characterize the properties of all inter-cluster links in the measured topology." If your interested in jitter for example a few pings with TS allows for fairly simple jitter computation. If you see some of ICMP 8:0 with ip opts that includes TimeStamp you might want to capture some packets and look inside to see if it came from this research project. TimeStamp replies are considered dangerous as they might be used to defeat time based authentication protocols. http://www.nessus.org/plugins/index.php?view=single&id=10114	donald 206 Posts Jan 7th 2011
Thread locked Subscribe	Jan 7th 2011 1 decade ago
"TimeStamp replies are considered dangerous as they might be used to defeat time based authentication protocols." I want to call BS on that Nessus DB entry. This is kind of like Voodoo security, saying "Knowing what planet your server is on might be used in a physical attack against your server". The word "might" is so non-committal, that you can use it to claim _anything_ is a risk, even if it is not possible to be a risk. I do not agree that timestamps are "dangerous". In some rare cases, they might expose information that needs to not be exposed, for certain servers. Someone really needs to explain exactly which time based authentication protocol they think can be defeated by knowing the time; as it seems like a bad protocol, since you have a good chance of "guessing" the value of a properly synchronized system clock. What's dangerous then is not the timestamps, but utilizing broken time-based authentication protocols. The IDS may be doing its job but it's definitely overstating its case.	Mysid 146 Posts
Quote	Jan 7th 2011 1 decade ago
i think allowing strangers to clearly identify the system time an any/all servers they can 'touch' is more an issue of 'drawing attention' to a system that may not be 'in-sync' with others around it... might be a good place to start as perhaps there may be other configurations (ie. patches, security settings) that are also 'not like the others'... my $.02	Anonymous
Quote	Jan 8th 2011 1 decade ago
I recall some combination of timestamps and broken implementations that made TCP spoofing much easier (something about BSD incrementing the microseconds field by random numbers at predictable intervals, so over the long term the average values of the numbers turned out to be much more predictable than was previously thought). More recently, there was the MD5 collision attack against a public CA that involved asking for certificates continuously until one of the timestamps signed by the real CA matched the timestamp signed by a fake CA. If you are attacking a broken RSA implementation that leaks information through timing attacks, asking for high resolution timestamps on all the packets helps eliminate Internet latency noise. And so on...	Anonymous
Quote	Jan 8th 2011 1 decade ago
Well, in regards to CAs.. the certificate signing equipment does not belong on the internet in the first place; certificate signing should be a backend function, and there is little/no latency "noise" on LANs, so in the common cases where a RSA implementation would be exploited, there is no internet noise to begin with. If you have a broken RSA implementation, chances are you have already lost. Of course I wouldn't say that "high resolution timestamps are useless to attackers". But being useful is far from being dangerous. It is the IDS use of the word "dangerous", and language designed to raise fear and doubt, with no evidence of actual vulnerability, I take issue with. Lots of systems respond to pings, and that can be used to assist attackers in identifying IP addresses that are in use by a host. Of course, responding to pings, traceroutes, or other network monitoring functions can also facilitate an attacker, but that does not mean it is dangerous to have hosts that respond to ping or be able to be tracerouted.	Mysid 146 Posts
Quote	Jan 8th 2011 1 decade ago

A reader noticed ICMP echo request packets attempting to enter
their network yesterday with the IP timestamp option set. Upon
closer inspection, the payload of the ICMP echo contained a
URL which was http://iplane.cs.washington.edu/

That link lead to a University of Washington research project site that measures
Internet path performance. Based on their website they have been doing this since 2006.
They are employing IP options in their echo request packets which many folks may
noticed in their IPS/IDS logs.

Echo requests with timestamp option allow you to do things like:
"Measuring link attributes: Existing techniques for
measuring loss rate, bandwidth capacity and available
bandwidth are employed in a scalable and efficient manner to
characterize the properties of all inter-cluster links in the
measured topology."

If your interested in jitter for example a few pings with TS allows for fairly simple jitter computation.
If you see some of ICMP 8:0 with ip opts that includes TimeStamp you might want to capture some packets and look inside to see if it came from this research project.

TimeStamp replies are considered dangerous as they might be used to defeat time based authentication protocols.
http://www.nessus.org/plugins/index.php?view=single&id=10114

donald

206 Posts

Jan 7th 2011

"TimeStamp replies are considered dangerous as they might be used to defeat time based authentication protocols."

I want to call BS on that Nessus DB entry. This is kind of like Voodoo security, saying "Knowing what planet your server is on might be used in a physical attack against your server". The word "might" is so non-committal, that you can use it to claim _anything_ is a risk, even if it is not possible to be a risk.

I do not agree that timestamps are "dangerous".
In some rare cases, they might expose information that needs to not be exposed, for certain servers.

Someone really needs to explain exactly which time based authentication protocol they think can be defeated by knowing the time; as it seems like a bad protocol, since you have a good chance of "guessing" the value of a properly synchronized system clock.

What's dangerous then is not the timestamps, but utilizing broken time-based authentication protocols.

The IDS may be doing its job but it's definitely overstating its case.

Mysid

146 Posts

i think allowing strangers to clearly identify the system time an any/all servers they can 'touch' is more an issue of 'drawing attention' to a system that may not be 'in-sync' with others around it... might be a good place to start as perhaps there may be other configurations (ie. patches, security settings) that are also 'not like the others'...

my $.02

Anonymous

I recall some combination of timestamps and broken implementations that made TCP spoofing much easier (something about BSD incrementing the microseconds field by random numbers at predictable intervals, so over the long term the average values of the numbers turned out to be much more predictable than was previously thought).

More recently, there was the MD5 collision attack against a public CA that involved asking for certificates continuously until one of the timestamps signed by the real CA matched the timestamp signed by a fake CA.

If you are attacking a broken RSA implementation that leaks information through timing attacks, asking for high resolution timestamps on all the packets helps eliminate Internet latency noise.

And so on...

Anonymous

Well, in regards to CAs.. the certificate signing equipment does not belong on the internet in the first place; certificate signing should be a backend function, and there is little/no latency "noise" on LANs, so in the common cases where a RSA implementation would be exploited, there is no internet noise to begin with.

If you have a broken RSA implementation, chances are you have already lost.

Of course I wouldn't say that "high resolution timestamps are useless to attackers".
But being useful is far from being dangerous.

It is the IDS use of the word "dangerous", and language designed to raise fear and doubt, with no evidence of actual vulnerability, I take issue with.

Lots of systems respond to pings, and that can be used to assist attackers in identifying IP addresses that are in use by a host.

Of course, responding to pings, traceroutes, or other network monitoring functions can also facilitate an attacker, but that does not mean it is dangerous to have hosts that respond to ping or be able to be tracerouted.

Mysid

146 Posts