Hello,
this is a known bug. Known fixed releases are at the bottom:
Limited Mode 6 denial-of-service vulnerability on NTP server and client
CSCum44673
Description
Symptom:
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.
Conditions:
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 doesn’t 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 ?
<3-15> 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
Workaround:
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
Further Problem Description:
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
Known Fixed Releases: (30)
15.6(1)SN
15.5(1.8)S
15.5(1.2.1a)GB
15.5(1)SN
15.5(1)S
15.5(0.18)S0.6
15.5(0.16.1)CG
15.5(0.14)T
15.4(3)S4
15.4(3)S3.8
15.4(3)M4
15.4(3)M3.2
15.3(1)IE101.154
15.2(6.3.0i)E
15.2(4.0.64a)E
15.2(4.0.38)E
15.2(4)E
15.2(3)E3
15.2(2.0.2)EA3
15.2(2)SY
15.2(2)EA3
15.2(2)E3
15.2(1.1)ST3
15.2(1)SY2
15.2(1)SY1.79
15.1(2)SY12
15.1(2)SY11.24
3.8(0)E
3.7(3)E
3.6(3)E
