The Network Time Protocol (NTP) is the standard protocol for time synchronization in the IT industry. It is widely used by servers, mobile devices, endpoints, and network devices, irrespective of their vendor. The latest version of NTP (version 4) is defined in RFC 5905.
The basic principles of time synchronization are pretty simple and straightforward. An NTP client sends a request to the NTP server, embedding the client’s own time. The NTP server replies 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.
In most network environments, local devices synchronize time with a local server (like the Domain Controller in Windows environments). The local server, in turn, synchronizes its clock with reliable internet NTP servers.
How Does the NTP Amplification Attack Work
In the case of distributed denial of service attacks (DDoS), the attacker floods the victim with a large amount of network traffic. A successful attacker must provide more attack traffic than the target can handle. This is often difficult to accomplish using normal requests. An attacker needs to control a large number of machines that send requests to the target.
One of the most common and most effective techniques used for DDoS attacks is reflection/amplification. This type of attack relies on a certain request being much smaller than the reply. If the attacker can redirect a large number of such replies to the victim, they can do a lot of harm with few resources. There are multiple protocols and/or protocol implementations with vulnerabilities that allow them to be used as accessories for reflection/amplification, for example, DNS, SNMP v2, and NTP. However, some of them (including NTP) are more sought after by the attackers because of the high amplification factor.
The protocol also allows for requests that let NTP clients assess the quality of the NTP server (to know if they can trust its clock). This includes a set of commands used for monitoring purposes. One of these commands is monlist (
MON_GETLIST). When the NTP server receives a monlist command, it returns the list of most recent assets that have interacted with the server. A single NTP monlist request of around 250 bytes can cause the server to send back several kB of data. The reply is up to 200 times the size of the request. Therefore, an attacker with a 1 GB network interface can theoretically generate 200 GB of traffic by exploiting this command. This vulnerability is classified as CVE-2013-5211.
To exploit most reflection/amplification vulnerabilities, attackers must also use IP spoofing. If not, the large reply goes back to the attacker, so it makes no sense. The attacker sends a small request to the accessory server with a source IP address of the victim. The accessory server thinks that the request came from the victim, so it returns the large reply to the source address. A large number of such events causes a distributed denial of service.
How to Prevent NTP Reflection
The NTP reflection DDOS attack vector saw the biggest incidence increase in Q1 2014. After more than 5 years, there are still many vulnerable NTP servers available that can be used as amplifiers for NTP reflection attacks. According to the SISSDEN organization, in 2018 NTP reflection was still one of the most popular vectors amongst amplification attacks.
Most current implementations of the NTP protocol are not vulnerable because the monlist command is banned or reserved by default. However, older NTP daemons and custom configurations may expose this command to external parties. Therefore, if you have any NTP servers on your network, do the following:
- Scan your NTP server with a vulnerability scanner
- Upgrade the NTP daemon if a vulnerability has been detected
- If an upgrade is not possible, disable the monlist command or enforce that requests come from valid sources
If you do not run an NTP server but are worried that you may become a victim of an NTP reflection attack, do the following:
- Monitor NTP traffic; if there are UDP packet volume spikes on port 123, 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 port 123 on your internet-facing assets if time synchronization is not required
*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by Tomasz Andrzej Nidecki. Read the original post at: http://feedproxy.google.com/~r/acunetixwebapplicationsecurityblog/~3/BW7lBn-LqyI/