[ntp:security] [Bug 3118] Mode 6 unauthenticated trap information disclosure and DDoS vector

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Fri Sep 23 07:28:16 UTC 2016


Harlan Stenn <stenn at ntp.org> changed:

           What    |Removed                     |Added
           Priority|P5                          |P2
            Summary|test #1                     |Mode 6 unauthenticated trap
                   |                            |information disclosure and
                   |                            |DDoS vector
              Flags|                            |blocking4.2.8+
           Severity|enhancement                 |critical

--- Comment #1 from Harlan Stenn <stenn at ntp.org> 2016-09-23 07:28:16 UTC ---

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.

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

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

  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

:: 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

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

:: Credit

Discovered by Matthew Van Gundy of Cisco ASIG.

:: Timeline

2016-09-20 - Vendor Disclosure

Configure bugmail: http://bugs.ntp.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the security mailing list