Preventing time synchronization in NTP broadcast mode

1 Preventing Time Synchronization in NTP’s Broadcast Mode Nikhil Tripathi∗ , Neminath Hubballi† arXiv:2005.01783v2 [cs.CR] 14 May 2020 Abstract Network Time Protocol (NTP) is used by millions of hosts in Internet today to synchronize their clocks. Clock synchronization is necessary for many network applications to function correctly. Unsynchronized clock may lead to failure of various core Internet services including DNS and RPKI based interdomain routing and opens path for more sophisticated attacks. In this paper, we describe a new attack which can prevent a client configured in NTP’s broadcast mode from synchronizing its clock with the server. We test the attack in real networks and show that it is effective in both authenticated and unauthenticated broadcast/multicast modes of NTP. We also perform experiments to measure the overall attack surface by scanning the entire IPv4 address space and show that NTP broadcast mode is being used in the wild by several low stratum (highly accurate) hosts. We also suggest few countermeasures to mitigate the proposed attack. Index Terms NTP, Broadcast Mode, Time Synchronization, Vulnerability Assessment, DoS I. I NTRODUCTION Network Time Protocol (NTP) [1] is one of the oldest protocols and is used to synchronize clocks of computer systems on the Internet. Clock synchronization among computers is important for many reasons as inconsistencies in clock time can affect various core Internet services such as Domain Name System (DNS) resolution, interdomain routing using Resource Public Key Infrastructure (RPKI) and Transport Layer Security (TLS) [2], [3], [4], [5]. Thus, if an adversary is able to manipulate clocks of important systems on the Internet by obstructing NTP’s operation, services to a large number of the Internet users will be affected. There have been several incidences in the past where clock synchronization failure led to breakdown of various services on the faulty systems, all at the same time. For example, two important NTP servers of U.S. Naval Observatory (USNO) were sent back in time by about 12 years on November 19, 2012 [6], “causing outages at a variety of devices including Active Directory (AD) authentication servers and routers” [7]. NTP’s potential for Distributed DoS (DDoS) using reflection and amplification techniques is well studied by the security community [8]. However, like in other application layer protocols [9], [10], [11], [12], researchers have now started paying attention to find vulnerabilities in NTP specification and implementation also [13], [5], [14]. In this paper, we describe a new attack that exploits a vulnerability present in NTP’s broadcast mode. The proposed attack prevents a NTP client from synchronizing its clock with a NTP broadcast server by sending spoofed NTP packets to the NTP client and the broadcast server. We also show how the proposed attack is effective in both authenticated and unauthenticated broadcast modes of NTP. To the best of our knowledge, this is the first attack proposed against NTP protocol since launch of NTP’s reference implementation’s most recent version ntpd v4.2.8p13 [15] on March 7th, 2019. As a first line of defense, we also suggest few countermeasures. In summary our contributions in this paper are: 1. We propose a new attack that can prevent a NTP client from synchronizing its clock with a NTP server. Nikhil Tripathi is with Technical University of Darmstadt, Rheinstr. 75, 64295 Darmstadt, Germany. Neminath Hubballi is with Discipline of Computer Science and Engineering, Indian Institute of Technology Indore, India. (E-mails:∗ [email protected], † [email protected]). ∗ Corresponding Author 2 2. We test the proposed attack in a real network and show that it is effective in both authenticated and unauthenticated NTP broadcast/multicast modes. 3. We perform extensive experiments to measure the attack surface on Internet by scanning the entire IPv4 address space and furnish the results. We also quantify the resulting attack surface and discuss that it is only the floor value of the actual attack surface on the Internet. 4. We suggest few countermeasures that can be deployed to effectively counter the proposed attack until the release of a proper security patch. Attack Disclosure: We have disclosed the attack to ntpd developers on 2nd October, 2018. Also, CVE2018-8956 has been reserved for the proposed attack. Organization: Rest of the paper is organized as follows. We give an overview of NTP protocol and its operation in Section III. In Section IV, we describe the working of proposed attack. In Section V, we present the experiments performed to test the proposed attack against NTP’s broadcast mode and the results of attack surface measurement in Internet. We describe some of the possible countermeasures to mitigate the proposed attack in Section VI. We explain previously known attacks against NTP and techniques to counter these attacks in Section VII. Finally, the paper is concluded in Section VIII. II. T HREAT M ODEL In this section, we describe the threat model we consider in our work. III. BACKGROUND NTP is in operation since 1985 and thus, is one of the oldest Internet protocols currently being used. Earlier versions of the protocol, NTPv1, NTPv2 and NTPv3 were described in RFC 1059 [16], RFC 1119 [17] and RFC 1305 [18] respectively while the current version of the protocol, NTPv4, is described in RFC 5905 [1] which is an Internet Standards Track document since June 2010. Despite of changing the protocol specification over the years to make the protocol more robust and accurate, various NTP implementations today do not completely follow the specification [14]. Instead, it is ntpd, the reference implementation of the protocol that “practically defines it” [5]. ntpd has been updated/modified several times in the last few decades to make it secure against various attack vectors found in the implementation over time. ntpd v4.2.8p13 is the most recent version launched on March 7th, 2019. A. NTP Packet Structure Different types of NTP packets exchanged during clock synchronization process have a common packet structure. This structure is shown in Figure 1. In this subsection, we describe the fields of this packet LI v Mode Stratum Poll Precision Root Delay Root Dispersion Reference ID Reference Timestamp Origin Timestamp Receive Timestamp Transmit Timestamp Key ID Message Digest Fig. 1. NTP packet structure structure essential to understand the working of our proposed attack. For a detailed explanation of NTP’s packet structure, reader is referred to RFC 5905 [1]. 3 Mode: This is a 3-bit field that represents the NTP mode (client/server, broadcast, etc.) to which the packet belongs. Stratum: This is an 8-bit field that represents the stratum of the NTP system. Stratum is a simple measure of the synchronization distance from the primary time source and its value ranges from 0 to 16 inclusive. Poll: This is an 8-bit field that represents the maximum interval between successive messages in log base 2 seconds. In case of a KoD packet (discussed later in Section III-D3), this field represents the minimum amount of time for which an NTP client should refrain itself from querying the server. Reference ID: This is a 32-bit field identifying a particular server or reference clock to which the NTP system is synchronized. Reference Timestamp: This is a 32-bit field that represents the time when system clock was last updated. Origin Timestamp (T1 ): This is a 32-bit field that represents the time at the client when a NTP request departed for the server. In broadcast mode, since the client does not send any NTP request and it is the server that sends unsolicited mode 5 packets at regular intervals, this field is set to NULL. Receive Timestamp (T2 ): This is a 32-bit field that represents the time at the server when the request arrived from the client. Since there is no corresponding request sent by the client in broadcast mode, this field is also set to NULL. Transmit Timestamp (T3 ): This is a 32-bit field that represents the time at the server when the NTP packet left for the client. Key ID: This is a 32-bit field that identifies the key used to authenticate the packet. There are multiple keys that can be configured on a NTP device and each key is identified by the Key ID. Message Digest: This is a 128-bit field that contains the MD5 hash calculated over the contents of the NTP packet using a symmetric key k. B. NTP Operation NTP is designed to operate under several modes: client/server (mode 3/mode 4), broadcast (mode 5), multicast (mode 5) and symmetric (mode 1 and mode 2) modes. All these modes are recommended to be processed by the same codepath of the NTP’s implementation [1]. NTP’s most common mode of operation is client/server mode in which an NTP client sends timing queries to a set of static NTP servers which are configured manually. Stratum s NTP systems act as servers for stratum s + 1 systems and provide time information to them. There are 16 levels in this stratum hierarchy such that stratum 0 refers to reference clocks which receive time from satellite navigation system while stratum 1 refers to those NTP systems which are at the root of the NTP hierarchy and get the time directly from reference clocks and thus, are the most accurate NTP systems. Also, a failure to synchronize clock is represented as stratum 16. Thus, as we go down the hierarchy, the time accuracy reduces as shown in Figure 2. Also, lower stratum NTP servers are given preference and large number of NTP clients usually synchronize their clock with these servers. In NTP’s broadcast mode, a set of clients listen to a broadcast server that periodically broadcasts timing information while in symmetric mode, NTP peers exchange timing information with each other. C. NTP’s Broadcast Mode Operation NTP’s broadcast mode is mostly used in environments having few NTP servers and large number of potential clients. An NTP server can be configured to periodically broadcast what is known as mode 5 NTP packets in the network. Similarly, NTP clients can be configured to accept and process these mode 5 packets. The broadcast server sends persistent broadcast association packets to the client and never demobilizes the association. On receiving these packets, the client creates an ephemeral association with the server that exists unless there is an error or timeout. While mobilizing the association, the broadcast NTP client changes its mode to client/server mode and calculates the path propagation delay between client and server. On page 6 of RFC 5905 [1], it is mentioned that: “It is useful to provide an initial volley where the client operating in client mode exchanges several packets with the server, so as to calibrate the propagation delay...” 4 Reference Clock Stratum 2 Peer Exchange Stratum 3 Accuracy Reduces Stratum 1 Reference Clock Fig. 2. NTP hierarchy While calculating path propagation delay in client/server mode, the client sends a mode 3 NTP query to the broadcast server. This query is sent by a client to obtain clock information from a server in order to synchronize its clock with the server’s clock. On receiving the mode 3 query, the server sends mode 4 response to the client. This response is sent by the server to provide its clock information to the client. Using this response, the client calculates the path propagation delay and reverts back to broadcast mode and creates an association with the broadcast server upon receiving subsequent mode 5 packets. After this, the client regularly synchronizes its clock with the help of mode 5 packets periodically sent by the broadcast server. D. Built-in Security Mechanisms in NTP NTP facilitates some built-in security mechanisms to counter variety of attacks against the protocol. These are as follows: 1) TEST2 [18]: NTP protocol requires the clients to check that the origin timestamp (T1 ) present in a server’s mode 4 response is the same as the transmit timestamp (T3 ) present in the corresponding mode 3 query sent by the client earlier. In this way, an off-path malicious client, that cannot observe the communication between the NTP client and the server, does not know the timestamp and thus can not spoof the packets. This is called as TEST2. It is to be noted that all NTP packets have UDP source port 123 instead of random source port numbers. That is the reason port number can not be used as a nonce to match a mode 4 response with the corresponding mode 3 query. 2) Panic Threshold and Step Threshold [1]: RFC 5905 defines a panic threshold PANICT and suggests that if the time difference (known as offset and discussed later in Section IV-A) between an NTP client’s clock and an NTP server’s clock to which the client is attempting to synchronize is greater than PANICT, NTP program should quit. On page 44 of RFC 5905, it is mentioned that: “PANIC means the offset is greater than the panic threshold PANICT (1000 s) and SHOULD cause the program to exit” This threshold prevents such attacks where a malicious client can attempt to tell a client to alter its local clock by a very large value so that the malicious client can create scenarios such as DNS cache and TLS certificate validity expiry which require time to be shifted by big steps (days or even years) in the past or future. RFC 5905 also defines a step threshold and suggests that a NTP client should accept a time shift larger than the step threshold (125 ms by default) but smaller than PANICT (1000 s by default). 5 3) Kiss-o’-Death (KoD) Packet [1]: RFC 5905 describes the use of a special packet called KoD to inform clients to stop sending packets that violate server access controls. For this purpose, the protocol specification defines several kiss codes [1] which must be inspected by recipient clients and take the action accordingly. One such kiss code is ’RATE’ which asks a recipient client to reduce the rate with which it is sending mode 3 queries to the server. On page 24 of RFC 5905, it is mentioned that: “Rate exceeded. The server has temporarily denied access because the client exceeded the rate threshold.” 4) Authenticated NTP’s Broadcast Mode: An NTP client listens to broadcast mode 5 packets sent by any NTP broadcast server in the network so an adversary can send mode 5 NTP packets from a spoofed IP address and the client accepts it. Moreover, the origin timestamp field in mode 5 NTP packet sent by broadcast server is always NULL as NTP client does not send any query for broadcast packets. As a result, TEST2 that checks if the origin timestamp and the transmit timestamp present in the most recent query client sent to the server is same, is not applicable in the broadcast mode. Due to this, NTP client is unable to validate the received mode 5 packets. Thus, NTP’s broadcast mode is vulnerable to identity spoofing attacks where malicious client can spoof the IP address of a broadcast server and send packets on its behalf. To address this issue, RFC 5905 [1] recommends that NTP implementations should have some authentication mechanism to validate mode 5 NTP packets. On page 32 of RFC 5905, it is mentioned that: “There is no specific requirement for authentication; however, if authentication is implemented, then the MD5-keyed hash algorithm described in [RFC1321] must be supported.” The authentication scheme appends an MD5 hash obtained by using a symmetric key k and NTP packet contents to the Message Digest field of NTP packet as shown in Figure 1. IV. P ROPOSED ATTACK We found a vulnerability (CVE-2018-8956) in NTP’s broadcast mode which can be exploited to launch an attack that can prevent a client configured in broadcast mode from synchronizing its clock with an NTP broadcast server. In this section, we first discuss the protocol vulnerability and how it can be exploited to launch the attack. Subsequently, we describe the procedure of attack execution in NTP’s unauthenticated and authenticated broadcast modes. A. Vulnerability in the Protocol NTP packets exchanged between a client and server include four timestamps - Origin Timestamp (T1 ) that determines client’s time when it sent the request to the server, Receive Timestamp (T2 ) that determines server’s time when it received the request sent by the client, Transmit Timestamp (T3 ) that determines server’s time when it sent the response to the client and Destination Timestamp (T4 ) that determines client’s time when it received the response sent by the server1 . NTP uses these timestamps to calculate Offset (θ) which represents the time difference between the client’s and server’s clock and is given by 1 (1) θ = ((T2 − T1 ) + (T3 − T4 )) 2 If the calculated offset θ is greater than the panic threshold PANICT, according to RFC 5905, ntpd should quit with a diagnostic message to the system log. However, this creates surface for on-path Small-stepbig-step attack [5]. This issue was disclosed in CVE-2015-5300 and ntpd v4.2.8p5 and versions released later were patched to prevent this attack. We also tested four most recent versions of ntpd - v4.2.8p10, v4.2.8p11, v4.2.8p12 and v4.2.8p13 - and found that these versions do not quit on receiving a broadcast mode 5 packet whose T3 is set to a timestamp such that the calculated θ > PANICT. However, the change in the implementation creates surface for another vulnerability as these versions start recalculating path 1 T4 is not present in the NTP packet structure and the client retrieves this timestamp directly from its own clock. 6 propagation delay by exchanging mode 3 and mode 4 packets with the NTP server on receiving mode 5 packets whose T3 is set to a timestamp such that the calculated θ > PANICT. Thus, to exploit this vulnerability, a malicious client can send such mode 5 packets to the victim client by spoofing the IP address of the genuine broadcast server. On receiving these mode 5 packets, the victim client starts sending mode 3 packets to recalculate the path propagation delay while on the other hand, the malicious client keeps sending large number of mode 3 packets to the broadcast server by spoofing the IP address of the victim client. As a result, the broadcast server starts responding with KoD packets (instead of mode 4 responses) having ’RATE’ code in response to the genuine mode 3 packets sent by the broadcast client. Since broadcast client does not receive mode 4 responses from the server, it is not able to calculate the path propagation delay. As a result, the broadcast client is not able to synchronize its clock with the broadcast server. Here arises a question - Can malicious client simply send spoofed KoD packets to the victim client as if they are from the broadcast server instead of inducing them from broadcast server to the victim client? The answer to this is ntpd v4.2.8p4 and later implementations use origin timestamp (T1 ) as a nonce to authenticate KoD packets [5]. Since malicious client (assuming off-path) does not know this nonce, it can not send KoD packets to the victim client which are spoofed to look like they are coming from the broadcast server. In fact this was a vulnerability in ntpd v4.2.8p3 and prior implementations which accept a KoD packet even if its origin timestamp is bogus [5]. After disclosure, the vulnerability was patched in ntpd v4.2.8p4 and later implementations. B. Preventing Time Synchronization in Unauthenticated Broadcast Mode Consider a network topology having five entities as shown in Figure 3 - one ith stratum NTP broadcast server (Bs ), two (i + 1)th stratum victim clients (Vc1 and Vc2 ) configured to accept mode 5 NTP packets, one off-path malicious client (Mc ) and one genuine client (Gc )- such that Bs , Vc1 and Vc2 are part of the broadcast network N1 while Mc and Gc are part of another network N2 on the Internet. Since the victim clients and malicious client are part of different networks in this scenario, the malicious client is off-path. Here, Gc is controlled by malicious client and its only purpose is to confirm that Vc1 is unable (MC) Malicious Client Genuine Client Internet ( V 1C ) (BS ) Broadcast Server Broadcast Network ( GC ) Victim Client 1 Victim Client 2 ( V C2 ) Fig. 3. Topology for attack description to synchronize its clock with Bs while the attack is going on. Launching the Attack: The steps involved while launching the attack are as follows: 1. In the first step, Vc1 is let to successfully synchronize its clock with Bs . Vc1 continuously listens to the mode 5 packets sent by Bs at regular intervals. As soon as it receives the first mode 5 packet, it calculates the path propagation delay by exchanging mode 3 and mode 4 packets with Bs . After calculating the path propagation delay, Vc1 reverts back to the broadcast mode and synchronizes its clock successfully. 2. Mc sends mode 5 packets to Vc1 at regular intervals which are spoofed to look like they are coming 7 from Bs . T1 and T2 in these mode 5 packets are set to zero while T3 is set to a timestamp such that θ calculated by client is greater than PANICT. Few moments later, Mc starts sending mode 3 packets to Bs at regular intervals which are spoofed to look like they are coming from Vc1 . 3. On receiving spoofed mode 5 packets sent by Mc in previous step, NTP daemon of Vc1 calculates θ using Equation 1. Since θ > PANICT, the daemon starts sending mode 3 NTP queries to Bs to recalculate the path propagation delay. 4. Since Bs continuously receives spoofed mode 3 NTP queries sent by Mc in Step 2, Bs sends KoD packets instead of valid mode 4 packets to Vc1 in response to its mode 3 queries sent in Step 3 due to which Vc1 is not able to calculate the path propagation delay. As a result, Vc1 is not able to synchronize itself with Bs . The exchange of various messages and their respective time of transmission for the successful execution of proposed attack are shown in Figure 4. Victim Client 1 (V C ) 1 Broadcast Server (BS ) Malicious Client ( M C ) Initializes and starts listening mode 5 packets Sends mode 5 packet Sends mode 3 queries Sends mode 4 responses Calculates path propagation delay Starts sending spoofed mode 5 packets at regular intervals Synchronizes successfully Calculates offset Offset > PANICT so restart calculating delay Starts sending large number of spoofed mode 3 packets at regular intervals Sends mode 3 queries Sends KoD packets Rate of mode 3 packets > threshold Not able to calculate delay Fails to synchronize Fig. 4. Exchange of messages while launching the attack Confirming Attack Success: As per protocol specification [1], every NTP host acts as a client for a set of servers and as a server for a set of clients. For example, in Figure 2, an NTP host at stratum 2 acts as a client for a stratum 1 NTP host but as a server for a stratum 3 NTP host. Thus if an NTP host receives a mode 3 query from an NTP client attempting to synchronize its clock, it acts as a server and sends back a mode 4 response to the client. This mode 4 response contains a field reference timestamp as shown in Figure 1. This field represents the time when system clock was last updated. In order to confirm that Vc1 is no longer able to synchronize itself with Bs , Gc sends genuine mode 3 NTP queries to Vc1 at regular intervals and in return, Vc1 sends back mode 4 NTP responses. In all these responses, if reference timestamp remains same, it means that Vc1 is not able to synchronize itself with Bs . Targeting other clients: Following the above steps and by placing appropriate source and destination IP addresses in spoofed mode 3 and mode 5 packets, an adversary can attack any client in the target broadcast domain. 8 C. Preventing Time Synchronization in Authenticated Broadcast Mode To describe the attack procedure in NTP’s authenticated broadcast mode, we consider two different scenarios - 1) Mc is part of the broadcast network (i.e. on-path) N1 as shown in Figure 5 and 2) Mc is not part of the broadcast network (i.e. off-path) but it controls a slave S in the broadcast network N1 as shown in Figure 6. We now discuss how the proposed attack works in both these scenarios. Broadcast Server (BS ) Key k Victim Client 2 (V 2C ) Key k Key k Key k Malicious Client Victim Client 1 (M C ) (V 1C ) Broadcast Network Fig. 5. Malicious client is part of the broadcast network Broadcast Server (BS ) Key k Victim Client 2 (V C2 ) Key k Capturing the packets Malicious Client Slave Key k Victim Client 1 (M C ) (V 1C ) Broadcast Network Fig. 6. Malicious client controls a slave in the broadcast network 1. When Mc is part of the broadcast network N1 : In this scenario, since Mc is part of the broadcast network to which Bs , Vc1 and Vc2 belong, it also possesses the key used to authenticate NTP messages [19], [20]. Thus, Mc can spoof identity of Bs and send broadcast mode 5 packets containing bogus time to Vc1 and Vc2 . Similarly, Mc can also spoof identities of Vc1 and Vc2 to send large number of mode 3 packets to Bs . These packets are accepted by the destination entities as the MD5 hash appended to the packets are generated using k. Thus, by following the attack procedure discussed in Section IV-B, Mc can prevent both Vc1 and Vc2 from synchronizing their clock with Bs . 2. When Mc controls a slave in N1 : In this scenario, Mc controls a slave in N1 that can capture one copy each of type mode 5 packet2 sent by Bs and mode 3 query sent by either Vc1 or Vc2 to Bs 3 . Once slave captures the required packets, it forwards them to Mc . After receiving copies of mode 3 and mode 5 packets, Mc can launch the attack from anywhere in the world but at a time Tf such that θ 2 3 Since mode 5 packet is a broadcast packet, the slave also receives this packet as it is part of the same network. Unlike unauthenticated mode, the malicious client needs a copy of these packets to meet authentication check with k. 9 calculated by Vc1 at Tf is greater than PANICT. To target Vc1 , Mc continuously sends copies of mode 5 and mode 3 queries at regular intervals. The copies of mode 5 NTP packets are sent to IP address of Vc1 with source IP address of Bs while copies of mode 3 query are sent to Bs with source IP address of Vc1 . Since Mc does not change any field in the NTP header of captured mode 5 and mode 3 packets, the destination entities of these packets accept it as the MD5 hash appended to the packets is correct. Thus, the attack procedure discussed in Section IV-B prevents Vc1 from synchronizing itself with Bs in NTP’s authenticated broadcast mode also. Likewise, Mc can prevent Vc2 from synchronizing itself with Bs by placing appropriate source and destination IP address in IP header of mode 5 and mode 3 NTP packets. The exchange of various messages and their respective time of transmission for the successful execution of proposed attack against Vc1 are shown in Figure 7. Broadcast Server (BS ) Victim Client 1 (V 1C ) Slave Malicious Client (M C ) Initializes and starts listening mode 5 packets Sends mode 5 packet Sends mode 3 queries Captures one mode 5 packet Sends the captured mode 5 packet Sends mode 4 responses Sends the captured mode 3 query Calculates path propagation delay Synchronizes successfully Captures one mode 3 query Starts replaying copies of mode 5 packets at regular intervals Calculates offset Offset > PANICT so restart calculating delay Starts replaying multiple copies of mode 3 packets at regular intervals Sends mode 3 queries Rate of mode 3 Sends KoD packets packets > threshold Not able to calculate delay Fails to synchronize Fig. 7. Exchange of messages while launching the attack in second scenario V. E XPERIMENTS AND R ESULTS We tested the proposed attack in a real network setup. In this section, we first describe the experiments performed to test the proposed attack and then we present the attack surface results obtained from scanning the entire IPv4 address space on Internet. A. Testbed Setup The setup on which we tested our proposed attack is shown in Figure 8. It had three entities - an off-path malicious client, victim client and broadcast server. The broadcast server and victim client were part of same broadcast network while the malicious client was connected to another network. All the entities in the testbed were configured on computers running Kali Linux 2.0 operating system and having Core i7 processor with 4 GB of physical memory. The details about various entities and how they were configured are as follows: 1. Broadcast Server: We installed ntpd v4.2.8p13 on the broadcast server and configured it by adding broadcast keyword and network broadcast address in NTP configuration file. A symmetric key was also configured in the configuration file for authentication purpose. This server was synchronized to an external stratum 2 NTP server on the Internet using one of its network interface while another interface 10 Lower Stratum NTP Server Internet Broadcast Server (BS ) (M C ) (V 1C ) Victim Client 1 Malicious Client ISP 1 ISP 2 Broadcast Network 0:01:39 2:30:23 Victim client resynchronized successfully 0:01:38 Attack stopped 0:01:37 1. Malicious client kept on sending spoofed mode 5 and mode 3 packets. 2. Victim client kept on attempting to recalculate PPD. 3. Broadcast server kept on sending mode 5 and KoD packets. 1st KoD packet sent by broadcast server to victim client 0:01:33 Victim client starts recalculating PPD 0:00:31 Two mode 3 packet copies sent by malicious client to broadcast server Victim client’s first attempt to calculate PPD 0:00:24 Attack started – 1st mode 5 packet copy sent by malicious client to victim client 0:00:22 Victim client synchronized successfully after initialization 0:00:00 0:00:21 Mode 5 packet received by victim client Mode 5 packet sent by broadcast server Victim client’s NTP started Fig. 8. Testbed setup 2:33:20 Time (h:mm:ss) --> Fig. 9. Timing of various events. (PPD: Path Propagation Delay) was used to send mode 5 NTP packets on the internal network. 2. Victim Client: We also installed ntpd v4.2.8p13 on the victim client and configured it by adding broadcastclient keyword and the required symmetric key in its NTP configuration file. 3. Malicious Client: The malicious client had two python scripts to send mode 5 and mode 3 NTP packets at regular intervals. In particular, we used Scapy [21] to send these packets. The first python script was configured to send copies of mode 5 packet at a rate of 1 packet per second while the second python script was configured to first send two mode 3 packets to broadcast server and then at a rate of only 1 packet per 10 seconds. Before the attack execution started, we let the victim client to synchronize its clock with the broadcast server. In the meantime, we captured one packet each of type mode 5 and mode 3 from the communication between broadcast server and victim client. These packets were then provided to the designated malicious client so that the packets could be sent by it later. B. Attack Execution We executed the attack for approximately 2.5 hours on the testbed setup. Figure 9 shows the relative timing of various events as seen in the experiment. The broadcast server sent a mode 5 packet at 0:00:21 which victim client received at 0:00:22. Subsequently, the victim client made its first attempt to calculate path propagation delay at 0:00:24. After this, the victim client successfully synchronized its clock with the broadcast server at 0:00:31. The malicious client started the attack execution at 0:01:33 by sending mode 5 packets to the victim client which were spoofed to look like they are coming from the 11 broadcast server. At 0:01:37, the malicious client sent a burst of two mode 3 packets to the broadcast server which were spoofed to look like they are coming from the victim client. This forced the broadcast server to trigger the rate-limiting mechanism and send a KoD packet to the victim client. Meanwhile, at 0:01:38, the victim client also sent mode 3 packets to the broadcast server in order to recalculate the path propagation delay. At 0:01:39, the broadcast server sent first KoD packet with polling interval of 64 seconds to the victim client due to the rate with which it was receiving mode 3 queries (from both victim client and malicious client). Between 0:01:39 and 02:30:23, the malicious client kept on sending spoofed mode 3 and mode 5 packets to the broadcast server and victim client respectively in order to continue the attack while the broadcast server kept on sending genuine mode 5 packets and KoD packets to the victim client. Meanwhile, the victim client made 30 (unsuccessful) attempts4 to calculate the path propagation delay in order to synchronize its clock with the broadcast server. At 02:30:23, the malicious client stopped the attack execution and subsequently, after 177 seconds, the victim client could successfully resynchronize its clock with the broadcast server in its 31st attempt. During the attack execution, the number of different types of NTP packets sent by each entity is shown in Table I. TABLE I NTP PACKETS SENT BY EACH ENTITY. Entity Malicious Client Victim Client Broadcast Server Mode 3 887 125 NA (NA: N OT A PPLICABLE ) Mode 5 8388 NA 138 KoD NA NA 886 C. Effectiveness of Attack in Authenticated Multicast Mode RFC 5905 [1] allows NTP clients and server to operate in multicast mode as well. The multicast mode operation is similar to that of the broadcast mode. Our proposed attack can also prevent a client configured in multicast mode from synchronizing itself with a multicast NTP server. To test the attack in multicast NTP mode, we configured victim client to listen mode 5 packets by adding multicastclient keyword and IPv4 multicast group address 224.0.1.1 in its NTP’s configuration file. We also modified NTP broadcast server’s configuration file by replacing the network broadcast address with 224.0.1.1 to send mode 5 NTP packets on this address. NTP daemon of broadcast server and victim client were then restarted to apply the changes. We then let the broadcast server and victim client synchronize to external stratum 2 server on the Internet and broadcast server respectively. To launch the attack, malicious client simply sent copies of mode 5 and mode 3 NTP packets with appropriate source and destination IP addresses as discussed earlier. On receiving mode 5 packets, victim client made several attempts to recalculate the path propagation delay, however, several mode 3 packets sent by the malicious client to broadcast server prevented the victim client to calculate the delay each time. Thus, the proposed attack was found to be effective in NTP’s authenticated multicast mode also. D. Attack Surface To quantify the effect of proposed attack, it is important to know the attack surface space. Thus, we scanned entire IPv4 address space5 to determine the usage of NTP’s broadcast mode in the wild. We also measured the usage of different ntpd versions on Internet. In this subsection, we discuss the scanning testbed setup, measurement procedure and the obtained results. 4 5 Victim client, on an average, sends four mode 3 packets to calculate path propagation delay in each attempt. excluding private and reserved IP addresses (covering approximately 13.8% of the entire IPv4 address space). 12 1) Setup: We performed the Internet wide scan using a Virtual Machine (VM) on Google Cloud Platform. This VM was running Ubuntu 18.04 operating system and having one virtual CPU with 6.5 GB of physical memory. This VM also had Python 2.7.0 and Scapy [21] libraries to send NTP control packets in Internet using raw sockets. We also installed tcpdump to capture the resulting NTP traffic at VM. The captured NTP traffic was then processed and parsed using Python and Scapy libraries to extract details such as NTP association type, ntpd version, stratum level, etc. 2) Measurement Methodology: We first executed peers command on a machine and captured the resulting NTP control packets. The peers command is used to obtain a list of all associations used by an NTP client. Once we had the required packets, we used a python script that creates raw sockets and sends the payload of captured NTP control packets to the entire IPv4 address space. We captured the resulting NTP traffic using tcpdump in the form of a pcap file. This measurement was taken from September 20th to September 22nd, 2019 and we obtained the responses from 1,171,607 IP addresses. After this, we rescanned these responding IP addresses using readvar command. This command, when executed for a particular association, returns the information such as reference ID, stratum, reference timestamp, mode of association, etc. This measurement was taken between September 23rd and September 24th, 2019. We obtained the responses from 722,217 IP addresses and we consider only these addresses here. 3) Results: The results for the measurement of broadcast association usage in the wild are shown in Table II. On a side note, we also measured the usage of symmetric as well as client/server associations TABLE II U SAGE OF DIFFERENT NTP MODES IN I NTERNET Detail Hosts with at least 1 broadcast association Total broadcast associations Hosts with at least 1 symmetric association Hosts with at least 1 client/server association Total symmetric associations Total client/server associations Count 2740 8090 55712 668,097 130,249 1,273,892 in the wild. The results for these measurements are also shown in Table II. Measurement of ntpd versions being used in the Internet: We also measured the usage of different ntpd versions in the Internet. For this purpose, we rescanned 722,217 IP addresses that responded in the previous measurement using readvar command. This command, when executed for a system as a whole, returns information such as ntpd version, operating system, etc. This measurement was taken from September 25th to September 26th, 2019 and we obtained the responses from 648,187 IP addresses. Out of these 648,187 IP addresses, only 496,079 IP addresses returned responses having version information. The results for this measurement is shown in Table III. We can notice from the table that the most ntpd VERSIONS BEING USED IN I NTERNET. Version Count 4.2.0 18024 4.2.8 13476 TABLE III Others: E ITHER OTHER OLDER VERSIONS OR UNREADABLE VERSION NUMBER 4.2.6 8166 4.1.1 7308 4.2.4 1203 4.2.7 569 Just “ntpd v4” 446620 Others 713 Total 496,079 recent ntpd version 4.2.8 is the second most popular (after 4.2.0) in the Internet. Since we found the vulnerability in four latest ntpd 4.2.8 subversions - 4.2.8p10, 4.2.8p11, 4.2.8p12 and 4.2.8p13, we also measured how many systems on the Internet are using these subversions. These results are shown in Table IV in descending order. Measurement of ntpd versions being used by broadcast clients in the Internet: We also measured which different ntpd versions are being used by broadcast clients in the Internet. Out of 2740 IP addresses 13 TABLE IV R ECENT SUBVERSIONS OF ntpd 4.2.8 BEING USED IN I NTERNET. Others: E ITHER OTHER SUBVERSIONS OR JUST ntpd 4.2.8 Version 4.2.8p10 4.2.8p12 4.2.8p11 4.2.8p13 (latest) Others Total Count 2881 2333 1960 1756 4546 13476 using at least one broadcast association, we obtained response containing version information from 1552 IP addresses only. The results for this measurement are shown in Table V. Similarly, the results for the usage of ntpd subversions 4.2.8p10, 4.2.8p11, 4.2.8p12 and 4.2.8p13 by NTP broadcast clients in the Internet are shown in Table VI. TABLE V ntpd VERSIONS BEING USED BY SYSTEMS WITH AT LEAST 1 BROADCAST ASSOCIATION IN I NTERNET. VERSIONS OR UNREADABLE VERSION NUMBER Version Count 4.2.8 23 4.1.0 4 4.2.0 3 4.1.1 2 4.2.6 1 Just “ntpd v4” 1519 Others: E ITHER OTHER OLDER Total 1552 TABLE VI R ECENT SUBVERSIONS OF ntpd 4.2.8 BEING USED BY SYSTEMS WITH AT LEAST 1 BROADCAST ASSOCIATION IN I NTERNET. Others: E ITHER OTHER SUBVERSIONS OR JUST ntpd 4.2.8 Version 4.2.8p10 4.2.8p13 (latest) 4.2.8p12 4.2.8p11 Others Total Count 10 3 5 1 4 23 E. How Significant is the Attack Surface? We can notice from Table II that the number of broadcast associations (i.e. 8090) is quite less as compared to client/server associations (i.e. 1,273,892) and thus, one can consider that the attack surface is insignificant. However, we argue that the actual attack surface depends not only on the number of broadcast associations but also on the stratum of NTP broadcast hosts on Internet. This is because if the victim NTP broadcast host is under attack and is not able to synchronize its clock with a broadcast server, eventually it will not be able to provide time information to other NTP hosts for whom it is acting as an NTP server. Thus, we performed a measurement study (using the output of same readvar command) to check the stratum of broadcast associations on the Internet and the number of NTP hosts synchronizing their clock time from these servers. Surprisingly, we found that 8088 out of 8090 broadcast associations are stratum 2 (considered as highly accurate) associations such that the number of stratum 3 NTP hosts taking time from these stratum 2 broadcast clients is 433. Subsequently, these stratum 3 NTP hosts provide time to stratum 4 NTP hosts and so on. Thus, if the lower stratum NTP hosts are attacked, it will directly affect the whole NTP hierarchy which makes the attack surface significant. We would also like to point that most of the NTP clients on the Internet do not respond to the readvar command that we used to measure the attack surface. This is because readvar command is used to launch popular NTP amplification/reflection attack [8]. Due to this shady image, network administrators 14 usually disable this remote query or deploy firewalls to drop it [13]. This is one of the primary reason why only 722,217 out of 1,171,607 NTP clients (i.e., only 61.64 %) on Internet responded back to readvar command. Also, we showed that only 23 out of 2740 broadcast NTP clients (i.e., 1.20 %) in Internet responded back with exact version information. Remaining 1519 broadcast NTP clients returned back response with version as “ntpd v4” (superset for ntpd v4.*.*p*) only. Moreover, NTP’s broadcast mode is typically implemented when the broadcast server and clients are present behind Network Address Translation (NAT) boxes which prevents them from being scanned from external machines like ours. Thus the exact number of NTP broadcast clients in the wild could not be measured and the presented results show only the floor value of the overall attack surface. Also, the proposed attack is effective against latest ntpd versions and sooner or later, several NTP clients in Internet will update their ntpd implementations which eventually makes them vulnerable to the attack. VI. P OSSIBLE C OUNTERMEASURES In the last two sections, we showed that our proposed attack can prevent an NTP client from synchronizing its clock with an NTP broadcast server and that the overall attack surface in the Internet can not be neglected. Thus, we also suggest possible mitigation approaches that can be deployed to counter the proposed attack until the vulnerable protocol implementations are appropriately patched. These countermeasures are as follows: Out-of-band Path Propagation Delay Calculation: Our proposed attack requires malicious client to send several mode 3 NTP queries to broadcast server which are spoofed to look like they are coming from a genuine NTP client. These mode 3 queries cause broadcast server to send KoD packets instead of mode 4 responses to the genuine client. This results into genuine client’s failure to calculate path propagation delay. For this reason, we suggest that NTP broadcast clients should use an out-of-band path propagation delay calculation technique. For instance, broadcast clients can exchange a couple of TCP or UDP packets with the broadcast server at regular intervals to calculate mean round-trip time. However, this recommendation requires making changes to RFC 5905. Moreover, this approach leads to higher bandwidth consumption at both broadcast server and client side. Relying Exclusively on Broadcast Mode is Harmful: The easiest way to prevent proposed attack is not to exclusively rely on broadcast mode for synchronization purpose. Instead, it should be made sure that the clients are backed by one or more NTP servers using other modes of NTP operation such as client/server mode or symmetric mode. In this way, the NTP clients have the option of choosing other existing associations when the broadcast association fails. Prevent IP Spoofing: Since the proposed attack requires malicious client to use spoofed IP addresses to send mode 5 and mode 3 packets to victim client and broadcast server respectively, any IP spoofing mitigation approach can prevent the proposed attack. Thus, techniques such as ingress/egress filtering [22], [23], [24], [25] can be implemented on the border routers to block malicious traffic. However, this approach will fail to mitigate the attack if it is launched within a local network. Limiting Access of NTP Broadcast Clients: RFC 5905 suggests “to limit the access of NTP clients to known or trusted NTP broadcast servers as it will prevent malicious traffic from reaching the NTP clients” [1]. Due to this, the malicious client will not be able to send spoofed mode 5 packets to the victim client which will subsequently prevent the attack. VII. P RIOR W ORK In this section, we describe earlier works wherein authors presented attacks against clock synchronization using NTP. Subsequently, we also discuss known defense approaches to counter these attacks. 15 A. Attacks against NTP Malhotra and Goldberg [13] proposed two attacks against NTP’s broadcast mode. The first attack is a replay attack wherein a Man-in-the-Middle (MitM) malicious client between an NTP broadcast server and a victim client replays a contiguous sequence of broadcast packets at regular interval to the victim client. This causes the victim’s clock to stuck at a particular time. The second attack is a DoS attack wherein a malicious client can cause an error in the NTP operation of victim client by sending a badly authenticated mode 5 packet. As a result, the victim client breaks its association with the broadcast server. Following attack disclosure, appropriate patches have been added to ntpd v4.2.8p6 and later versions to mitigate these attacks [13]. In another work [5], authors proposed several attacks against NTP’s unauthenticated client/server mode. To launch the first attack [5], a malicious client sends bogus small time shifts to a victim client and then, when the malicious client is ready, it sends a big time shift to the victim client to create DoS. Following attack disclosure, vulnerable ntpd versions were patched to mitigate this attack [5]. To launch the second variant, an off-path malicious client sends a spoofed KoD packet to the victim NTP client for each of the client’s pre-configured NTP servers. On receiving KoD packets, the client immediately stops sending NTP packets to the servers due to which it is not able to synchronize its local clock. After public disclosure, newer ntpd versions are made resilient to this attack by patching the origin timestamp validation process. In one of the attacks, authors also showed how certain IPv4 fragmentation policies used by a client’s and server’s operating systems can be exploited to hijack an unauthenticated NTP connection established between the client and server. In [14], authors discussed an attack wherein a malicious client obtains the transmit timestamp T3 of a pending mode 3 query sent by a client to a NTP server and then crafts a fake mode 4 response having origin timestamp as T3 and bogus time information. Since this response is having valid origin timestamp, the client accepts and processes the response due to which its clock is shifted to a wrong time. This vulnerability is not yet patched [14] and thus, the current versions of ntpd are still vulnerable. One more vulnerability was discussed in this work wherein a malicious client can bypass TEST2 by spoofing server’s mode 4 response packets with their origin timestamp set to zero. Following attack disclosure, this vulnerability has been fixed in ntpd v4.2.8p9 and later versions [14]. B. Defense Approaches Cryptographic Techniques: Some approaches [14], [26] use cryptographic techniques to authenticate NTP packets. However, NTP traffic is very rarely authenticated in practice [5] because of various reasons such as cumbersome key distribution mechanism, weaknesses in the Autokey protocol [27] for public-key authentication, etc. [19]. This leads to the development of NTPsec [28], [29]. Unfortunately, the adoption of NTPsec is still very slow and moreover, authentication and encryption do not mitigate MitM attacks as an MitM adversary can simply drop traffic destined to port 123 (default for NTP). Path Redundancy: A class of work in the literature utilize path redundancy on the Internet to avoid MitM adversaries [30], [31]. Under this approach, multiple paths on the Internet are used to connect NTP clients and servers. Thus, even if one of the paths between an NTP client and a server is compromised, the client is able to synchronize its clock by exchanging NTP packets over other paths. The drawback of this approach is that it can not mitigate attacks which do not require a MitM position (our proposed attack, for example). Server Redundancy: Deutsch et al. [32] proposed a new NTP client Chronos which first generates server redundancy by creating large server pools and then carefully samples servers in these pools. Since Chronos synchronizes its clock with the help of large server pools, even a malicious client with MitM position can not stop the client from obtaining correct time information from other servers. As a result, this approach is resilient to on-path attacks. In case of off-path attacks, Chronos’ clock selection algorithm 16 rejects wrong time information received from a malicious adversary as it differs from the clock values of servers present in the pool. Thus, Chronos is resilient to off-path attacks as well. However, this setup requires changes in the core NTP infrastructure of the Internet to counter the attacks. VIII. C ONCLUSION In this paper, we proposed a new attack that can prevent a client from synchronizing its clock to a broadcast NTP server. We tested the proposed attack in real network and reported the results. The proposed attack was found to be effective in both authenticated and unauthenticated broadcast and multicast modes. We also discussed how the proposed attack can render all the broadcast clients in the network unsynchronized. We measured the attack surface by scanning the entire IPv4 address space using extensive experiments and showed that several highly accurate low stratum hosts on Internet are vulnerable to the attack. We also suggested few countermeasures that can be deployed as a first line of defense to mitigate the proposed attack. Moreover, we are also working on an effective prevention approach to counter this attack. We believe that our new attack disclosure will motivate researchers in the security community to closely evaluate the protocol specification further, identify new vulnerabilities and propose appropriate patches or defense mechanisms to make the protocol and its implementations secure and robust. R EFERENCES [1] D. L. Mills, J. Martin, J. Burbank, and W.Kasch, “(RFC 5905) Network Time Protocol Version 4: Protocol and Algorithms Specification,” 2010. [2] J. Klein, “Becoming a Time Lord - Implications of Attacking Time Sources. Shmoocon Firetalks 2013,” 2013. [Online]. Available: https://www.youtube.com/watch?v=XogpQ-iA6Lw [3] D. L. Mills, Computer Network Time Synchronization: The Network Time Protocol on Earth and in Space, Second Edition, 2nd ed. CRC Press, Inc., 2010. [4] J. Selvi, “Breaking SSL Using Time Synchronisation Attacks. DEFCON’23,” 2015. [Online]. Available: https://www.youtube.com/ watch?v=hkw9tFnJk8k [5] A. Malhotra, I. E. Cohen, E. Brakke, and S. Goldberg, “Attacking the Network Time Protocol,” in Proceedings of the Network and Distributed System Security Symposium (NDSS), 2016, pp. 1–15. [6] L. Bicknell, “NTP Issues Today. Outages Mailing List,” 2012. [Online]. Available: https://mailman.nanog.org/pipermail/nanog/ 2012-November/053449.html [7] Y. R. M. T. Blog, “Has your Windows Server 2003 Domain Controller time gone back to year 2000 (like Y2K)?” 2012. [Online]. Available: https://blogs.technet.microsoft.com/yongrhee/2012/11/19/ has-your-windows-server-2003-domain-controller-time-gone-back-to-year-2000-like-y2k/ [8] J. Czyz, M. Kallitsis, M. Gharaibeh, C. Papadopoulos, M. Bailey, and M. Karir, “Taming the 800 Pound Gorilla: The Rise and Decline of NTP DDoS Attacks,” in Proceedings of the Internet Measurement Conference (IMC’14), 2014, pp. 435–448. [9] N. Tripathi and N. Hubballi, “Exploiting DHCP Server-side IP Address Conflict Detection: A DHCP Starvation Attack,” in Proceedings of the International Conference on Advanced Networks and Telecommuncations Systems (ANTS), 2015, pp. 1–3. [10] N. Tripathi, N. Hubballi, and Y. Singh, “How Secure are Web Servers? An Empirical Study of Slow HTTP DoS Attacks and Detection,” in Proceedings of the International Conference on Availability, Reliability and Security (ARES), 2016, pp. 454–463. [11] N. Tripathi and N. Hubballi, “Slow Rate Denial of Service Attacks against HTTP/2 and Detection,” Computers & security, vol. 72, pp. 255–272, 2018. [12] N. Hubballi and N. Tripathi, “A Closer Look into DHCP Starvation Attack in Wireless Networks,” Computers & Security, vol. 65, pp. 387–404, 2017. [13] A. Malhotra and S. Goldberg, “Attacking NTP’s Authenticated Broadcast Mode,” ACM SIGCOMM Computer Communication Review, vol. 46, no. 2, pp. 12–17, 2016. [14] A. Malhotra, M. Van Gundy, M. Varia, H. Kennedy, J. Gardner, and S. Goldberg, “The Security of NTP’s Datagram Protocol,” in Proceedings of the International Conference on Financial Cryptography and Data Security, 2017, pp. 405–423. [15] “NTP Software Downloads,” http://www.ntp.org/downloads.html. [16] D. L. Mills, “(RFC 1059) Network Time Protocol (Version 1) Specfication and Implementation,” 1988. [17] ——, “(RFC 1119) Network Time Protocol (Version 2) Specfication and Implementation,” 1989. [18] ——, “(RFC 1305) Network Time Protocol (Version 3) Specification, Implementation and Analysis,” 1992. [19] T. Mizrahi, “(RFC 7384 (informational)) Security Requirements of Time Protocols in Packet Switched Networks,” 2014. [Online]. Available: https://tools.ietf.org/html/rfc7384 [20] D. Sibold, S. Roettger, and K. Teichel, “draft-ietf-ntp-network-time-security-10: Network Time Security,” 2014. [21] Scapy. Welcome to Scapy’s Documentation! (2019) Https://scapy.readthedocs.io/en/latest/. [22] P. Ferguson and D. Senie, “(RFC 2827) Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing,” 2000. [23] H. Wang, C. Jin, and K. G. Shin, “Defense Against Spoofed IP Traffic Using Hop-Count Filtering,” IEEE/ACM Transactions on Networking, vol. 15, no. 1, pp. 40–53, 2007. 17 [24] C. Jin, H. Wang, and K. G. Shin, “Hop-Count Filtering: An Effective Defense Against Spoofed DDoS Traffic,” in CCS ’03: Proceedings of the 10th ACM Conference on Computer and Communications Security, 2003, pp. 30–41. [25] N. Hubballi and N. Tripathi, “An Event based Technique for Detecting Spoofed IP Packets,” Journal of Information Security and Applications, vol. 35, pp. 32–43, 2017. [26] B. Dowling, D. Stebila, and G. Zaverucha, “Authenticated Network Time Synchronization,” in Proceedings of the USENIX Security Symposium (USENIX Security’16), 2016, pp. 823–840. [27] D. M. Ed. B. Haberman, “(RFC 5906 (informational)) Network Time Protocol Version 4: Autokey Specification,” 2010. [Online]. Available: https://tools.ietf.org/html/rfc5906 [28] N. C. Team, “The Secure Network Time Protocol (NTPsec) Distribution,” 2019. [Online]. Available: https://docs.ntpsec.org/latest/ [29] A. Liska, NTP Security: A Quick-Start Guide. Apress, 2016. [30] T. Mizrahi, “Slave Diversity: Using Multiple Paths to Improve the Accuracy of Clock Synchronization Protocols,” in Proceedings of the International Symposium on Precision Clock Synchronization for Measurement, Control and Communication (ISPCS’12), 2012, pp. 1–6. [31] A. Shpiner, Y. Revah, and T. Mizrahi, “Multi-path Time Protocols,” in Proceedings of the IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication (ISPCS’13), 2013, pp. 1–6. [32] O. Deutsch, N. R. Schiff, D. Dolev, and M. Schapira, “Preventing (Network) Time Travel with Chronos,” in Proceedings of the Network and Distributed System Security Symposium (NDSS’18), 2018, pp. 1–15.