Re: [Ntp] Antwort: Re: Symmetric mode

[Danny Mayer <[e-mail]>]

On 9/26/22 6:53 AM, Miroslav Lichvar wrote:
> 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.
No, and that's the misunderstanding as explained in another message. 
It's either acting as a client or as a server but not both 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.
No, this is part of the misunderstanding. Symmetric mode is not as well 
documented as it should have been and it's worth clarification in the RFC.
>
>>> 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
No more than a regular server can be attacked.
>
>>>    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.


There might be a bug in the code, but you should see the same number of 
packets.

>> 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.
>
That would be a bug if true.

Danny