CVE-2015-7871

Summary

Unauthenticated off-path attackers can force ntpd processes to peer with malicious time sources of the attacker’s choosing allowing the attacker to make arbitrary changes to system time. This attack leverages a logic error in ntpd’s handling of certain crypto-NAK packets. When a vulnerable ntpd receives an NTP symmetric active crypto-NAK packet, it will peer with the sender bypassing the authentication typically required to establish a peer association.

Tested Versions

ntp 4.2.8p3

Product URLs

http://www.ntp.org

CVSS Score

CVSSv2: 6.4 - (AV:N/AC:L/Au:N/C:N/I:P/A:P)

CVSSv3: 7.2 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:L

Details

In most common configurations, ntpd determines which other NTP daemons to peer with via explicit configuration directives specified by an administrator in the ntp.conf configuration file. However, ntpd also has the ability to create ephemeral peer associations on the fly in response to certain kinds of incoming requests. In most common configurations, if ntpd receives such a packet, it will set up an ephemeral association with the sender only if the packet is correctly authenticated under a key that ntpd trusts.

For example, when ntpd receives a symmetric active (NTP mode 1) packet and there is no existing peer association with the sender, ntpd executes the following check to determine if the packet has been correctly authenticated before mobilizing a new ephemeral symmetric association.

/* From: ntp_proto.c */ if (!AUTH(sys_authenticate | (restrict_mask & (RES_NOPEER | RES_DONTTRUST)), is_authentic)) { /* * If authenticated but cannot mobilize an * association, send a symmetric passive * response without mobilizing an association. * This is for drat broken Windows clients. See * Microsoft KB 875424 for preferred workaround. */ if (AUTH(restrict_mask & RES_DONTTRUST, is_authentic)) { fast_xmit(rbufp, MODE_PASSIVE, skeyid, restrict_mask); return; /* hooray */ } if (is_authentic == AUTH_ERROR) { fast_xmit(rbufp, MODE_ACTIVE, 0, restrict_mask); sys_restricted++; return; } }

In contrast to the simpler checks present in other locations where ephemeral associations are mobilized, the logic for symmetric active packets has been complicated by a workaround to accommodate some non standards compliant clients. The intent of this code appears to be:

if (AUTH(restrict_mask & RES_DONTTRUST, is_authentic)): If the packet is not authenticated and the sender is not restricted with “notrust”, it’s probably a non standards compliant client that mistakenly sends symmetric active mode packets instead of client mode (NTP mode 4) packets. In this case, it returns the symmetric passive response expected by such clients and ceases further processing (fast_xmit(); return;).

if (is_authentic == AUTH_ERROR): Otherwise, return a symmetric active mode crypto-NAK and cease further processing (fast_xmit(); return;).

In most cases, when ntpd receives a packet with a cryptographic digest that does not validate correctly, it bails out early and responds with a crypto-NAK — an unauthenticated packet containing a keyid but no cryptographic digest which informs the sender that the received packet was not correctly authenticated.

Internally, ntpd represents the authentication state of a received packet using the “is_authentic” variable which can take on four values under the following conditions:

| is_authentic | packet has | packet has | packet validates | | | keyid | digest | under keyid | |--------------+------------+------------+------------------| | AUTH_NONE | N | N | N/A | | AUTH_OK | Y | Y | Y | | AUTH_ERROR | Y | Y | N | | AUTH_CRYPTO | Y | N | N/A |

Thus, when ntpd receives a crypto-NAK packet, it sets the “is_authentic” variable to the special value AUTH_CRYPTO. This has interesting implications for the authentication check described above. The AUTH() macro always returns false if the second input is AUTH_CRYPTO. This causes the first check for unauthenticated packets sent by non standards compliant clients to fail. The second check (is_authentic == AUTH_ERROR) only matches packets that contain a bad digest. As a result, crypto-NAK packets avoid both early termination conditions and proceed through to code which creates a new ephemeral association authenticated under the keyid specified by the packet, in this case keyid == 0. This has interesting implications when we consider how authentication is enforced.

