Re: [NSE] ntp-info probing logic?

[Daniel Miller <bonsaiviking () gmail com>]

nnposter,

While I'm not necessarily opposed to dropping the success check as you
propose, I think there may be a better improvement, too. What results do
you get if you apply this patch?

diff --git a/scripts/ntp-info.nse b/scripts/ntp-info.nse
index 9ca8090..825c811 100644
--- a/scripts/ntp-info.nse
+++ b/scripts/ntp-info.nse
@@ -75,8 +75,8 @@ action = function(host, port)
   local buftres, bufrlres
   local output = stdnse.output_table()

-  -- This is a ntp v4 mode3 (client) date/time request.
-  local treq = string.char(0xe3, 0x00, 0x04, 0xfa, 0x00, 0x01, 0x00, 0x00,
+  -- This is a ntp v2 mode3 (client) date/time request.
+  local treq = string.char(0xd3, 0x00, 0x04, 0xfa, 0x00, 0x01, 0x00, 0x00,
                            0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,


This changes the request from a version 4 to a version 2 packet, which may
be more widely supported (version 3 appears to be the consensus, and each
version is backwards-compatible with previous ones except for version 1).

If this solves your issue, I'd be inclined to just limit the change to this
for now. Though your idea does bring to mind the fact that most UDP NSE
scripts do not attempt to retransmit packets, which means that network
congestion could result in lost results.

Dan



On Thu, Aug 7, 2014 at 6:12 PM, <nnposter () users sourceforge net> wrote:

> Back in March I have proposed a change in how ntp-info behaves to
> improve its compatibility.
>
> http://seclists.org/nmap-dev/2014/q1/341
>
> nnposter wrote:
> > The current version of ntp-info.nse has the following flow:
> >
> > 1. Send NTPv4 request for date/time
> > 2. Exit if it failed
> > 3. Save results
> > 4. Send NTPv2 request for readlist
> > 5. Save results (if any)
> > 6. Return all saved results
> >
> > I am wondering if anybody has any insight into the reason behind
> > the early bailout in step 2.
> >
> > I am seeing systems where the first probe in step 1 fails but
> > the second probe in step 4 does not. In case there is no good
> > reason to keep the current logic then I am proposing the patch
> > below, effectively removing step 2/3.
>
> The proposal has not received any feedback so I would like to ask for
> a reconsideration or some explanation why it would be a bad idea.
>
>
> Cheers,
> nnposter
> _______________________________________________
> Sent through the dev mailing list
> http://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/