Re: [NSE] NTP Peer Listing

[jah <jah () zadkiel plus com>]

On 11/04/2010 02:14, Mak Kolybabi wrote:
> Attached is an el-cheapo straight-up rip-off of the Metasploit plugin that lists
> the most recent hosts that have connected to an NTP server.
>
> Some additional features that I'm considering are:
> - Sorting the list of addresses.
> - Separating the list between RFC1918 addresses and non-RFC1918 addresses.
>
> Suggestions and testing would be appreciated.
>   
Hi Mak, All,

Maybe we should join forces on this script - I've written a similar
script which is not quite finished.  The current version is in an
experimental svn branch at:
nmap-exp/jah/scripts/ntp-monlist.nse

There are some differences between our scripts:
I found quite early-on that, whilst using nsock to receive the monlist
data, I wasn't getting all of the replies - that is, the target sent
more data than the script received.  So I decided to use pcap to listen
for the replies and then decided to use dnet to send the query so that I
could control the source port and use it in the capture filter.
I decided the four hundred plus IP addresses is too much output from a
script and so it dumps them to file.  It prints a summary instead:

PORT    STATE SERVICE REASON
123/udp open  ntp     udp-response
| ntp-monlist: dumped 426 discovered IPv4 addresses to file:
| scripts/data/ntp-monlist-10.10.10.123.list
| and discovered internal addresses:
| 172.16/12 (71), 192.168/16 (5)
| and discovered 1 ntp server:
|_10.10.187.123

This output has changed a bit in my working copy:

PORT    STATE SERVICE REASON
123/udp open  ntp     udp-response
... as above ...
| 172.16/12 (71), 192.168/16 (5)
| and discovered 1 alternative address for the target:
|_10.10.187.123

to better reflect what the discovered ntp server actually means.
My working copy also collects IPv6 adresses:

PORT    STATE SERVICE REASON
123/udp open  ntp     udp-response
| ntp-monlist: dumped 5 IPv4 and 1 IPv6 address to file:
| scripts/data/ntp-monlist-192.168.1.21.list
| and discovered internal addresses:
| 192.168/16 (1)
| and discovered 1 alternative address for the target:
|_2a01:348:1a6:0:0:0:0:253a

It doesn't sort the address list as yours does, but it does comment-out
IPv6 and private IPv4 addresses so that the list can be passed to nmap
-iL (with a caveat that your external address may appear in the results).
It doesn't output port numbers - I didn't consider them particularly
useful and I'm also not clear on whether they're source or destination
ports (I think they might be destination ports, but in the context of
client-server, server-client and peer-peer communications).
The query my version sends contains a 40 byte data section as described
in ntp_request.h [1] and the total query length is way smaller than
those sent in the metasploit and sensepost scripts.

There are some things I still want to do to the script:
There are two data structures that can be returned by an ntp server for
a monlist query in addition to the info_monitor_1 that we handle:
info_monitor and old_info_monitor.  I haven't determined under what
circumstances these are returned, but it might turn-out to be useful to
support them.
Our scripts queries are version 2 and I'd like to look at version 3 and
4 too.
The monitor data can contain addresses for ntp servers, peers, clients
and the local host (e.g. an entry for 127.0.0.1 if 'ntpdc -C monlist' is
executed at the console of the ntp server itself). It may be possible
and useful to differentiate between hosts based on the Mode field of the
returned data structures - the mode field apparently is the mode of the
last seen communication with a host.
Query IPv6 targets - this won't work until Nmap can perform ipv6 udp
scans (unless some trickery is involved), but it might be more likely to
yield IPv6 hosts than querying an IPv4 server and a useful way of
discovering IPv6 hosts to scan.
Better file handling - at the moment the script appends to an existing
file and it may be a better idea to do one of the following:
a) read an existing file and only write unique addresses to it or
b) version the file so that comparisons may be made between them or
c) clobber the file.
Also, there probably ought to be script options for:
a) sorting the file (an expensive operation which I don't think is
necessary all of the time, but nice to have)
b) the filepath to write to.

As I said, my working copy isn't sync'ed with the nmap-exp branch at the
moment and I need to a bit of tidying, but I'll get that done and check
it in later on - you can, if you wish, have a look either now or later
(either way, you'll need the latest version of packet.lua).

I'd love to hear opinions on which output style would be most useful,
whether any of my proposed enhancements would (or not) be useful and any
other changes/enhancements.

Regards,

jah

[1] -[first google result] -
http://src.opensolaris.org/source/xref/brussels/brussels-gate/usr/src/cmd/xntpd/include/ntp_request.h

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