Talos Vulnerability Report


NAK to the Future: NTP Symmetric Association Authentication Bypass Vulnerability

Oct 21, 2015

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


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


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,
                            return;                        /* hooray */
                    if (is_authentic == AUTH_ERROR) {
                            fast_xmit(rbufp, MODE_ACTIVE, 0,

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 */
                    if (has_mac &&
                        (hismode == MODE_ACTIVE || hismode == MODE_PASSIVE))
                            fast_xmit(rbufp, MODE_ACTIVE, 0, restrict_mask);

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    2 u    2   64   77   61.985   -5.808   4.378
+server2    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    2 u   62   64   37   54.822   -7.868   4.310
+server5    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    2 u   54   64  377   59.255    4.625   7.393
+server2    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    2 u   49   64  377   52.071    1.726   8.939
+server5    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    2 u   32   64  377   57.873    1.455   5.495
xserver2    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    2 u   25   64  377   90.991  -22.040  18.962
xserver5    2 u   25   64  377   98.811    0.776   6.355
-attacker1   2 S   25   64    1    0.310  -300432   0.000
+attacker2   2 S    1   64    1    1.210  -300432   0.000
-attacker3   2 S   34   64    1    0.567  -300433   0.000
-attacker4   2 S   10   64    1   15.753  -300417   0.000
+attacker5   2 S    5   64    1    0.396  -300431   0.000
*attacker6   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    2 u    1   64    1   58.073  300425.   0.000
+server2    2 u    -   64    1   85.505  300424.   1.201
*server3          .ACTS.          1 u    1   64    1   84.131  300423.   1.182
 server4    2 u    1   64    1   51.920  300425.   0.000
-server5    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     2 u   52   64    1   67.141  300424.   6.354
xserver2     2 u   52   64    1   88.428  300424.   0.888
xserver3         .ACTS.           1 u   53   64    1  107.698  300415.  12.255
xserver4     2 u   51   64    1   67.562  300419.   5.143
xserver5     2 u   56   64    1  101.432  300427.   1.491
*attacker1     2 S   29   64    2    1.853    3.464   0.000
-attacker2     2 S   10   64    3    0.102    5.735   3.579
-attacker3     2 S   35   64    2    1.733    1.986   0.000
-attacker4     2 S   10   64    3    0.205    5.640   2.975
+attacker5     2 S    9   64    3    1.172    4.657   2.598
+attacker6     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:

  • 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


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:


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


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         2 u  257  256  377    1.388    3.174   2.315  .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?

Discovered by Matthew Van Gundy of Cisco ASIG.


2015-10-07 - Vendor Disclosure
2015-10-21 - Public Release