Re: [NSE] NTP Peer Listing

[David Fifield <david () bamsoftware com>]

On Sun, Apr 11, 2010 at 06:54:52PM +0100, jah wrote:
> 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

I found some time to test these. I really like the idea; we have to
decide which parts of which scripts will be included. Here's a test
against localhost.

PORT    STATE SERVICE REASON
123/udp open  ntp     udp-response
| ntp-monlist: discovered internal addresses:
| 127/8 (1)
| and discovered 1 alternative address for the target:
| 192.168.0.21
| and collected 4 IPv4 addresses:
|_66.79.152.35    69.36.241.112   169.229.70.64   208.77.19.5
| ntp-peers:
|   Private Peers (1)
|     127.0.0.1:56189
|   Public Peers (4)
|     66.79.152.35:123
|     69.36.241.112:123
|     169.229.70.64:123
|_    208.77.19.5:123

I like how both scripts separate out the private and public addresses. I
really like the bit "discovered 1 alternative address for the target" in
ntp-monlist. Do you get the netmask back from the NTP server in "127/8"
or is that inferred?

Here's the result from running against the first of the public peers
above (the only one that produced any output). I also included the
output of the Metasploit script.

PORT    STATE SERVICE REASON
123/udp open  ntp     udp-response
| ntp-monlist: collected 600 IPv4 addresses:
| 4.78.155.130    66.151.63.26    72.184.160.70   140.182.214.208
| 12.21.127.78    66.152.137.15   72.203.133.69   141.156.191.175
... 146 lines ...
| 66.151.63.14    72.159.219.194  137.113.118.26  217.114.222.89
|_66.151.63.17    72.169.122.140  137.113.118.28  222.66.126.163
| ntp-peers:
|   Private Peers (0)
|   Public Peers (474)
|     4.78.155.130:11308
|     12.21.127.78:123
... 470 lines ...
|     217.114.222.89:123
|_    222.66.126.163:60514

msf auxiliary(ntp_monlist) > set RHOSTS 66.79.152.35
RHOSTS => 66.79.152.35
msf auxiliary(ntp_monlist) > run
[*] Sending probes to 66.79.152.35->66.79.152.35 (1 hosts)
[*] 66.79.152.35:123 96.245.144.224:123 (66.79.152.35)
[*] 66.79.152.35:123 66.83.13.6:123 (66.79.152.35)
... 596 lines ...
[*] 66.79.152.35:123 206.169.68.114:62582 (66.79.152.35)
[*] 66.79.152.35:123 69.7.96.116:6634 (66.79.152.35)
[*] Scanned 1 of 1 hosts (100% complete)

The first thing I see is that ntp-peers gets less than 600 records. This
is reproducible. But when I run it by itself, it gets the maximum of 600.

About the source port numbers: is it possible that these distinguish
between downstream (port 123) and upstream servers (not 123)?

In terms of payload, ntp-monlist's is much shorter than ntp-peer's or
Metasploit's.

ntp-monlist:
17 00 03 2a 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ntp-peers, ntp_monlist.rb:
17 00 03 2a 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I prefer that the first commit of this script not write to a file. With
four addresses per row, we're looking at about 150 lines of output max,
which is big not but not that big.

jah, you mentioned that you had trouble with Nsock and decided to use
raw sockets and pcap to do the sending and receiving. Can you tell more
about that? Were you getting Nsock TIMEOUT errors? It should not be
necessary to use raw sockets for this script. It might be a bug in Nsock
that has to be fixed.

Overall I prefer the clarity of ntp-peers over ntp-monlist, but I much
appreciate the protocol documentation in ntp-monlist.

This is what I would like to see: A combination of these two scripts,
with the name ntp-monlist, using plain Nsock if possible, with the
shorter payload, not writing to a file, with columnar output.

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