In this article I am going to illustrate how NTP is vulnerable to attacks like replay-delay attacks, MITM, and a very recent attack termed as NTP DdoS (which is a kind of amplification attack used to flood the intended target with a response from the NTP server that can be 350 times bigger than the original request), and how the NTP security model addresses some of these concerns and future design considerations.
Network Time Protocol (NTP): NTP is used to synchronize the time of the computer within a few milliseconds of Coordinated Universal Time (UTC). It can be implemented in various models like client-server and peer-to-peer. The current version of NTP is ntpv4 and uses the User Datagram Protocol (UDP) and port number 123. In a client-server model, the client sends a packet mode 4 to the server and the server responds back with a packet mode 3 and provides synchronization to them. NTP uses a hierarchical model of time sources. Each layer is termed as stratum, with stratum 0 being the parent of whole layer. This layer is comprised of timekeeping devices such as atomic clocks, GPS clocks and radio clocks. Further down, the next layer is named as stratum 1, which is comprised of computer systems whose devices are synchronized to a few microseconds with their attacked stratum 0 devices. Then a stratum 2 layer, which is connected over a network to stratum 1 devices. Only stratum 0 to 15 are valid.
NTP Security Model
Intruders can play with this protocol to clog the network with big response packets (recent DDoS amplification attack), disrupt some time-dependent critical service, etc. There are various types of attacks that are possible on NTP. Some of them are discussed below:
- A replay attack in which an intruder replays one or more packets.
- Man in the middle attack (MITM) in which an intruder can intercept the packets between authentic client and server.
- A delay attack in which packets between client and server are delayed for a constant or variable time but left unchanged.
- A DDoS attack in which an attacker finds a vulnerable machine, makes it a bot master, and infects other vulnerable systems with malware. NTP DDoS is a type of reflective DDoS attack in which an attacker sends spoofed SYN packets so that when the server replies to the spoofed packet, replies goes to the spoofed IP in the SYN packet. In DDoS, amplification factor is used by attackers to increase the traffic volume in an attack. Results have shown that in an NTP DDoS attack, an attacker who has 1 GB of bandwidth can generate the attack with amplification factor close to 250 GB. More on this will be covered later in this article.
NTP Hierarchical Security Model
So let’s first understand the security model of NTP. The below section covers the security layers in NTP, the various attacks possible, and how each layer protects against the respective attack projected at them.
Let’s discuss these layers further.
On-Wire Protocol Layer: The underlying protocol which is used to transfer packets between client and server. To detect duplicate packets and bogus packets, the wire protocol uses a 64 bit timestamp in the NTP packet, which is very unlikely for an intruder to guess. Detection of a duplicate packet is called a loopback test, and whenever a duplicate packet is found, it is discarded. Thus this layer protects attacks such as replay attacks.
Message Digest Layer: Packets between client and server can be intercepted and changed, except the transmit timestamp. To protect against these attacks, NTP has a message digest layer that uses symmetric key cryptography to compute a message digest. The message digest is computed using algorithms such as MD5 using a secret key and appending a Message Authentication Code (MAC) along with NTP and extension protocol. The MAC consists of a 32 bit key ID followed by a message digest. An algorithm such as MD5 then computes the message hash of the message digest and concatenates that with the NTP packet header. When packets are transmitted, the digest is computed and inserted in the MAC, and when packets are received, the digest is compared with the digest in the MAC, and the packet is only accepted when two digests are equal. However when a large number of clients are required, this is not suitable.
Autokey Sequence Key: In order to provide authenticity of NTP packets, an auto sequence layer is used to provide authenticity using public key cryptography and also digital signatures which are used only in responses from server to client. In client-server mode, the server distributes a unique cookie per client. The server computes the client cookie as the MD5 hash of the autokey with client and IP addresses of server, a key ID of zero and the server cookie. On receiving a request, the server returns the encrypted client cookie and the responses are signed using the server private sign key. The client on the other side decrypts the client cookie and verifies it using the server public key, which is contained in the certificate. For subsequent requests, both client and server calculate and verify the message digest. So an intruder cannot forge a packet until the possession of client cookie, which is further bound to a server signature.
However, a vulnerability known as cookie snatcher exists, where an intruder is able to wiretap the client cookie request to learn the client and server IP addresses. The intruder then launches a client cookie request using its own public encryption key. Using the client cookie, the middleman can masquerade as the legitimate server and inject bogus packets acceptable to the client.
The Autokey Protocol Layer: This protocol layer is used to retrieve certificates and identity keys. There are different key pairs, such as:
- Host Keys: These keys are used to encrypt client cookie.
- Sign Keys: These keys are used on certificates to verify signatures on extension fields. Changing the sign keys will set up the need to regenerate all the certificates.
- Identity keys: these keys are used to authenticate sign keys to avoid masquerade attacks.
Below is the process defined for client-server mode.
Client-server mode is the most deployed for a time server and thousands of clients. All the exchanges must be in proper order. The exchange begins when the client sends an association request including its X.509 distinguished name along with its available cryptographic options. The response from the stateless server sends an association response including its X.509 distinguished name and available cryptographic options. The client, after selecting from the available options, sends a certificate request specifying the server distinguished name. The server sends the certificate signed by the server private sign key for positive identification. This design is vulnerable to the cookie snatcher attack.
So, we have seen that signing and message digest are even susceptible to an attack known as cookie snatcher attack. Let’s understand what exactly a cookie snatcher attack is and a design consideration to stop it.
The cookie snatcher attack happens at the on-wire protocol layer, thus exposing client cookie and message digest. This attack can be defended by adopting an agreement scheme the same way as the TLS handshake protocol, in which client sets message digest key as a nonce and encrypts the key using server public sign key on its certificate and sends that encrypted key during the exchange. Server in turn then decrypts it with its private key and saves the digest key for future use.
NTP DDoS Amplification Attack
Recently, an attack termed as NTP DDoS amplification attack has been realized worldwide. So what is an amplification factor?
Amplification Factor: Amplification is the factor by which the volume of an attack increases. An attacker can trigger an NTP attack by a initiating a request message which is of few bytes in size and because a command like monlist (defined later) can make the server to respond with a packet of very very big size. Recent attacks have been seen to have an amplificatory factor of 350+.
How NTP DDoS Attack Works
NTP protocol by design uses UDP to operate, which does not require any handshake like TCP, thus no record of the request. So, NTP DDoS amplification attack begins when an attacker crafts packets with a spoofed source IP to make the packets appear to be coming from the intended target and sends them to NTP server. Attacker initially crafts the packet of few bytes, but NTP responds with a large amount of data thus adding to amplification of this attack.
MONLIST command: It is a NTP protocol command which has very little use, but it is this command which is the main culprit for this attack. However, the use of MONLIST command is to give details of the last 600 clients that have connected to the NTP time service. Below is the command syntax:
Resolution or Mitigation Steps for DDoS Amplification Attack
Below are some of the ways in which NTP DDoS attack can be mitigated:
- Update the NTP server: All versions of ntpd server prior to 4.2.7 are vulnerable to this attack by default. So upgrade the ntpd servers to the latest version.
- For ntpd servers which cannot be upgraded to the latest version, disable the monlist functionality on NTP servers by adding the noquery directive to the restrict default line in ntp.conf like below:
- restrict default kod nomodify notrap nopeer noquery
- restrict -6 default kod nomodify notrap nopeer noquery
Like other DDoS attacks, attacker usually spoofs the source IP address in this attack as well. So organizations should restrict forged traffic. This mitigation technique is listed in BCP 38. Analysis has shown that attackers place their system inside network range 18.104.22.168/24. So by restricting transit traffic which originates from downstream network to known, this problem of address spoofing can be virtually eliminated. Take a look at the picture below:
For example, in the above figure, the ISP provides connectivity to Attacker (22.214.171.124/24) and all traffic originating from Attacker’s machine is filtered on the ingress link to router 2, thus providing connectivity to Attacker’s machine and filtering traffic that have originated with source address other than mentioned the range 126.96.36.199/24 thus prohibiting the attack from using an invalid IP address.
ISPs should regularly check their exposed services from a security perspective to close any vulnerable services before they are abused by attackers.
Organizations should implement tighter Access Control Lists (ACLs) in their public facing transit edges across layer 3 devices like switches and hardware based routers. This will help to mitigate the malicious traffic (NTP DDoS) from reaching targeted resources; however since the attack amplification factor is so large, mostly transit edge devices get clogged.
Disable the remote execution of monlist command. For example, most Unix /Linux distributions support monlist from a localhost and not from a remote host. Check this monlist execution with following command: