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:
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?
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.
Acknowledgements:
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.