ntpd can communicate simultaneously with both authenticated and unauthenticated peers. ntpd indicates the authentication requirements for an association by storing the id of the required authentication key in the “keyid” variable of the peer association structure. The special keyid value 0 indicates that no authentication is required. By default, when a packet is received from a peer with an active association, ntpd requires the packet to be authenticated only if the association requires authentication. This check is governed by the following code.

/* From ntp_proto.c */ /* * If the digest fails or it's missing for authenticated * associations, the client cannot authenticate a server * reply to a client packet previously sent. The loopback check * is designed to avoid a bait-and-switch attack, which was * possible in past versions. If symmetric modes, return a * crypto-NAK. The peer should restart the protocol. */ } else if (!AUTH(peer->keyid || has_mac || (restrict_mask & RES_DONTTRUST), is_authentic)) { report_event(PEVNT_AUTH, peer, "digest"); peer->flash |= TEST5; /* bad auth */ peer->badauth++; if (has_mac && (hismode == MODE_ACTIVE || hismode == MODE_PASSIVE)) fast_xmit(rbufp, MODE_ACTIVE, 0, restrict_mask); ... return; }

Let us consider what happens to subsequent unauthenticated packets sent after an attacker sends a crypto-NAK. Because the association is configured with keyid 0, peer->keyid == 0. For unauthenticated packets has_mac == 0. As long as the sender is not subject to a “notrust” restriction, the first parameter of the AUTH() macro will be zero indicating that unauthenticated packets are permissible. Since is_authentic == AUTH_NONE for unauthenticated packets, AUTH() will return true, the guard will be false, and the packet will proceed to further processing. As long as the packet passes all the other consistency checks that can be met by any consistent NTP peer, it will be processed for time. If there are a majority of mutually-consistent attacking peers advertising the incorrect time, they can win the clock selection algorithm and cause the victim to accept their time.

Attack Scenario

Lets look at an attack in action. We can monitor the attack progress by querying the victim for the status of its peer associations using the “ntpq -c lpeer” command. As the attack progresses, we’ll see how the victim’s peer status changes. Initially, the victim is configured with 5 upstream servers, server1-5:

remote refid st t when poll reach delay offset jitter ============================================================================== +server1 192.168.99.1 2 u 2 64 77 61.985 -5.808 4.378 +server2 192.168.99.2 2 u 66 64 37 87.387 -9.879 6.186 *server3 .ACTS. 1 u 65 64 37 83.949 -9.816 6.583 +server4 192.168.99.2 2 u 62 64 37 54.822 -7.868 4.310 +server5 192.168.99.5 3 u 62 64 37 103.997 -5.807 4.369

Six attacking nodes (attacker1-6) send symmetric active crypto-NAK packets to the victim causing the victim to establish ephemeral peer associations with the attacking nodes:

remote refid st t when poll reach delay offset jitter ============================================================================== +server1 192.168.99.1 2 u 54 64 377 59.255 4.625 7.393 +server2 192.168.99.2 2 u 51 64 377 83.354 0.156 7.140 *server3 .ACTS. 1 u 48 64 373 86.698 2.518 10.006 +server4 192.168.99.2 2 u 49 64 377 52.071 1.726 8.939 +server5 192.168.99.5 2 u 47 64 377 101.751 3.860 8.142 attacker1 .INIT. 16 S - 64 0 0.000 0.000 0.000 attacker2 .INIT. 16 S - 64 0 0.000 0.000 0.000 attacker3 .INIT. 16 S - 64 0 0.000 0.000 0.000 attacker4 .INIT. 16 S - 64 0 0.000 0.000 0.000 attacker5 .INIT. 16 S - 64 0 0.000 0.000 0.000 attacker6 .INIT. 16 S - 64 0 0.000 0.000 0.000

In this attack, the attackers consistently advertise time that is 5 minutes behind true time. Because the time provided by the attackers is consistent and they outnumber the legitimate servers, ntpd eventually declares the legitimate servers to be falsetickers and chooses an attacker node as the chosen peer.

