Network Time Protocol Control Mode Unauthenticated Trap Information Disclosure and DDoS Amplification Vulnerability

Summary

An exploitable configuration modification vulnerability exists in the control mode (mode 6) functionality of ntpd. A specially crafted control mode packet can set ntpd traps, providing information disclosure and DDoS amplification, and unset ntpd traps, preventing legitimate monitoring. A remote, unauthenticated, network attacker can trigger this vulnerability.

Tested Versions

NTP 4.2.8p3
NTP 4.2.8p8
NTPsec 0.9.1
NTPsec 0.9.3

Product URLs

http://www.ntp.org
http://www.ntpsec.org/

CVSS Scores

CVSSv2: 6.4 - (AV:N/AC:L/Au:N/C:P/I:P/A:N)
CVSSv3: 6.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Details

ntpd provides a trap functionality that sends asynchronous notifications to a number of trap receivers whenever an event of interest occurs. Example events of interest include: association mobilization and demobilization, authentication failures, reachability changes, etc.

Since at least ntp-4.0.94 (July 21, 1999), ntpd has allowed traps to be configured via control (mode 6) and private (mode 7) NTP modes. Though private mode requires messages modifying trap settings to be be authenticated, control mode allows unauthenticated packets to modify trap settings using the SETTRAP and UNSETTRAP control messages.

This vulnerability can be used to achieve several goals:

• Time Shifting: If an attacker controls a host that is allowed to receive traps (i.e. not restricted by restrict noquery or restrict notrap), the attacker can instruct a victim ntpd instance to send traps to the attacker’s host. Whenever a reportable event occurs for some peer, the victim ntpd will send a trap to the attacker leaking all the peer variables associated with that peer. The information leaked includes the peer’s org and rec variables allowing the attacker to bypass TEST2 and impersonate said peer in a manner similar to CVE-2015-8139 and CVE-2016-1548.

The attacker can force the victim ntpd to leak the information for any peer at any time by triggering a reportable event for said peer. There are multiple methods to trigger a reportable event for a peer, among them spoofing an invalid crypto-NAK or incorrectly authenticated packet from the peer.

NOTE: With ntp-4.2.8p8 and earlier the 0rigin attack (CVE-2015-8138) [1] already allows impersonation of reachable peers. In those ntpd versions, this vulnerability provides another method for impersonating unreachable peers.

• DDoS Amplification: An attacker can use an ntpd instance as a DDoS amplifier to DDoS hosts that are allowed to receive traps from the ntpd instance using the following technique. The amplification factor is 12-13x.

The attacker forges a SETTRAP packet from the victim to the amplifier, causing the amplifier to set a trap for the victim. The attacker then repeatedly triggers reportable events causing trap messages to be sent to the victim. E.g. the attacker rapidly forges invalid crypto-NAKs and/or bad_auth packets from the victim’s sys_peer.

ntpd attempts to limit the number of consecutive traps sent for events of a single type. To maximize effect, the attacker can alternate between events of different types.

ntpd will periodically time out old traps when a new one is set. Therefore, for a long-term attack, the attacker may need to periodically refresh the trap on the amplifier.

• Evading Monitoring: In an environment where dynamically configured traps are used to modify an ntpd instance, an unauthenticated attacker can remove traps set by legitimate monitoring systems by spoofing the source address of the trap receiver in an UNSETTRAP message.

Authentication should be required in order to modify trap configuration.

Mitigation

Several mitigations can lessen the impact of this vulnerability.

1. Unauthorized hosts can be prevented from receiving traps using the restrict default notrap restriction. This setting is the default on many modern Linux systems.

This mitigation has no effect on the “Evading Monitoring” impact described above because the alleged sender of the packet is an authorized trap receiver.

2. Block NTP control mode trap configuration commands using a firewall or IPS. It does not appear that support for configuring control mode traps was ever implemented in ntpq, the reference NTP control mode client. As such, on most networks blocking control mode trap configuration commands should have no effect on legitimate traffic. Specifically, firewalls should block packets with the following characteristics:

   • UDP Destination Port: 123
   • NTP Mode: 6
   • NTP Control Operation Code: 6 (SETTRAP) or 31 (UNSETTRAP)

Traps specified in ntp.conf cannot be modified using this vulnerability.

[1] http://www.talosintelligence.com/reports/TALOS-2016-0077/

Timeline

2016-09-20 - Vendor Disclosure
2016-11-21 - Public Release