Network Time Protocol Authenticated Preemptable Modes Denial-of-Service Vulnerability

CERT VU#357792

Summary

Expected Behavior:

The protocol should prevent against off-path Denial of Service attacks in authenticated broadcast and other modes which create preemptable associations, such as: multicast client, manycast client, pool client modes, and associations configured with the “preempt” option.

Actual Behavior:

An off-path attacker can send broadcast packets with bad authentication (wrong key, mismatched key, incorrect MAC, etc) to broadcast clients. It is observed that the broadcast client tears down the association with the broadcast server upon receiving just one bad packet. If an attacker keeps sending “bad” authenticated packets frequently, then the broadcast client can never sync with the real broadcast server (because of lack of sufficient number of good samples.)

This vulnerability has also been confirmed against multicast, manycast, pool and client associations configured with the “preempt” option.

Implications of the attack:

An off-path attacker can deny NTP service to the broadcast client even in authenticated mode.

Tested Versions

ntp 4.2.8p3
NTPsec a48d001683e5b791a743ec9c575aaf7d867a2b0c

Product URLs

<http://www.ntp.org>
<http://www.ntpsec.org/&gt;

CVSS Score

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

Details

Testbed Configuration for NTP:

a) We have a broadcast server, broadcast client and on off-path attacker.

b) The broadcast server is a stratum 4 server. 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. The 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

d) Attacker sends broadcast packets to the subnet with incorrect key.

Recommended Fix

There are two main problems here:

a) There is no origin timestamp check on the broadcast packets as origin timestamp is set to zero in the broadcast server packets.

b) The client tears down the association and clears the state variables on receiving a bad packet.

Improperly-authenticated packets should be discarded without further action. If ntpd makes state changes to authenticated associations in response to unauthenticated or improperly-authenticated packets, it is likely to result in a Denial of Service vulnerability.

Timeline

2015-10-07 - Vendor Disclosure
2015-10-23 - Vendors notified that all preemptable associations are affected
2016-01-19 - Public Release