Talos Vulnerability Report

Summary

Expected Behavior: RFC 5905 page 29 Section 8 states that the on-wire protocol resists replay of server response packet in broadcast mode. Also on page 55 section 15, the RFC claims security in authenticated mode against on-path attackers where an attacker can:

a) Intercept and archive packets forever

b) In a wiretap attack, intercept, modify and replay a packet.

c) In a middleman attack or masquerade attack, intercept, modify and replay a packet and prevent onward transmission of the original packet.

The expected behavior in authenticated broadcast mode MUST then at the least prevent against an on-path replay attack.

Actual Behavior:

a) In a middleman attack, where the intruder is positioned between the server and the client and can intercept, and replay a packet and prevent onward transmission of the original packet, the protocol does not resist the replay attack.

b) Also if the attacker is one of the machines on the network or adjacent network who also gets broadcast packets from the same NTP server and has the same trusted keys as the victim, then he can simply replay the packets that he receives from the broadcast server.

Implications of the attack: Man-in-the-middle or a malicious client on the same/adjacent subnet can replay broadcast server packets and make the victim client’s machine be stuck at a particular time value forever. Having time back in the past has severe implications on various applications.

Note: Be aware that this issue could affect other ntpd modes of operation such as multicast.

Tested Versions

ntp 4.2.8p3
NTPSec aa48d001683e5b791a743ec9c575aaf7d867a2b0c

Product URLs

(http://www.ntp.org)[http://www.ntp.org]
(http://www.ntpsec.org/)[http://www.ntpsec.org/]

CVSS Score

CVSSv2: 4.3 - AV:A/AC:M/Au:N/C:N/I:P/A:P
CVSSv3: 4.2 - CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L

Details

Testbed Configuration for NTP:

a) We have a broadcast server and broadcast client.

b) The broadcast server is a stratum 1 server. Its refid is .LOCL. The following lines are added to the ntp.conf file for broadcast server.

       broadcast subnetaddress key keyid1
       trustedkey keyid1 keyid2
       keys /etc/ntp/ntp_key  # Path to the key file

We also create a key file ntp_key where all the keys are listed in /etc/ntp directory:

       keyid1 MD5 password1
       keyid2 MD5 password2

c) The broadcast client is configured only as a broadcast client and does not have any other associations. Following lines are added to the ntp.conf on the client:

       broadcastclient subnetaddress
       trustedkey keyid1 keyid2
       keys /etc/ntp/ntp_key  # Path to the key file

We also create a key file ntp_key where all the keys are listed in /etc/ntp directory:

       keyid1 MD5 password1
       keyid2 MD5 password2

Testbed Configuration for NTPSec:

a) We have a broadcast server and broadcast client.

b) The broadcast server is a stratum 4 server. Its refid is 192.168.33.9. The following lines are added to the ntp.conf file for broadcast server.

   server 192.168.33.9
       broadcast subnetaddress key keyid1
       trustedkey keyid1 keyid2
       keys /etc/ntp/ntp_key  # Path to the key file

We also create a key file ntp_key where all the keys are listed in /etc/ntp directory:

       keyid1 MD5 password1
       keyid2 MD5 password2

c) The broadcast client is configured only as a broadcast client and does not have any other associations. Following lines are added to the ntp.conf on the client:

       broadcastclient subnetaddress
       trustedkey keyid1 keyid2
       keys /etc/ntp/ntp_key  # Path to the key file

We also create a key file ntp_key where all the keys are listed in /etc/ntp directory:

       keyid1 MD5 password1
       keyid2 MD5 password2

Recommended Fix

The major problem here is that there is no origin timestamp check on the broadcast packets as origin timestamp is set to null in the broadcast server packets. There are a couple of recommendations that might be effective:

a) The broadcast server packet may include an incrementing counter value in the extensions field. The client should maintain state for this value in the previous packet and check if this counter value in the current packet is greater than that of the previous packet. This simple check can prevent the replay of the old packets.

b) There could be some way for NTP to see if it is stuck at the same timestamp for a considerable amount of time and should log an error or do something to warn the admin.

Timeline

2015-10-07 - Vendor Disclosure
2016-01-19 - Public Release