Cisco NX-OS Malformed IP Packet Denial of Service Vulnerability


Cisco NX-OS Software is affected by a denial of service (DoS) vulnerability that could cause Cisco Nexus 1000v, 5000, and 7000 Series Switches that are running affected versions of Cisco NX-OS Software to reload when the IP stack processes a malformed IP packet.

Vulnerable Products

Cisco Nexus 1000v, 5000, and 7000 Series Switches that are running affected versions of Cisco NX-OS Software are affected by this vulnerability. The vulnerability is in the operating system’s IP stack; therefore, any feature that makes use of the services that are offered by the IP stack to process IP packets is affected.

Cisco NX-OS Software versions prior to the First Fixed Release version are affected. Refer to the Software Versions and Fixes section for details regarding fixed versions.

To determine the version of Cisco NX-OS Software that is running on a Cisco Nexus switch, administrators can log in to the device and issue the show version command to display the system banner.

Products Confirmed Not Vulnerable

Cisco NX-OS Software for products other than the Cisco Nexus 1000v, 5000, and 7000 Series Switches is not affected by this vulnerability. In particular, the following products that run Cisco NX-OS Software are not affected:

Cisco Nexus 2000 Series Switches
Cisco Nexus 3000 Series Switches
Cisco Nexus 4000 Series Switches
Unified Computing System (UCS)
Cisco MDS 9000 Series Multilayer Switches

No other Cisco products are currently known to be affected by this vulnerability.

This advisory is available at the following link:

Cisco: CUCM DoS Vulnerabilities

Cisco Unified Communications Manager (formerly Cisco CallManager) contains multiple denial of service (DoS) vulnerabilities that if exploited could cause an interruption of voice services. The Session Initiation Protocol (SIP), Skinny Client Control Protocol (SCCP) and Computer Telephony Integration (CTI) Manager services are affected by these vulnerabilities.

To address these vulnerabilities, Cisco has released free software updates for select Cisco Unified Communications Manager versions. There is a workaround for of one the vulnerabilities.

The following products are affected by vulnerabilities that are described in this advisory:

* Cisco Unified Communications Manager 4.x
* Cisco Unified Communications Manager 5.x
* Cisco Unified Communications Manager 6.x
* Cisco Unified Communications Manager 7.x

Administrators can mitigate the SCCP- and SIP-related vulnerabilities by implementing filtering on screening devices to permit access to TCP ports 2000 and 2443, and TCP and UDP ports 5060 and 5061 only from networks that require SCCP and SIP access to Cisco Unified Communications Manager appliances.

It is possible to mitigate the CTI Manager vulnerability by disabling the CTI Manager service t is not necessary; however, this workaround will interrupt applications that reply on the CTI Manager service. Administrators can also mitigate the vulnerability by implementing filtering on screening devices to permit access to TCP port 2748 only from networks that require access to the CTI Manager service.

This advisory is posted at

Cisco FWSM SCCP Inspection DoS Vulnerability

A vulnerability exists in the Cisco Firewall Services Module (FWSM) for the Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers that may cause the Cisco FWSM to reload after processing a malformed Skinny Client Control Protocol (SCCP) message. The vulnerability exists when SCCP inspection is enabled.

Cisco has released free software updates that address this vulnerability.

All non-fixed 4.x versions of Cisco FWSM Software are affected by this vulnerability if SCCP inspection is enabled. SCCP inspection is enabled by default.

To check if SCCP inspection is enabled, issue the show service-policy | include skinny command and confirm that the command returns output. Example output follows:

fwsm#show service-policy | include skinny
Inspect: skinny , packet 0, drop 0, reset-drop 0

If SCCP inspection is not required, this vulnerability can be mitigated by disabling it. Administrators can disable SCCP inspection by issuing the no inspect skinny command in class configuration sub-mode within the policy map configuration. If SCCP inspection is required, there are no workarounds.

Cisco has released free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment.

This advisory is posted at

New DOS attacks threaten wireless data networks

Forget spam, viruses, worms, malware and phishing. These threats are apparently old school when compared to a new class of denial-of-service (DOS) attacks that threaten wireless data networks.

The latest wireless network threats were outlined in a talk here Thursday by Krishan Sabnani, vice president of networking research at Bell Labs, at the Cyber Infrastructure Protection Conference at City College of New York.

