Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
A vulnerability in Network Time Protocol (NTP) package of Cisco IOS and Cisco IOS-XE Software could allow an unauthenticated, remote attacker to cause a limited Denial of Service (DoS) condition on an affected device. The vulnerability is due to processing of MODE_CONTROL (Mode 6) NTP control messages which have a certain amplification vector. An attacker could exploit this vulnerability by sending Mode 6 control requests to NTP servers and clients and observing responses amplified up to 40 times in size. An exploit could allow the attacker to cause a Denial of Service (DoS) condition where the affected NTP server is forced to process and respond with larger response data. In order to elicit significantly big response and exploit this vulnerability, an attacker would have to send a huge number of mode 6 messages to a large number of servers or clients Processing of Mode 7 messages is already disabled through the fix for CSCtd75033.
Cisco IOS, and Cisco IOS-XE Software devices configured as NTP servers or clients are only affected by a very limited amplification attack coming from processing Mode 6 requests. Cisco IOS, and Cisco IOS-XE Software are not processing Mode 7 command requests from clients starting with the fix that got into CSCtd75033. Prior to the fixed software in CSCum44673 Cisco IOS Software does not perform rate limiting on Mode 6 packets. All versions prior to the fix of CSCum44673 are subject to contributing to amplification attacks via mode 6 packets. Once CSCum44673 is integrated (you can see that via the fixed field in Bug Search Toolkit), your device has access to the configuration command: Device(config)#ntp allow mode control ? Rate limiting delay (s) With the default setting being 3 seconds. Any versions after the first fix also keep this NTP rate-limiting change. To see if a device is configured with NTP, log into the device and issue the CLI command show running-config | include ntp. If the output returns either of the following commands listed then the device is vulnerable: ntp master ntp peer ntp server ntp broadcast client ntp multicast client The following example identifies a Cisco device that is configured with NTP: router#show running-config | include ntp ntp peer 192.168.0.12 The following example identifies a Cisco device that is not configured with NTP: router#show running-config | include ntp router# Information about Cisco IOS Software release naming conventions is available in ''White Paper: Cisco IOS and NX-OS Software Reference Guide'' at the following link: http://www.cisco.com/web/about/security/intelligence/ios-ref.html
There are no solid workarounds other than disabling NTP on the device. The following mitigations have been identified for this vulnerability; only packets destined for any configured IP address on the device can exploit this vulnerability. Transit traffic will not exploit this vulnerability. Note: NTP peer authentication is not a workaround and is still a vulnerable configuration. * NTP Access Group Warning: Because the feature in this vulnerability utilizes UDP as a transport, it is possible to spoof the sender's IP address, which may defeat access control lists (ACLs) that permit communication to these ports from trusted IP addresses. Unicast Reverse Path Forwarding (Unicast RPF) should be considered to be used in conjunction to offer a better mitigation solution. Additionally, ''serve-only'' keyword added to the NTP access-group will limit the exposure of the server to only respond to valid queries. For additional information on NTP access control groups, consult the document titled ''Cisco Nexus 7000 Series NX-OS System Management Configuration Guide, Release 4.x'' at the following link: http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_2/nx-os/system_management/configuration/guide/sm_3ntp.html * Infrastructure Access Control Lists Warning: Because the feature in this vulnerability utilizes UDP as a transport, it is possible to spoof the sender's IP address, which may defeat ACLs that permit communication to these ports from trusted IP addresses. Unicast RPF should be considered to be used in conjunction to offer a better mitigation solution. Although it is often difficult to block traffic that transits a network, it is possible to identify traffic that should never be allowed to target infrastructure devices and block that traffic at the border of networks. Infrastructure ACLs (iACLs) are a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The white paper entitled ''Protecting Your Core: Infrastructure Protection Access Control Lists'' presents guidelines and recommended deployment techniques for infrastructure protection access lists and is available at the following link: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml * Control Plane Policing - Filtering untrusted sources to the device. Warning: Because the feature in this vulnerability utilizes UDP as a transport, it is possible to spoof the sender's IP address, which may defeat ACLs that permit communication to these ports from trusted IP addresses. Unicast RPF should be considered to be used in conjunction to offer a better mitigation solution. Control Plane Policing (CoPP) can be used to block untrusted UDP traffic to the device. CoPP can be configured on a device to help protect the management and control planes and minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic that is sent to infrastructure devices in accordance with existing security policies and configurations. - Rate Limiting the traffic to the device Note: Since the NTP Amplification DoS attacks rely on sending relatively small amount of NTP requests in order to solicit large, amplified responses from the server, this workaround has only limited application. Additional information on the configuration and use of the CoPP feature can be found in the documents, ''Control Plane Policing Implementation Best Practices'' and ''Understand CoPP on Nexus 7000 Series Switches'' at the following links: http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html and http://www.cisco.com/en/US/products/ps9402/products_tech_note09186a0080c01155.shtml
The vulnerability comes from a shortcoming in RFC5905 that allows processing of optional Mode 6 command requests by NTP servers and clients In summary, the attack is based on the premise of processing Mode 6 (MODE_CONTROL) requests from the clients. While the requests are small, the response can grow up to 40 times in amplification factor size. PSIRT Evaluation: The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 2.6/2.3: http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:H/Au:N/C:N/I:N/A:P/E:F/RL:W/RC:C&version=2.0 No CVE ID has been assigned to this issue. Additional information on Cisco's security vulnerability policy can be found at the following URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html