remote refid st t when poll reach delay offset jitter ============================================================================== xserver1 192.168.99.1 2 u 32 64 377 57.873 1.455 5.495 xserver2 192.168.99.2 2 u 27 64 377 84.543 -1.815 6.012 xserver3 .ACTS. 1 u 25 64 367 92.528 -4.774 6.641 xserver4 192.168.99.2 2 u 25 64 377 90.991 -22.040 18.962 xserver5 192.168.99.5 2 u 25 64 377 98.811 0.776 6.355 -attacker1 192.168.33.9 2 S 25 64 1 0.310 -300432 0.000 +attacker2 192.168.33.9 2 S 1 64 1 1.210 -300432 0.000 -attacker3 192.168.33.9 2 S 34 64 1 0.567 -300433 0.000 -attacker4 192.168.33.9 2 S 10 64 1 15.753 -300417 0.000 +attacker5 192.168.33.9 2 S 5 64 1 0.396 -300431 0.000 *attacker6 192.168.33.9 2 S 22 64 1 0.258 -300432 0.000

Eventually the victim steps its clock to match the attacker-provided time and resets its associations.

remote refid st t when poll reach delay offset jitter ============================================================================== +server1 192.168.99.1 2 u 1 64 1 58.073 300425. 0.000 +server2 192.168.99.2 2 u - 64 1 85.505 300424. 1.201 *server3 .ACTS. 1 u 1 64 1 84.131 300423. 1.182 server4 192.168.99.2 2 u 1 64 1 51.920 300425. 0.000 -server5 192.168.99.5 2 u 2 64 1 98.141 300425. 0.737 attacker1 .STEP. 16 S 276 64 0 0.000 0.000 0.000 attacker2 .STEP. 16 S 159 64 0 0.000 0.000 0.000 attacker3 .STEP. 16 S 407 64 0 0.000 0.000 0.000 attacker4 .STEP. 16 S 176 64 0 0.000 0.000 0.000 attacker5 .STEP. 16 S 95 64 0 0.000 0.000 0.000 attacker6 .STEP. 16 S 75 64 0 0.000 0.000 0.000

Once the victim has stepped its clock, the attackers win the election to become the chosen peers. They can maintain the system’s clock at the offset time or make further changes.

remote refid st t when poll reach delay offset jitter ============================================================================== xserver1 192.168.99.1 2 u 52 64 1 67.141 300424. 6.354 xserver2 192.168.99.2 2 u 52 64 1 88.428 300424. 0.888 xserver3 .ACTS. 1 u 53 64 1 107.698 300415. 12.255 xserver4 192.168.99.2 2 u 51 64 1 67.562 300419. 5.143 xserver5 192.168.99.5 2 u 56 64 1 101.432 300427. 1.491 *attacker1 192.168.33.9 2 S 29 64 2 1.853 3.464 0.000 -attacker2 192.168.33.9 2 S 10 64 3 0.102 5.735 3.579 -attacker3 192.168.33.9 2 S 35 64 2 1.733 1.986 0.000 -attacker4 192.168.33.9 2 S 10 64 3 0.205 5.640 2.975 +attacker5 192.168.33.9 2 S 9 64 3 1.172 4.657 2.598 +attacker6 192.168.33.9 2 S 24 64 2 2.516 4.041 0.000

In this example attack, we have only stepped the clock by 5 minutes. However, we have achieved larger offsets in lab testing. We are not aware of any limitations that would prevent attackers from stepping the clock by significantly greater values nor are we aware of limitations to prevent attackers from executing multiple successive steps to move the victim’s system time arbitrarily from the initial time.

Mitigation

Attempts to exploit this vulnerability are detected by the following IDS rules:

* Snort - SID 36536

The most complete mitigation is to upgrade to ntp-4.2.8p4. ntp-4.2.8p4 fixes a number of other critical issues in addition to this vulnerability. If your system’s ntpd is packaged by the system vendor, apply your vendor’s security update as soon as it becomes available. Until then, the best defense is to use firewall rules to block malicious traffic.

If your system supports a host-based firewall which blocks incoming traffic, such as the Windows Firewall, Mac OS X Application Firewall, or the Uncomplicated Firewall on Linux, you should enable it.

For other systems, appropriate firewall rules will depend on your environment. Use the following recommendations as a guideline for typical client-server and peer modes:

