Cisco: Multiple Vulnerabilities in Cisco PGW Softswitch

Multiple vulnerabilities exist in the Cisco PGW 2200 Softswitch series of products and they are related to processing Session Initiation Protocol (SIP) or Media Gateway Control Protocol (MGCP) messages.

SIP is a popular signaling protocol used to manage voice and video calls across IP networks such as the Internet. SIP is responsible for handling all aspects of call setup and termination. Voice and video are the most popular types of sessions that SIP handles, but the protocol is flexible to accommodate for other applications that require call setup and termination. SIP call signaling can use UDP (port 5060), TCP (port 5060), or Transport Layer Security (TLS; TCP port 5061) as the underlying transport protocol.

MGCP is the protocol for controlling telephony gateways from external call control elements known as media gateway controllers or call agents. A telephony gateway is a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or other packet networks.

Multiple DoS vulnerabilities exist in the Cisco PGW 2200 Softswitch SIP implementation, and one vulnerability is in the MGCP implementation.

The following vulnerabilities can cause affected devices to crash:

  • CSCsl39126 (registered customers only), CVE ID CVE-2010-0601
  • CSCsk32606 (registered customers only), CVE ID CVE-2010-0602
  • CSCsk40030 (registered customers only), CVE ID CVE-2010-0603
  • CSCsk38165 (registered customers only), CVE ID CVE-2010-0604
  • CSCsk44115 (registered customers only), CVE ID CVE-2010-1561
  • CSCsj98521 (registered customers only), CVE ID CVE-2010-1562
  • CSCsk04588 (registered customers only), CVE ID CVE-2010-1563
  • CSCsz13590 (registered customers only), CVE ID CVE-2010-1567

The following vulnerability may cause an affected device to be unable to accept or create a new TCP connection. Existing calls will not be terminated, but no new SIP connections will be established. If exploited, this vulnerability will also prevent the device from establishing any new HTTP, SSH or Telnet sessions.

  • CSCsk13561 (registered customers only), CVE ID CVE-2010-1565

There are no workarounds for the vulnerabilities in this advisory.


Great tool for testing QoS implementation

After my last post, some readers were asking what tool did I used for testing the QoS and how satisfied I’m with it.

The name of the tool is Packgen. According to its developer developers, “Packgen is a simple network packet generator handling diffserv markers, useful for testing network bandwidth and QoS.” It support features like:
– Network packet flows generation with given bandwidth (packets sent at each time interval depending on the bandwidth to produce and the size of the packets to generate);
– UDP and TCP flows;
– DSCP marking;
– Log generation which gives the possibility to compute statistics on the flows (to come later).

The main difference between IPerf (which is also a great testing tool, especially for bandwidth, jitter, packet loss tests…) and Packgen, is that the last one support diffserv marking natively. Of course you can achieve the same results with IPerf, with and ACL and inbound marking of the packets matched in the access-list, but with Packgen this is straight forward.

I had a little issue when downloading this tool, as the first result in Google search engine directed me to a page with no download link: This contains all the needed information about features, installation and how to use it (actually one of the best README that I ever saw for such tools), but no suggestion where to download the package. I search a little bit and you can download it from this official link.

To install this tool, you need to have Ruby on your system and then just run from inside the unpacked Packgen folder:

ruby ./setup.rb

Now some words about how to use it. From my post about AutoQoS, you can see that you need at least one client and one server. This 2 devices, use different files with Packgen (Don’t worry as the files come in the source package and if not, it’s very easy to create them).
First the server file, called listen.yml (if you create it, you can give whatever name you want) looks like this:



ports: !ruby/range 17000..17002

ports: !ruby/range 5002..5004

As you can see, there are 2 sections defined for UDP and TCP traffic. Then with “!ruby/range” you define a range where the server will listen. However, you can also simply use an Integer port number.

Then on the  client side, there is file called sent.yml:



name: Voice
bandwidth: 700Kb
packet_size: 252B
dscp: ef !ruby/range 0.0..60.0

name: Video
bandwidth: 2.8Mb
packet_size: 750B
dscp: cs4 !ruby/range 10.0..60.0

name: Best Effort
bandwidth: 3.2Mb
packet_size: 1KB !ruby/range 20.0..60.0

name: Background
bandwidth: 3.2Mb
packet_size: 1KB
dscp: cs1 !ruby/range 30.0..60.0

Here it’s a little bit more complex, but still human readable. This file also have 2 sections for UDP and TCP traffic, with the following paramters being defined:

-name: I believe it say everything
-host: ServerIP:port
-bandwidth: bandwidth to simulate
-packet size: packet in size in B, KB
-dscp: value !ruby/range: time intervals

After everything is defined, you just have to run Packgen to test.
On Server side first:

packgen -i listen.yml

Then on Client side:

packgen -i sent.yml

Optional you can add the -l file option, which will log the traffic send:

1258663872.6248 SEND dest=
1258663882.62591 SEND dest=
1258663895.65219 SEND dest=
1258663905.66876 SEND dest=
1258663933.72797 STOP dest=

or received:

1258663869.80496 LISTEN port=16384 proto=udp
1258663869.81079 LISTEN port=16385 proto=udp
1258663869.81441 LISTEN port=5002 proto=tcp
1258663869.81506 LISTEN port=5003 proto=tcp
1258663872.5886 RECV sent_at=1258663872.64102 flow=0 size=252 id=6
1258663872.58893 RECV sent_at=1258663872.64613 flow=0 size=252 id=7
1258663872.58903 RECV sent_at=1258663872.64719 flow=0 size=252 id=8
1258663872.58915 RECV sent_at=1258663872.65052 flow=0 size=252 id=9
1258663872.58924 RECV sent_at=1258663872.6742 flow=0 size=252 id=10

The configuration files and logs excerpt were from my AutoQos test. If you have any issues with using it, please contact me, or just check in details the documentation from developers site.

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

Cisco hidden tools: Testing TCP connection

Sometimes you have a connection between 2 routers that you want to test with something more than a ping. Cisco devices have a hidden command which is actually a very powerful testing tool for your TCP connection.

The command is “ttcp” and you will not find it in the the default list of commands of a Cisco device. So, even if you use help ( “?” mark at the router prompt) this command will not be showed to you.

For our testing we will use the same topology as in the previous posts. If you do not have it please download it here. Since this is a point-to-point TCP connection testing we will not use any fancy routing protocol or other networking protocols.

See the tutorial below: