NTP can be abused to amplify denial-of-service attack traffic

2014-01-1000:00:00

www.kb.cert.org

125

5 Medium

CVSS2

Access Vector

NETWORK

Access Complexity

LOW

Authentication

NONE

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

PARTIAL

AV:N/AC:L/Au:N/C:N/I:N/A:P

0.967 High

EPSS

Percentile

99.6%

JSON

Overview

UDP protocols such as NTP can be abused to amplify denial-of-service attack traffic. Servers running the network time protocol (NTP) based on implementations of ntpd prior to version 4.2.7p26 that use the default unrestricted query configuration are susceptible to a reflected denial-of-service (DRDoS) attack. Other proprietary NTP implementations may also be affected.

Description

NTP and other UDP-based protocols can be used to amplify denial-of-service attacks. Servers running the network time protocol (NTP) based on implementations of ntpd prior to version 4.2.7p26 that use the default unrestricted query configuration are susceptible to a reflected denial-of-service (DRDoS) attack. Other proprietary NTP implementations may also be affected. This is similar in scope to DNS Amplification Attacks.

In a reflected denial-of-service attack, the attacker spoofs the source address of attack traffic, replacing the source address with the target’s address. Certain NTP control messages provide significant bandwidth amplification factors (BAF).

NTP is designed for time synchronization, and may also implement other features such as server administration, maintenance, and monitoring. NTP relies on the user datagram protocol (UDP) to send and receive messages, which does not validate the source (IP address) of the sender. The NTP DRDoS attack is similar to the reflective DoS attacks used on open DNS resolvers. The attacker sends a packet with their source address being the IP of a victim. The NTP server replies to this request, but the number of bytes sent in the response is an amplified amount compared to the initial request, resulting in a denial-of-service on the victim. The two highest message types, REQ_MON_GETLIST and REQ_MON_GETLIST_1 amplify the original request by a factor of up to 3660 and 5500 respectively. This bandwidth amplification factor (BAF) is a bandwidth multiplier based on the number of UDP payload bytes that are sent by the server in comparison to the UDP payload bytes of the request. Other message types can also be used in this attack, but REQ_MON_GETLIST and REQ_MON_GETLIST_1 create the biggest impact.

This vulnerability contains elements of CWE-406: Insufficient Control of Network Message Volume (Network Amplification).

More information can be found in Christian Rossow’s “Amplification DDoS Attacks (Ab)using NTP Servers” blog post.

In April 2014, Rapid7 published R7-2014-12 documenting additional NTP commands that can amplify traffic and disclose potentially sensitive information.

Impact

An unauthenticated remote attacker may leverage the vulnerable NTP server to conduct a distributed reflective denial-of-service (DRDoS) attack on another user.

Solution

Apply an Update
Affected users are advised to update to ntpd versions 4.2.7p26 and greater.

ntpd version 4.2.7p26 disables REQ_MON_GETLIST and REQ_MON_GETLIST_1, removing the two most significant BAF control messages.

The 4.2.6.x and earlier production branches are still vulnerable to this attack, however.

If an update is not possible, please consider one or more of the following workarounds.

Check if the amplified responses are enabled
Entering the following commands can help users verify if the REQ_MON_GETLIST and REQ_MON_GETLIST_1 responses of NTP are currently enabled:

ntpq -c rv
ntpdc -c sysinfo
ntpdc -n -c monlist

These commands only verify if the specified functions are enabled. If they are enabled, implement at least one of the following:

Perform Egress Filtering
Configure your router/firewall to perform egress filtering, which may help to mitigate attacks that utilize source IP spoofing. Please refer to your product’s documentation for instructions on how to perform egress filtering.

Disable status queries or restrict access.
The ntpd status query features provided by ntpq/ntpdc will reveal some information about the system running ntpd (e.g. OS version, ntpd version) that you may not wish others to know. Disabling this feature may also help to reduce the likelihood of this vulnerability taking place. If the NTP implementation is vulnerable, adding the following lines to your ntp.conf file will restrict informational queries to authorized recipients only.

IPV4: restrict default kod nomodify notrap nopeer noquery
IPv6: restrict -6 default kod nomodify notrap nopeer noquery
Please note that a restart of the ntpd service is required for changes to take effect.

It is also possible to restrict access per network segment (be sure to modify line 3 to match your LAN settings) and per host (line 4):

restrict default noquery
restrict localhost
restrict 192.168.0.0 netmask 255.255.0.0
restrict 192.168.1.27
Please note that a restart of the ntpd service is required for changes to take effect. Please also note that the ntpq/ntpdc query capabilities provide useful Q/A and debugging information. Disabling these queries comes with a cost.