Last updated at Fri, 10 May 2019 17:16:30 GMT

Overview

As part of Rapid7 Labs' Project Sonar, among other things, we scan the entire public IPv4 space (minus those who have opted out) looking for listening NTP servers.  During this research we discovered some unknown NTP servers responding to our probes with messages that were entirely unexpected.  This lead to the writing of an NTP fuzzer in Metasploit in the hopes of understanding what NTP implementations would respond in this or other anomalous manner in various configurations.  This, in turn, resulted in finding six previously unpublished vulnerabilities in NTP Project's NTP implementation. One of these is similar in terms of severity to the NTP MON_GETLIST amplification vulnerability described in CVE-2013-5211 that was the source of record-sized DRDoS attacks in late 2013 and early 2014.  All NTP instances vulnerable to CVE-2013-5211 are likely also vulnerable to these six new vulnerabilities, putting the number of public, vulnerable systems at approximately 65,000 based on a recent analysis.

Background

To fully grasp these vulnerabilities it is important to have a brief understanding of the technology in question (NTP), the vulnerability type (traffic amplification) and the attacks that frequently result from the abuse of these vulnerabilities (DRDoS).

NTP is the Network Time Protocol and serves to keep the clock of a computer system in sync.  Properly synchronized clocks play a critical role in logging, authentication, cryptography and general system sanity, and as such NTP can be found in some manner in nearly all environments.  NTP has been evolving for over 30 years and has seen four revisions its protocol.  While there are numerous NTP implementations for both clients and servers, the NTP software provided by the Network Time Foundation's Network Time Protocol project powers the vast majority.

A traffic amplification vulnerability occurs when the number or size of any resulting responses is greater than that of the initiating request.  These types of vulnerabilities are nearly exclusively limited to just UDP protocols and see frequent enough abuse to justify a notice from US-CERT.  When discussing traffic amplification vulnerabilities, an amplification factor is used to describe the relationship between the total size or total number of responses as compared to that of the original request.  For example, a vulnerability where a single 1-byte UDP message results in 3 responses of arbitrary size can be said to have a 3x packet amplification factor.  Similarly, a vulnerability where a single 8-byte UDP message results in an 800-byte response can be said to have a 100x bandwidth amplification factor.

Distributed Reflective Denial of Service (DRDoS) attacks abuse traffic amplification flaws to overwhelm third-party targets.  In a typical attack, an attacker will forge UDP packets with a source address of their intended target and a destination address of the system vulnerable to traffic amplification.  With enough traffic amplifiers, because the number or size of each resulting response is larger than that of the forged request, a target can very quickly become overwhelmed with the responses coming from the affected UDP service.  While DRDoS attacks continue to be effective, they generally only exploit vulnerabilities where the traffic amplification factor is large enough to overwhelm the target.

This particular disclosure describes traffic amplification vulnerabilities in the Network Time Protocol project's NTP implementation that could be used in DRDoS attacks.

Vulnerabilities Summary

More detail is available below, however the summary is:

  1. NTP mode 7 (private) PEER_LIST (0), PEER_LIST_SUM (1) and GET_RESTRICT (16) requests are vulnerable to traffic amplification and can be used to conduct DRDoS attacks
  2. NTP mode 6 (control) CTL_OP_REQ_NONCE (12) and UNSETTRAP (31) requests are vulnerable to traffic amplification and can be used to conduct DRDoS attacks
  3. NTP mode 7 (private) GET_RESTRICT requests can be used to conduction information disclosure attacks and obtain the internal ACL configuration of vulnerable NTP instances (CVE-2014-5209)

The NTP Project currently plans to fix these specific vulnerabilities but no release date for these changes has been published. However, as of version 4.2.7p230, released in November 2011, mode 7 responses are disabled by default.  Furthermore, numerous resources that have been available for years that describe how to properly secure an NTP instance and can be used to provide adequate compensating controls to protect against all of these vulnerabilities.  This means that any instances running versions newer than 4.2.7p230 should be sufficiently protected by default unless explicitly configured otherwise, and nearly all NTP versions can be protected when properly configured.  Operators of NTP servers should ensure that mode 6 and mode 7 requests are allowed only if absolutely necessary and from trusted entities using a secure NTP configuration.

Victims of resulting DRDoS attacks should apply the same countermeasures recommended for CVE-2013-5211 and similar DoS/DDoS attacks.  Everyone is encouraged to comply with BCP38 which can help in preventing traffic amplification vulnerabilities from being exploited in the first place.

Disclosure Timeline

  • Thu, Jun 19, 2014: Issue discovered and advisory written
  • Fri, Jun 20, 2014: Vendor PGP contact details sought
  • Wed, Jul 9, 2014: Issue disclosed to CERT/CC
  • Sun, Aug 3, 2014: Contact established with NTP.org
  • Mon, Aug 4, 2014: Updated advisory sent to NTP.org
  • Mon, Aug 25, 2014: Public disclosure

Technical Analysis

R7-2014-12.1 -- NTP Project Mode 7 PEER_LIST (0) Traffic Amplification

An NTP private (mode 7) message for the XNTPD_OLD (2) and XNTPD (3) implementation with the PEER_LIST (0) request code will return the list of all hosts that a given NTP server is peering with. Depending on the number of peers, an NTP server's response can be large and potentially spread over many packets.  The more peers in use, the larger the response will be.

Because both the number and size of the packets sent as the response can be greater than that of the original request, this can be used to conduct a DRDoS attack against third parties using vulnerable NTP servers.  The traffic amplification factor for this is slightly less than half of CVE-2013-5211 because each peer contributes 32 bytes to a response rather than MON_GETLIST_1's 72.  In most situations the amplification will actually be much less because it is a function of how many NTP servers a given NTP instance peers with, and most configurations peer with 3-5 peers.  With 5 peers, the bandwidth amplification factor is 17x and there is no packet amplification.

