NTP is the standard protocol for time synchronization in the IT industry and is widely used by servers, mobile devices, endpoints and network devices, irrespective of their vendor. Latest definition of NTP is at version 4, described in RFC 5905. The basic principle of the time synchronization protocol is pretty simple and straightforward: NTP clients send requests embedding their own time to NTP servers which reply back with their own time and the time when the packet was sent back. Based on these parameters, the NTP client can calculate the time difference between the clock of the NTP server and its own clock. The protocol implements other types of requests through which the NTP clients assess the quality of the NTP server in order to trust its clock. In most network environments, endpoints, mobile devices and network devices would synchronize their time with a local server (like the Domain Controller in Windows environments) which, in turn, would synchronize its clock with reliable internet NTP servers.

The problem

The NTP protocol includes a set of commands used for monitoring purposes. Among these, the one most relevant to this article, is “monlist” (MON_GETLIST). When the NTP server receives a “monlist” command, it will reply with the list of last the 600 assets that have interacted with the server. Simply put, a single request of around 250 bytes can cause the server to send back numerous packets summing up to a few KB of data, thus multiplying the size of the reply by a factor of up to 200, depending on the activity that the NTP server can report on. In other words, an attacker with a 1 GB network interface can theoretically generate traffic of 200 GB by exploiting this command.

Figure 1. Output of monlist command

How does the attack work?

DDOS attacks imply overwhelming a target with network traffic. Having said that, successful attackers must output more network traffic than the target can handle. This may prove a difficult thing to accomplish by using normal requests, as the attacker needs to control a large number of “bots” or zombie machines that carry out the requests to the target. What made NTP a notorious tool for DDOS attackers, is the fact that it acts as an amplifier for the network traffic – a small request causes the server to send a large reply. Using this technique, attackers can cause denial of service conditions using a relatively low number of NTP servers as amplifiers. Other protocols prone to this type of vulnerability are DNS (with a lower multiplication factor) and SNMP v2 (with a higher multiplication factor).

Since CVE-2013-5211 is an NTP vulnerability, we might think that the targets of DDOS attacks exploiting it are vulnerable NTP servers. NTP servers themselves do not constitute a sweet target for attackers, because the benefits from bringing down such servers are minimal. Instead, the attackers use IP spoofing to target any machine on the internet and just use the vulnerable NTP servers as accessories.

The target of such an attack can be virtually any exposed server that allows IP spoofing. Attackers would send forged requests to vulnerable NTP servers and use the spoofed IP of the target as source IP. The vulnerable servers will reply to the target’s IP address causing the denial of service condition.

Figure 2. Typical NTP Reflection DDOS Attack

How to prevent the attack?

a) If you administer an NTP server

Windows implementations of the NTP protocol do not have this vulnerability as the use of monlist command is banned or reserved.

Most of the Unix/Linux implementations do, however, suffer from this vulnerability. The NTP daemons prior to 4.2.7p26 are vulnerable by default.

If upgrade is not possible, you can disable the “monlist” command or enforce that the request comes from valid sources. See how

Periodically scan the NTP server for CVE-2013-5211 with network and vulnerability scanners that can detect CVE-2013-5211, in order to make sure your NTP server cannot be used as a DDOS amplifier.

b) If you have internet facing assets (and are a potential target of a NTP DDOS reflection attack)

Monitor NTP traffic; if there are volume spikes on port 123 UDP, then you may be under such an attack;

Prevent IP spoofing – Make sure that the IP of your internet facing assets cannot be spoofed by implementing security measures such as BCP 38;

Close UDP 123 on your internet facing assets, if time synchronization is not required via NTP. Use a network scanner to identify assets on which port 123 UDP is open.

Conclusion

According to Prolexic, NTP reflection DDOS attack vector saw the biggest incidence increase in Q1 2014, arriving second to the Syn attack which remains most popular. There are still many vulnerable NTP servers available that can be used as amplifiers for NTP reflected DDOS attacks. Prevent your servers from being part of DDOS attacks by using port scanning to identify running NTP services and vulnerability assessment to detect CVE-2013-5211.