Re: http-date.nse

[David Fifield <david () bamsoftware com>]

On Sat, Jul 11, 2009 at 04:19:11PM -0700, Fyodor wrote:
> On Mon, Jul 06, 2009 at 02:49:08PM -0600, David Fifield wrote:
> > I was thinking about information disclosure, and how you can get the
> > system clock setting of a remote system through certain scripts like
> > daytime.nse and smb-os-detection.nse. Another technique that's likely to
> > work against a lot of systems is to read the Date header field in an
> > HTTP response. Attached is an http-date.nse script that shows the date
> > reported by any HTTP-like service. It works for HTTP, HTTPS, and IPP,
> > and probably lots of other protocols.
> >
> > I don't know if this on its own is enough to be included, but it could
> > be extended to show a message when a remote clock is set incorrectly.
>
> Thanks David.  I think it is at least worth including as a non-default
> script.  There have been many cryptographic attacks (particularly
> based on poor random number generation) which benefit from knowing the
> server's exact time.  Also, knowing that two servers are each exactly
> 11 seconds slow may help you determine that they are actually the same
> underlying system with multiple IP addresses.  Conversely, if your
> HTTP requests keep varying between +5s, +2s, or -3s off correct time,
> then you probably have a load balancer directing the requests to three
> different systems.  It might be nice if the script gives a delta of
> server time compared to the client system's time.  Output is harder to
> interpret if you only have the server time but don't know exactly when
> it was taken by the NSE script.

I added the script, including time differences from local time. Here is
a sample of its output:

$ nmap --script=http-date www.time.gov scanme.nmap.org 192.168.0.1 -p 80

Starting Nmap 4.90RC2 ( http://nmap.org ) at 2009-07-13 16:52 MDT
Warning: Hostname www.time.gov resolves to 2 IPs. Using 129.6.13.35.
NSE: Script Scanning completed.
Interesting ports on www-04.nist.gov (129.6.13.35):
PORT   STATE SERVICE
80/tcp open  http
|_ http-date: Mon, 13 Jul 2009 22:52:44 GMT; 0s from local time.

Interesting ports on scanme.nmap.org (64.13.134.52):
PORT   STATE SERVICE
80/tcp open  http
|_ http-date: Mon, 13 Jul 2009 22:52:37 GMT; -7s from local time.

Interesting ports on 192.168.0.1:
PORT   STATE SERVICE
80/tcp open  http
|_ http-date: Sun, 07 Jan 2007 09:06:04 GMT; -2y187d13h46m40s from local time.

Nmap done: 3 IP addresses (3 hosts up) scanned in 3.22 seconds

As you can see, time.gov is right on, scanme is a little off, and my DSL
router is very confused.

> The reason I suggest making it non-default is that it may lead to a
> lot of output (a line for every web service) and there are many cases
> where users don't care about the server date information.

I put it in "discovery", "safe".

> I agree that a HEAD request would be better, assuming implementations
> such as the IPP server you mentioned also tend to handle HEAD.  On a
> similar note, it might be nice if the http request library would save
> the date + offset in the registry for a given port if it receives a
> Date header.  And the http-date runlevel could be increased.  That way
> if we've already done, say, an html-title, we don't need to do a
> second request in http-date just to get the date information.

Yes, I can see where simple HTTP caching would be problematic for this
script, because it wouldn't know how far in the past the page was
cached. The cache will have to store a request date with the cached
object.

It also occurs to me that scripts that use HEAD should be in a higher
runlevel than those that do GET, because with a cached GET results you
can synthesize a HEAD, but if you only have a HEAD then you have to
re-do the GET.

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org