Should broadcast be robust to replay attacks? According to RFC 5905 (Mills et al., 2010), NTP’s “on-wire protocol ... resists replay of a server response packet.” This is supposed to be accomplished through what is called TEST1 in the protocol specification: Upon receipt of an NTP response packet, the NTP client matches the transmit timestamp in the current packet to that of the last response packet it received; if the timestamp matches, it marks the packet as duplicate and drops it. However, we now show that because broadcast mode does not impose TEST2, then TEST1 cannot provide sufficient protection against replay attacks, even when NTP packets are cryptographically authenticated.
a) Deja Vu: Our on-path time-sticking attack (CVE-2015-7973). Consider a man-
in-the-middle (MiTM) attack, where the attacker is positioned between the server and the victim client, and can intercept and replay a packet and prevent onward
transmission of the original packet, but does not possess the symmetric key that authenticates broadcast messages. We show that the protocol does not resist the following replay attack. The MiTM collects and records a contiguous sequence of server broadcast packets. (The attacker requires a sufficient number of these packets for the client to update its clock; this is because NTP requires a client to obtain between eight to hundreds of messages from a server before the client’s clock discipline algorithms synchronizes it to the server (Mills et al., 2010, Sec. 10-12).) He then replays this sequence of packets, over and over, to the victim client; the victim accepts the same time over and over, and thus gets stuck at a particular time. Notice that these are the authenticated packets from the broadcast server, and so they pass the authentication check on the client. Moreover, by replaying a sequence of packets, rather than just one packet, the attacker ensures that the replayed packets pass TEST1.
b) Our off-path time-shifting attack. If the attacker is one of the clients on the
broadcast network, or on an adjacent network that also gets the broadcast packets from the same broadcast server, it then shares the same symmetric key with the server as the victim client. In this case, the attacker possesses the same key as the server and therefore can simply forge authenticated NTP mode 5 packets and send them to the victim client. The attacker can then send the victim back/forward in time as discussed in Chapter 2, or can make him stick to a particular time.
Why do these attacks work? These attacks highlight the following weaknesses in NTP; a) The protocol specifies and defaults to the use of symmetric key cryptography for broadcast authentication, where all nodes share the same key and one/some of them could be malicious or may be compromised, b) an NTP client is unable to recognize that it is stuck in a particular time for long periods of time, and c) in the absence of TEST2, TEST1 doesn’t actually prevent replay in general—it just
prevents replay of the most recent packet. Our replay attack passes TEST1 because the client only matches the current transmit timestamp with that of the last packet. Experiments: As a proof-of-concept, we set up an ntpd v4.2.8p3 broadcast client and server using the configuration options broadcastclient and broadcast IP address range. Another machine on the same network behaves as MiTM and collects 12 mode 5 pack- ets and stores them. The MiTM then drops the original mode 5 packets to the victim and replays his previously collected set of mode 5 packets. The victim accepts the time after getting sufficient samples required for a server to pass the clock discipline
algorithms, gets into the ‘STEP’ mode4and clears the state variables for this associa-
tion. We continue this experiment for ≈ 4 hours and observe that the victim’s system clock is stuck at the same time.
Implications of the attack. A MiTM can use a replay attack to make the victim client get stuck at a particular time value forever. Moreover, a compromised machine on the same or adjacent subnet can or forge authenticated mode 5 packets and shift time forward or backward on the victim client. Shift time forward/backward has severe implications on security guarantees provided by various core Internet proto- cols, such as DNSSec, BGP, TLS, and authentication services that use Kerberos; see Chapter 2 for discussion.
3.4
Denial of Service Attacks
We now present an off-path denial-of-service attack that generically succeeds on any preemptable or ephemeral association that is cryptographically authenticated, includ- ing authenticated broadcast mode.
Preemptable and empheremal associations. NTP’s broadcast clients use an
4An NTP client enters ‘STEP’ mode whenever it needs to shift its clock by more than 125ms but
less than ≈ 16 min; our replay attack shifts the client back in time by more than 125ms, causing the client to enter STEP mode.
ephemeral association to listen to NTP mode 5 from a broadcast server; as discussed in Section 3.2, this association is automatically demobilized upon error or timeout.
NTP also supports preemptable associations (Mills, 2014), which are similar to ephemeral associations. Preemptable associations are mobilized if the ntpd client has the keyword “preempt” to the line in its configuration file that establishes a associa- tion with a particular server. Alternatively, the ntpd client may be preconfigured with the manycastclient or pool [pool address] options; in this case, the client establishes a preemptable association upon receipt of a server discovery packet. Preemptable associations are also demobilized upon error or timeout.
Our off-path DoS attack (CVE-2015-7979). An off-path attacker can easily cause
an error by sending mode 5 with bad cryptographic authentication (e.g., wrong key, mismatched key, incorrect message digest, etc.). The attacker sends one such error- causing packet for every legitimate response the client receives from the server, so that the client immediately tears down its association with the server. This way, the client never collects enough good NTP response to allow its clock discipline algorithms to update its local clock, resulting in a denial-of-service attack on the client.
Experiment. As a proof-of-concept, we set up ntpd v4.2.8p3 broadcast client and server using the configuration options broadcastclient and broadcast IP address range respectively. Once the client is synchronized with the broadcast server, another ma- chine which behaves as an off-path attacker sends badly-authenticated mode 5 packet to the client. The client immediately tears down the association with the server and clears all the state variables. Next, the client receives the legitimate packet from the broadcast server and again mobilizes the association. The attacker again sends the bad mode 5 packet and the client again tears down the association. The attacker keeps repeating this and the client never obtains enough consistent time samples from the server to allow it to update its system clock.
Implications a) An off-path attacker can deny NTP service to the broadcast client even when it uses cryptographic authentication. b) If the client is preconfigured to a bad timekeeper or one of the servers’ that the client is configured to is con- trolled/compromised by the attacker, then using this DoS attack, the client can pin the client to bad server that is controlled by him. The attacker can then send the client back/forward in time which has implications as mentioned in Section 3.3.