Versions as new as 4.2.7p465, released this month, and as old as 4.2.7p25 from April of 2010 have been confirmed to be vulnerable, but only when querying is allowed and mode 7 messages are enabled.  Older versions may be vulnerable, however it is unclear when this functionality was originally added.

This can be seen by running the ntp_peer_list_dos Metasploit module:

Or utilizing the ntpdc command:

ntpdc -nc listpeers <host>

R7-2014-12.2 -- NTP Project Mode 7 PEER_LIST_SUM (1) Traffic Amplification

This vulnerability is identical to R7-2014-12.1 except for the fact that the response to a PEER_LIST_SUM request also includes metadata to describe each peer (stratum, clock delay, etc), making each response larger than an equivalent PEER_LIST response.  While it is similarly limited by the generally low number of peers in use on most NTP servers, theoretically the traffic amplification is on-par with the MON_GETLIST_1 vulnerability because each peer entry contributes 72 bytes to the response.  In the recommended minimum setup of 5 peers, a 46x bandwidth amplification is possible but there is no packet amplification.

This can be tested by running the ntp_peer_list_sum_dos Metasploit module:

Or utilizing the ntpdc command:

ntpdc -nc peers <host>

R7-2014-12.3 -- NTP Project Mode 7 GET_RESTRICT (16) Traffic Amplification

An NTP private (mode 7) message for the XNTPD_OLD (2) and XNTPD (3) implementation with the GET_RESTRICT (16) request code will return the list of hosts/networks that have particular restrictions applied to them.  Depending on the number of restrictions applied, an NTP server's response can be large and potentially spread over many packets.  The more restrictions applied, the larger the response will be.

Because both the number and size of the packets sent as the response can be greater than that of the original request, this can be used to conduct a DRDoS attack against third parties using vulnerable NTP servers.  Each restriction applied in an NTP server contributes 56 bytes to the resulting response, but much like with the other vulnerabilities described so far there are practical limitations.  In most situations, NTP servers will only have a handful of restrictions and is likely a function of the number of peers in use, resulting in a traffic amplification similar to R7-2014-12.2

Versions as new as 4.2.7p465, released this month, and as old as 4.2.7p25 from April of 2010 have been confirmed to be vulnerable, but only when querying is allowed and mode 7 messages are enabled. Older versions may be vulnerable, however it is unclear when this functionality was originally added.  xntp3 5.93e from 1998, for example, appears to have similarly vulnerable code.

This can be tested by running the ntp_reslist_dos Metasploit module:

Or utilizing the ntpdc command:

ntpdc -nc reslist <host>

R7-2014-12.4 -- NTP Project Mode 7 GET_RESTRICT (16) Information Disclosure

As described in R7-2014-12.3, the GET_RESTRICT message returns the list of hosts/networks that have particular restrictions applied to them. This is the equivalent of an ACL and should be considered sensitive because it can:

  • Disclose the internal or alternative IP addresses and/or networks used by the NTP server
  • Disclose any other networks or hosts that have unique, possibly more lax restrictions applied when communicating with this NTP server, potentially showing further attack vectors

This vulnerability applies to the same versions affected by R7-2014-12.3 with the same exploitability caveats and exploitation steps, and has been assigned CVE-2014-5209.

R7-2014-12.5 -- NTP Project Mode 6 CTL_OP_REQ_NONCE (12) Traffic Amplification

An NTP control (mode 6) message with the CTL_OP_REQ_NONCE (12) opcode will generate a single reply that is larger (44 bytes) than the request (12 bytes).  Because the size of the packet sent as the response is greater than that of the original request, this can be used to conduct a DRDoS attack against third parties using vulnerable NTP servers but only with a small 4x bandwidth amplification factor.

This vulnerability was introduced in 4.2.7p26, the release that originally fixed CVE-2013-5211. All 4.2.7 versions after this are vulnerable, but, again, only when querying is allowed.

This can be tested by running the ntp_req_nonce_dos Metasploit module:

R7-2014-12.6 -- NTP Project Mode 6 UNSETTRAP (31) Traffic Amplification

An NTP control (mode 6) message with the UNSETTRAP (31) opcode with an unknown association identifier will cause NTP to respond with two packets -- one error response packet indicating that the association identifier was invalid followed by another non-error, largely empty response. Because the number of packets sent as the response is greater than the single packet request, this can be used to conduct a DRDoS attack using vulnerable NTP servers as the unwitting third parties with a 2x packet amplification factor and a 3-4x bandwidth amplification factor.

This vulnerability applies to the same versions affected by R7-2014-12.1 with similar exploitabiity caveats, however more testing needs to be done.

This can be tested by running the ntp_unsettrap_dos Metasploit module:

Conclusions and Recommendations

While it would be nice for these vulnerabilities to be fixed, the reality may be that they cannot be fixed without non-trivial modifications to the protocol such that the vulnerability is removed (for example, by enforcing request size/count >= response size/count) or adequate mitigating controls are put in place (such as a session identifier or other unique request identifier).  Barring changes of this magnitude, operators of NTP servers should continue to heed the advice that the Network Time Prototcol Project, openntpproject.org, Team CYMRU and others that have been giving for years and deploy NTP configurations that properly restrict querying and anything related to mode 6 or 7 messages.  At the end of the day, the messages in question are purely for valid administrative purpose and SOP should be that these administrative capabilities be properly restricted.

Modules for detecting these vulnerabilities will be landed in Metasploit today and the corresponding coverage in Nexpose will come with this week's release on Wednesday, August 27.