Sabnani said the latest wireless data network threats are the result of inherent weaknesses in Mobile IP, a protocol that uses tunneling and complex network triangulation to allow mobile devices to move freely from one network to another.

“We need to especially monitor the mobile networks – with limited bandwidth and terminal battery—for DOS attacks,” Sabnani said.

Here are five wireless data network threats outlined by Sabnani:

1. Signaling DOS

2. Battery Drain

3. Peer-to-Peer Applications

4. Malfunctioning Air Card

5. Excessive Port Scanning

Read the full article on

Cisco: DoS protection using TCP Intercept

Every now and then, all network engineers have to deal with some kind of network attack.  Usually, the attack does not target the network devices, but the machines that provide services (e.g. www, database hosting…), because it’s more easy to find on the Internet a script that is probing port 80 for example, which by the way any kiddie can use, than to corrupt BGP in order to act as man-in-the-middle. Anyway, in front on the machine being attacked, there is a network device and even if the network component is not the target it can be affected (e.g. high traffic encounter during a denial-of-service attack). So, beside the fact that we have to protect the network components, we have the duty (at least moral) to help the team that is managing the servers to mitigate the attack.

For those of you who are not familiar I will explain shortly what is a Denial-of-Service (DoS) attack. A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a computer resource unavailable to its intended users. DoS attacks typically target sites or services hosted on high-profile web servers such as banks, credit card payment gateways, web hosting and so on. One common method of attack involves saturating the target machine with external communications requests, such that it cannot respond to legitimate traffic, or responds so slowly as to be rendered effectively unavailable. This extreme external communications requests can be achieved using ICMP flood, peer-to-peer attack, teardrop attack, nuke, application level floor and many other (too many…) methods and the purpose of this is the consuming of resources on the target machine so that it can no longer provide its intended service or obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately.

On method to prevent DoS attacks is to limit on the network device ( network router) the amount of connection which is allowed to pass to a server by using  TCP Intercept. The TCP intercept feature helps prevent SYN-flooding attacks by intercepting and validating TCP connection requests. In intercept mode, the TCP intercept software intercepts TCP synchronization (SYN) packets from clients to servers that match an extended access list. The software establishes a connection with the client on behalf of the destination server, and if successful, establishes the connection with the server on behalf of the client and knits the two half-connections together transparently. Thus, connection attempts from unreachable hosts will never reach the server. The software continues to intercept and forward packets throughout the duration of the connection.

The main steps to enable TCP Intercept are:

1. Define an IP extended access list
Enable TCP intercept
3. Fine tune TCP intercept parameter

The TCP intercept can operate in either active intercept mode or passive watch mode. The default is intercept mode.
In intercept mode, the software actively intercepts each incoming connection request (SYN) and responds on behalf of the server with an ACK and SYN, then waits for an ACK of the SYN from the client. When that ACK is received, the original SYN is set to the server and the software performs a three-way handshake with the server. When this is complete, the two half-connections are joined.

In watch mode, connection requests are allowed to pass through the router to the server but are watched until they become established. If they fail to become established within a definite interval, the software sends a Reset to the server to clear up its state.

In the following topology we have the Server ( and the possible Attacker ( In the middle we have the router called R1 which is reponsible to mitigate the attack to port 80 on the Server. For this I would chose to apply the following configuration:

access-list 101 permit tcp any host eq 80

ip tcp intercept mode intercept
ip tcp intercept list 101
ip tcp intercept max-incomplete high 150
ip tcp intercept max-incomplete low 100
ip tcp intercept drop-mode oldest

Some explanation for the line above. We create an access-list matching the traffic from anywhere to the Server. We set the TCP intercept mode to intercept (this is not need actually, because it’s the default mode; I put it here just for the sanity of the example). When the connections are over 150 (…max-incomplete high 600) the router will start to drop connections starting with the oldest ones (..drop-mode oldest). As soon as the connection will be under 100, the router will cease to drop the connections. This are just values used for this example.

To check the TCP intercept you can use the following commands on the Cisco router:

show tcp intercept connections
show tcp intercept statistics

To check a live example of what you should see if your TCP Intercept configuration is working properly please click on the image below. The test is done in Dynamips environment with 2 VMware machines (client and server) using Ubuntu and a Cisco 3640 series router.

Cisco TCP Intercept