NTP clients should block incoming NTP packets from any system that is not a known, legitimate peer

NTP servers (and systems that must allow incoming ephemeral peer connections) should block incoming symmetric active (NTP mode 1) crypto-NAK packets

In environments where authentication has been configured between all NTP clients, servers, and peers, ntpd can be prevented from communicating with unauthenticated peers by enabling the ntpd “notrust” restriction. This does not prevent an attacker from causing the ephemeral peer association to be created. However, even with malicious peer associations active, ntpd should reject packets sent by those the malicious peers. The “notrust” restriction can be enabled by adding it to ntpd’s default restriction lists:

restrict -4 default kod notrap nomodify nopeer noquery notrust restrict -6 default kod notrap nomodify nopeer noquery notrust

If there are known-good peer connections that cannot be authenticated, the “notrust” restriction can be selectively relaxed for those peers only as follows:

server ntp.mydomain.local restrict ntp.mydomain.local kod notrap nomodify nopeer noquery

Further Discussion

Impact

Malicious changes system time can have grave implications in a number of systems. With the ability to change system time, an attacker may be able to:

Authenticate via expired passwords and accounts

Cause TLS clients to accept expired and revoked certificates and to reject currently valid certificates

Circumvent modern web security mitigations such as certificate pinning and HTTP Strict Transport Security

Deny service to authentication systems such as Kerberos, Active Directory, and other systems that use time-limited authentication tickets such as web services

Force caching systems such as DNS and CDNs to flush their caches resulting in significant system performance degradation

Damage real-time and cyber-physical systems

Am I Vulnerable?

This vulnerability has been confirmed in ntp version 4.2.8p3. The vulnerable code path was introduced in ntp version 4.2.5p186 (late 2009). Therefore, all ntp-4 stable releases from 4.2.5p186 through 4.2.8p3 appear to be vulnerable. All ntp-4 development versions from 4.3.0 through, at least, 4.3.76 also appear to be vulnerable.

Any product which integrates an ntpd version from the vulnerable range may also be affected. Because many vendors patch ntpd before packaging it for distribution in their products, the susceptibility of any specific product must be considered on a per-product basis.

The Cisco Product Security Incident Response Team (PSIRT) is currently investigating the susceptibility of Cisco products to the vulnerabilities disclosed with ntp-4.2.8p4. A Cisco Security Advisory should be posted shortly:

http://tools.cisco.com/security/center/publicationListing.x

Please refer to the Cisco Security Vulnerability Policy for further information about vulnerability response:

http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html

Is Configuration X Vulnerable?

If an attacker can send symmetric active crypto-NAK packets to your ntpd process and can receive responses back, then you are vulnerable unless your ntpd is configured to reject unauthenticated packets from unknown peers (e.g. “restrict default notrust …”). In a lab environment, we have successfully attacked:

Stratum 1 servers with attached refclocks

Clients configured with a single server

Clients in typical configurations with 4 servers from the NTP Pool Project and one fallback server

How Do I Know If I’m Being Attacked?

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 /etc/ntp.conf file could indicate an attack:

$ ntpq -c lpeer remote refid st t when poll reach delay offset jitter ============================================================================== *ntp-server 10.0.0.1 2 u 257 256 377 1.388 3.174 2.315 192.168.33.254 .INIT. 16 u - 1024 0 0.000 0.000 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: 36536.

More generally, reception of unsolicited crypto-NAKs that are not in response to a packet originated by the recipient may indicate an attack.

Where Can I Find More Information?

ntp.org Security Notices: http://support.ntp.org/bin/view/Main/SecurityNotice

Details of vulnerabilities fixed by ntp-4.2.8p4 that were found by other researchers Cisco Talos: http://talosintel.com/vulnerability-reports/ Boston University: http://www.cs.bu.edu/~goldbe/NTPattack.html

ntp.org Security Bug #2941: https://bugs.ntp.org/show_bug.cgi?id=2941

Cisco Security Advisories and Responses: http://tools.cisco.com/security/center/publicationListing.x

Cisco Security Vulnerability Policy: http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html

Timeline

2015-10-07 - Vendor Disclosure

2015-10-21 - Public Release