The ntpq protocol is vulnerable to replay attacks. The sequence number being included under the signature fails to prevent replay attacks for two reasons. Commands that don’t require authentication can be used to move the sequence number forward, and NTP doesn’t actually care what sequence number is used so a packet can be replayed at any time.
A simple example of this being used against an NTP server is if an attacker at some point observed an ntpq command to configure a server address. This setting might be changed later due to problems with that server, such as being inaccurate or even a malicious server. A replay attack could reset the server address back to this malicious server.
It is recommended that users restrict ntpq to localhost and change the key it’s using, the key change would prevent messages already recorded from being replayed with local access.
A possible fix would be for the client to request a sequence number to be generated whenever it wants to start a session with the server, the server would create a large random nonce, store it for the session, and reply with it. The client would then include this sequence number in the signed portion of its authenticated messages, incrementing the sequence each message. The nonce must be large enough to make a repeated value sufficiently unlikely. The server must validate that the correct sequence value was included (the current sequence must be greater than the last sequence within some sort of window, such as 10, to allow for some missed packets). If too many packets are dropped the session must be restarted.
A more involved fix would be implementing a secure channel, such as TLS. This would also provide the benifit of confidentiality.
NTP ntpd 4.2.8p3
NTPsec ntpd aa48d001683e5b791a743ec9c575aaf7d867a2b0c
CVSSv2: 5.4 - AV:A/AC:M/Au:N/C:P/I:P/A:P
CVSSv3: 5.0 - CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L
This defect can be mitigated by disabling ntpq in ntp.conf.
2015-10-16 - Vendor Disclosure
2016-01-19 - Public Release