DrDoS cyberattacks based on the NTP protocol

Once the denial of service (DoS) cyberattacks have been analysed alongside any of their variants in the article “DrDoS: characteristics and operation”, this new article is going to address how the NTP protocol is used as a tool to develop a DrDoS variant of a DoS cyberattack.

NTP

The Network Time Protocol (NTP) is a protocol that allows the temporal synchronisation of the various interconnected devices within the scope of configuration of this service. It works with UDP through port 123 and is widely used on global networks, both internal and public. Its importance lies in the fact that the want of time synchronisation for a prolonged period of time in a system affects the consistency and integrity of the information, which has serious consequences in financial, productive and legal areas, and many others.

- Figure 1. NTP operational diagram. -

An example is database systems in which incorrect time synchronisation in record consolidation would cause errors in the acceptance and validation of transactions or give rise to incorrect or out-of-date results or simply errors in the search engine when making queries.

Electronic signature systems also are another clear example, since they include a temporary datum in electronic documents and records and, should it be verified that that date and time datum is incorrect, the signature applied would be directly invalidated.

Attack vector

The NTP protocol shows vulnerabilities related to certain commands used for the management and supervision of the protocol itself, and to be able to configure and assess the status of an NTP server. These commands include:

• The “monlist” command (MON_GETLIST) which, when executed, returns a list with the most recent 600 devices that have communicate with the server. Thus, a request launched against the NTP server of a tiny size, around 250 bytes, causes a response that may be 200 times larger.
• The “readvar” command which, when executed, returns the variables used by the NTP service daemon alongside their values. In this case, the server response consists of more than one package, since this command returns an iteration about the range of associations of the variables used, and their size may reach 30 times that of the source.

Given the foregoing, an ill-intentioned operator may make GET_MONLIST or “readvar” requests from an NTP server, falsifying the real source IP address of the request, with the IP address of the machine that is to be disabled, thus reflecting the cyberattack. The result is that the victim machine, without having requested it, receives the NTP responses with an amplification of 30 to 200 times, according to the type of consultation. Moreover, if these requests are made from a botnet, the victim machine would suffer a drain on its resources, so that the flood of NTP responses reaching it will affect the availability of the services that require connectivity offered by it.

- Figure 2. DrDoS NTP attack diagram. -

These known vulnerabilities affect NTP servers hosting a version prior to 4.2.7p26 and which maintain the default configuration resulting from the default installation, since the specific versions for the Microsoft Windows platform were available from version 4.3.8p8.

Prevention

Firstly, to check whether the monlist function is activated, we can use the following command from a Linux device:

ntpdc -n -c monlist [NTP server IP]

If the command output is a list of devices, monlist will be activated and, therefore, the server will be vulnerable.

On the other hand, regarding the “readvar” function, it is possible to verify whether the server is affected, analysing the output of the execution of the following command:

ntpq -c rv [NTP server IP]

If a timeout error is returned, the server is properly protected. Otherwise, it is vulnerable.

Even if an own NTP server is vulnerable, it is possible to prevent it from being used to participate in a DrDoS cyberattack. The following measures are recommended for this purpose:

• Update to the NTP daemon version. In released versions later than 4.2.7p26, the “monlist” command is disabled. It is possible to check the version of the NTP daemon in service by using the “ntpdc” command with the “--version” argument. Or resort to a system scanning programme such as the well-known “nmap” program, using the modifiers incorporated into the tool. In the case of “nmap”, the following ntpd command could be executed:

sudo nmap -sU -pU:123 -Pn -n --script=ntp-monlist <server-IP>

• Disable the “monlist” or “readvar” function. This is an alternative in the event that the foregoing measure were not possible and which entails assessing the possible impact of the need of the devices connected to the NTP server.
  • To disable the “monlist” function, amend the “/etc/ntp.conf” file to add the line “disable monitor” and then restart the service.
  • To disable the “readvar” function, edit the “/etc/ntp.conf” text file to insert the following lines:

restrict default ignore
disable bclient

If monitoring is essential, there exists the option to limit the origin of requests to specific network segments. This would reduce the NTP server’s level of exposure and the risk of exploitation by an external attacker would be reduced. To do so, the configuration file “/etc/ntp.conf” will be edited by adding the following lines, according to the restrictions to be applied:

restrict default noquery #to restrict it completely
restrict localhost #to restrict it to only the server itself
restrict (network to monitor) netmask (netmask) #to restrict it to a specific network
restrict (IP address) #to restrict it to a specific IP

• Deploy the NTP servers behind firewalls. The firewall must be configured with rules to detect and filter requests directed by UDP to the port of the NTP server and that has an anti-spoofing IP configuration.
• Limit the visibility of the NTP server on the Internet. So that the server is not “public”, by filtering IP addresses. This measure can be established using filtering rules in the firewall.
• Ask your internet service provider (ISP) for anti-spoofing filters. These providers may reject NTP traffic with spoofed addresses, which are not accessible through the actual path of the package. This will prevent the own NTP server from receiving and dealing with requests that are liable to be a DrDoS.
• Set out an action protocol for NTP DrDoS incidents. To reduce the possible impact of the loss of time synchronisation on the system, specific guidelines must be provided on how to identify these attacks and how to act if they occur. Improvisation in the actions taken to address these incidents can cause problems and failures in other components.

Detection and evidence

To detect whether an own NTP server is participating in a reflected denial of service attack, it is necessary to pay attention to the performance of the time synchronisation servers as regards process overload and intensive use of their resources. One must also watch out for unusual and heavy UDP traffic on port 123.

Similarly, it is also recommendable to enable the collection statistics on the NTP server for consultation and analysis in this type of situation, which are collected in the “/var/log/ntpstats” file.

Response and recommendations

If the indications are confirmed and it is believed that a denial-of-service attack is underway on the own NTP servers, it is necessary to act quickly and apply the previously-defined action and incident management protocol.

• Enable an alternative NTP service. If the NTP server goes out of service and that affects other components of the system, it is recommendable to temporarily replace the normal configuration with an alternative one that may be a global pool of NTP servers. Doing this will prevent other services that depend on the own NTP server from failing or data time inconsistency problems from arising. At ntppool.org, there are several global servers that may be used as an alternative time source.

w32tm /config /syncfromflags:manual /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org

If it is a Linux system, the following parameters will be added in the text file hosted on the following path: “/var/lib/ntp/ntp.drift”.

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org

• Compile as much data as possible about the incident. An investigation will have to be undertaken to identify source and destination IP addresses, ports and possible URL addresses.
• Block and filter unwanted traffic. The data collected previously may be used to set up filtering rules in firewalls and routers and thus to prevent requests from reaching the one’s own NTP server. It is also recommendable to contact the Internet and hosting provider so that they can apply in their area filters that block the installation of unauthorised traffic.
• Obtain technical assistance. Either with the IT technical service providers they may have contracted or through the leading public computer emergency response teams (CERT), such as INCIBE-CERT.

Once the attack has stopped, it must be verified that the service has been restored to normal and the time configuration is it usually is. Also, it the causes must be analysed that have caused it and, as with any other technology crime, the incident must be reported to the authorities.