Attacking the Network Time Protocol
Aanchal Malhotra, Isaac E. Cohen, Erik Brakke, and Sharon Goldberg
Boston University

Time is a fundamental building block for computing applications, and is heavily utilized by many cryptographic protocols (eg. digital certificates and TLS, bitcoin, authentication with Kerberos, DNSSEC, etc). Time on computer clocks is commonly set using the Network Time Protocol (NTP). We have uncovered several security issues affecting unauthenticated NTP and its reference implementation ntpd. These issues allow an attacker to either (a) alter time on computer systems that set their clocks using NTP (timeshifting attacks), or (b) prevent those systems from synchronizing their clocks (denial of service attacks).

Technical paper    Our attacks    Advice for ntp implementors    Advice for ntp users    Acknoweldgements   

Our attacks:

  1. Attack 1 (Denial of Service by Spoofed Kiss-o'-Death). We present an attack that could be used to deactivate NTP on most of the computers in the Internet using only a single attacking machine. An off-path attacker, located anywhere on the Internet, can exploit NTP's rate-limiting mechanism--- the Kiss-o'-Death (KoD) packet---to disable NTP at a victim client. This attack exploits the fact that ntpd versions earlier than 4.2.8p4 allow an off-path attacker to trivially spoof a single KoD packet for each of the client's preconfigured servers; upon receipt of the spoofed KoD, the client stops querying its servers for days or even years, and can therefore no longer update its clock. Because the attacker need only send a few Kiss-o'-Death packets per victim client, standard network scanning tools (nmap, zmap) can be adapted to very quickly launch this attack, in bulk, on most of the ntpd clients in the Internet. This vulnerability is described in CVE-2015-7704, and in Section V.A-V.C of our technical paper.

  2. Attack 2 (Denial of Service by Priming the Pump). Even if the vulnerability that allows KoD packets to be trivially spoofed (see Attack 1) is patched, an off-path attacker can still disable NTP at a victim client. This attack once again exploits rate-limiting via the KoD packet. Here, the attacker elicits a valid KoD packet from the client's preconfigured servers by 'priming the pump', i.e., sending the servers a high volume of queries that are spoofed to look like they come from the client. The servers then start rate-limiting the client, responding to each of its subsequent queries with a valid KoD packet. Upon receipt of the KoD, the client stops querying its servers, and can no longer update its local clock. This attack has the same effect as Attack 1, but requires the attacker expend more resources by sending more packets to the client's servers. This vulnerability is described in CVE-2015-7705 with more details in Section V.B-V.C of our technical paper.

  3. Attack 3 (Timeshifting by Reboot). We discuss how an on-path attacker that hijacks traffic to an NTP server (using, for example, BGP or DNS hijacks) can shift time on the server's clients. Under normal conditions, if NTP attempts to update the local clock by a value that exceeds the panic threshold (about 16 minutes), then the NTP client "SHOULD exit with a diagnostic message to the system log". We discuss how to circumvent the panic threshold by exploiting ntpd's behavior upon reboot. We also present the small-step-big-step attack, which allows an attacker that reboots the client to stealthily create a big time step and then quickly bring the client's clock back to normal; this attack is useful for stealthily flushing a client's cache, or to causing a specific cryptographic object to expire. Our small-step-big-step attack is described in CVE-2015-5300 and Section IV.B of our technical paper.

  4. Attack 4 (Timeshifting by Fragmentation). We show how an off-path attacker can exploit IPv4 packet fragmentation to shift time on a client. We explain why NTP's clock discipline algorithms require our attack to craft a stream of self-consistent packets (rather than just one packet), and demonstrate its feasibility with a proof-of-concept implementation. This attack depends on IPv4 fragmentation policies at the client and server OS, rather than on weakness in ntpd or the NTP protocol. See Section VI of our technical paper.
Our technical paper discuss the implications on these attacks on other core Internet protocols (including authentication, caching, TLS certificates, bitcoin, DNSSEC, and the RPKI) and quantifies their attack surface using Internet measurements.

Attacks on NTP's Authenticated Broadcast Mode. On January 19, 2016, we released new attacks on NTP's authenticated broadcast model. See details here. We do not recommend the use of NTP's broadcast mode, unless both the broadcast clients and the broadcast server are protected by a firewall.

Full Technical Paper:

For NTP implementors: How should I patch my NTP implementation?

At the very minimum, you should apply the following simple fix to ensure that your implementation is not vulnerable to Attack 1, our Denial-of-Service by Spoofed Kiss-o'-Death attack in CVE-2015-7704: make sure that your client implementation drops KoD packets that do not pass 'TEST2' (origin timestamp validation). This should be a simple fix: KoD packets are a special kind of NTP mode 4 packet, and regular mode 4 packets are required to pass TEST2; you just need to make sure that KoD packets are also required to pass TEST2. See also Section V.A of our technical paper.

Section V.G of our technical paper provides various suggestions for implementors that would like to mitigate the risk of Attack 2, our Denial-of-Service by Priming-the-Pump attack in CVE-2015-7705. One option is to apply techniques developed for rate-limiting other protocols, e.g., Response Rate Limiting (RRL) in the DNS; the idea here is to require that when server is rate-limiting a client with KoDs, it must still send legitimate responses (instead of a KoD) to some random fraction of the client's queries. For this to be effective, NTP clients should also limit the period for which they are willing to keep quiet upon receipt of a KoD; not querying the server for over days or years upon receipt of a single KoD packet is excessive and invites abuse.

Section IV.B of our technical paper explains why ntpd is vulnerable to the small-step-big-step attack (Attack 3). To patch this, one should edit ntp_loopfilter.c to ensure that the allow_panic variable is set to FALSE after the very first clock update upon initialization. Implementors can also prevent ntpd clients from putting 'INIT' in the reference ID of their NTP packets upon initializing; this would make it more difficult for attackers to know when initialization is taking place, raising the bar for attacks that exploit reboot.

We also suggest that the NTP community take another look at authenticating NTP traffic. Traffic from client to server AND from server to client should be authenticated. See Section V.G of our technical paper.

For NTP users: How should I protect my NTP servers and clients?

  1. Attack 1 and Attack 2 (Denial of Service). Upgrade to ntpd v4.2.8p4. To see what ntpd version you are running, log into to your NTP server and type ntpq and then rv. Also, monitor the system log for error messages of the form "receive: Unexpected origin timestamp from %s", which could indicate that you are subject to a priming-the-pump attack.

  2. Attack 3 (Timeshifting by Reboot). Monitor system logs for suspicious panic events or restarts of ntpd. Alternatively, do not run ntpd with the -g option enabled. (NOTE: most operating systems run ntpd with -g as the default.)

  3. Attack 4. (Fragmentation). Our fragmentation attacks requires an NTP server that runs on an OS that accepts path MTU discovery (PMTU) requests to fragment to a 68-byte MTU.

    Running an NTP server? Check if it may be vulnerable to our fragmentation attack by entering its IP address into NTP Server Fragmentation Vulnerability Test box below. Fortunately, many modern OSes, like Windows, do not accept accept requests to fragment to a 68-byte MTU by default; your NTP server is more likely to be at risk if it runs on an older operating system. If your server is vulnerable, you should change the OS configuration to ensure it does not accept requests to fragment to a 68-byte MTU, or upgrade to more recent version. For example, on Linux, make sure that the min_pmtu parameter is larger than 90, and on Solaris, make sure that the ip_pmtu_min parameter is larger than 90. NOTE: Our network measurements indicate that servers running on SunOS or Linux 2.2.13 are especially vulnerable to our IPv4 fragmentation attack; if your NTP server is running on one of these OSes, we strongly suggest that you upgrade to a newer OS.

    Running an NTP client? Check if your client is taking time from vulnerable servers. Log into your client, type ntpq and then peers, refer to the leftmost column in the output to get a list of the time servers used by your client, and test each of these servers by entering its IP/hostname in the NTP Server Fragmentation Vulnerability Test box below. (You can also find the list of servers in ntp.conf.) If one of your servers is vulnerable, you can replace it with a different server in ntp.conf; see here.

We thank the
Network Time Foundation, NTPsec, Cisco, and RedHat's security team for quickly issuing patches for various issues described in this work. We thank Jared Mauch and the openNTPproject for measurement data and assistance with coordinating responsible disclosure of our attacks. Our work was supported, in part, by NSF awards 1347525, 1350733 and 1012910 and a gift from Cisco. Any opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the sponsors.

This research was first disclosed on August 20, 2015 and made public on October 21, 2015.