CVE-2015-7871
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.
ntp 4.2.8p3
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
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:
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.
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.
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:
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
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:
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
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:
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.
2015-10-07 - Vendor Disclosure
2015-10-21 - Public Release
Matthew Van Gundy of Cisco ASIG