Re: [Ntp] Antwort: Re: Symmetric mode

[Miroslav Lichvar <[e-mail]>]

On Sat, Sep 24, 2022 at 07:20:36PM -0400, Danny Mayer wrote:
> On 9/22/22 3:40 AM, Miroslav Lichvar wrote:
> > The peer doesn't know if a received message is a new one or it was
> > already sent before by one of the peers. It doesn't have an infinite
> > storage and there can be messages lost in the network.
> When a peer is acting as the client it knows if it already has received the
> message. If the peer is acting as the server then it acts as if that's a new
> request from a client and responds appropriately.

The trouble is that the peer is doing both the client and server part
of the protocol at the same time. The server responds only once per
polling interval and it doesn't know which request is the genuine
request from the other peer, so replays can cause a denial of service
due to the response having an origin timestamp from the attacker's
replay instead of the peer's request.

> > The IP addresses and ports are not included in the data authenticated
> > by the NTP MAC. You can replay an authenticated NTP messages from any
> > address and any port.
> First of all you know what IP addresses you are peering with, so that
> wouldn't work anyway. I assume that you are talking about the peer acting as
> a client so if it's a replay attack it wouldn't work as the peer acting as a
> client has already received the packet so it would discard the replay
> packet.

No, this is about the server part. If the server allows ephemeral
associations, the attacker can create an unlimited number of them and
prevent a real peer from 

> >   And if you
> > specify the other peer on both ends, you can just as well use the
> > client/server mode. It will double the NTP traffic, but it will be
> > more secure.
> 
> No, that's not true. Symmetric peer mode uses the same number of packets as
> client/server

Here is a packet capture comparing two systems polling each other like
this:

A: server B minpoll 3 maxpoll 3
B: server A minpoll 3 maxpoll 3

vs this:

A: peer B minpoll 3 maxpoll 3
B: peer A minpoll 3 maxpoll 3

10:30:25.051989 IP 192.168.50.2.ntp > 192.168.50.1.ntp: NTPv4, Client, length 48
10:30:25.052171 IP 192.168.50.1.ntp > 192.168.50.2.ntp: NTPv4, Server, length 48
10:30:25.476877 IP 192.168.50.1.ntp > 192.168.50.2.ntp: NTPv4, Client, length 48
10:30:25.476911 IP 192.168.50.2.ntp > 192.168.50.1.ntp: NTPv4, Server, length 48
10:30:33.051990 IP 192.168.50.2.ntp > 192.168.50.1.ntp: NTPv4, Client, length 48
10:30:33.052176 IP 192.168.50.1.ntp > 192.168.50.2.ntp: NTPv4, Server, length 48
10:30:33.476129 IP 192.168.50.1.ntp > 192.168.50.2.ntp: NTPv4, Client, length 48
10:30:33.476175 IP 192.168.50.2.ntp > 192.168.50.1.ntp: NTPv4, Server, length 48
10:30:57.719140 IP 192.168.50.1.ntp > 192.168.50.2.ntp: NTPv4, symmetric active, length 48
10:30:59.393583 IP 192.168.50.2.ntp > 192.168.50.1.ntp: NTPv4, symmetric active, length 48
10:31:05.718401 IP 192.168.50.1.ntp > 192.168.50.2.ntp: NTPv4, symmetric active, length 48
10:31:07.393583 IP 192.168.50.2.ntp > 192.168.50.1.ntp: NTPv4, symmetric active, length 48

As you can see, there are 4 client/server mode packets per poll, but
only 2 symmetric mode packets per poll.

> and as I said above it's no more vulnerable than
> client/server.

No, there are at least three security issues specific to the symmetric
mode. You don't seem to be following what others have been saying here
for years.

As an example, I can show you how the replay attack breaks a symmetric
association configured as in the previous test.

Before the attack starts ntpq -pn on the peer B prints:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.50.1    10.2.32.37       3 s    3    8  377    0.124   +4.482   2.969

After capturing a single packet from B to A with tcpdump and replaying
it with tcpreplay once per second for 8 polling intervals the
reachability reported by ntpq drops to zero, i.e. no valid response
was received and synchronization is broken:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.50.1    10.2.32.37       3 s    8    8    0    0.011   +4.770   1.927

Here is the complete packet capture if you want to check how the peer
A is sending messages with wrong origin timestamp:

https://fedorapeople.org/~mlichvar/tmp/ntp-replay.pcap

Repeating the replay once per second is not necessary, but this was
easier than trying to time it between the request and response.

-- 
Miroslav Lichvar