How do I remove this vulnerability on Concentrator

Unanswered Question
Jul 13th, 2007

Our Qualys security scan has scanned our external port our concentrator and has this vulnerability:

Cisco Internet Key Exchange (IKE) is exposed to a denial of service issue. This issue affects devices implementing IKE Version 1, and is due to resource exhaustion when handling a high rate of IKE requests. An attack of 10 packets per second at 122 bytes each is sufficient to cause denial of service conditions.

Cisco is tracking these issues with the following Bug IDs:

* CSCse70811 for Cisco IOS software

* CSCse89808 for Cisco VPN 3000 Concentrators

* CSCsb51032 for Cisco PIX firewalls


A successful attack may lead to denial of service to legitimate users.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Richard Burts Fri, 07/13/2007 - 06:26


If you look at the bug for VPN3000 concentrators it points to this advisory from Cisco:

The section of the advisory about concentrators essentially says that there is not anything you need to do because the VPN 3000 is architected to not crash or do bad things in this situation.

Here is some of that text. You can look at the advisory for the full text:

The VPN3000 system is designed to limit the impact of such an attack on system resources consumed by users already connected. If new IKE initiator packets are received and the available IKE negotiation slots are full, the new request will be discarded. This prevents CPU processing power and memory resources from being fully consumed by incoming IKE requests. The finite IKE negotiation slot design prevents new tunnel requests from degrading existing tunnels. The design goals of the VPN3000 are to allow the box to survive an attack without jeopardizing the tunnels already established and other functions performed by the device.

Legitimate IKE initiator packets from valid end users will have to compete for slots with an attacking stream of packets. An incoming attack stream of IKE initiator requests does not render the VPN3000 incapable of connecting a valid user, it simply reduces the likelihood that an IKE negotiation slot will be available when the user request arrives.

While under this type of attack, the VPN3000:

* Will not crash due to memory exhaustion

* Will not consume all available CPU cycles processing IKE requests

* Will not drop existing tunnels



whiteford Fri, 07/13/2007 - 06:39

Great, would that be the same for the threat I get:

TCP Sequence Number Approximation Based Denial of Service


TCP provides stateful communications between hosts on a network. TCP sessions are established by a three-way handshake and use random 32-bit sequence and acknowledgement numbers to ensure the validity of traffic. A vulnerability was reported that may permit TCP sequence numbers to be more easily approximated by remote attackers. This issue affects products released by multiple vendors.

The cause of the vulnerability is that affected implementations will accept TCP sequence numbers within a certain range, known as the acknowledgement range, of the expected sequence number for a packet in the session. This is determined by the TCP window size, which is negotiated during the three-way handshake for the session. Larger TCP window sizes may be set to allow for more throughput, but the larger the TCP window size, the more probable it is to guess a TCP sequence number that falls within an acceptable range. It was initially thought that guessing an acceptable sequence number was relatively difficult for most implementations given random distribution, making this type of attack impractical. However, some implementations may make it easier to successfully approximate an acceptable TCP sequence number, making these attacks possible with a number of protocols and implementations.

This is further compounded by the fact that some implementations may support the use of the TCP Window Scale Option, as described in RFC 1323, to extend the TCP window size to a maximum value of 1 billion.

This vulnerability will permit a remote attacker to inject a SYN or RST packet into the session, causing it to be reset and effectively allowing for denial of service attacks. An attacker would exploit this issue by sending a packet to a receiving implementation with an approximated sequence number and a forged source IP address and TCP port.

There are a few factors that may present viable target implementations, such as those which depend on long-lived TCP connections, those that have known or easily guessed IP address endpoints and those implementations with easily guessed TCP source ports. It has been noted that Border Gateway Protocol (BGP) is reported to be particularly vulnerable to this type of attack, due to the use of long-lived TCP sessions and the possibility that some implementations may use the TCP Window Scale Option. As a result, this issue is likely to affect a number of routing platforms.

Another factor to consider is the relative difficulty of injecting packets into TCP sessions, as a number of receiving implementations will reassemble packets in order, dropping any duplicates. This may make some implementations more resistant to attacks than others.

It should be noted that while a number of vendors have confirmed this issue in various products, investigations are ongoing and it is likely that many other vendors and products will turn out to be vulnerable as the issue is investigated further.


Successful exploitation of this issue could lead to denial of service attacks on the TCP based services of target hosts. Other consequences may also result, such as man-in-the-middle attacks.

Richard Burts Fri, 07/13/2007 - 07:54


Unfortunately I do not believe that the same thing applies to this vulnerability. I believe that the good news is that since most of the traffic to the concentrator is IPSec and not TCP based there is much less opportunity for the Denial of Service attack that is described.

Does the writeup describing the vulnerability have anything about how to mitigate the threat? Many of their vulnerabilities show links to Cisco site and to some description of mitigation strategies.

I assume that this vulnerability shows up because there are several open TCP ports on the concentrator (23 for telnet, 80 for HTTP) primarily used for management. If you configured the concentrator to use SSH instead of telnet and HTTPS instead of HTTP I wonder if that would tone down the vulnerability.



whiteford Fri, 07/13/2007 - 11:28

THis is the external port I'm scann and only 1723 is open. This is the solution, which I'm not to good and understanding:


Please first check the results section below for the port number on which this vulnerability was detected. If that port number is known to be used for port-forwarding, then it is the backend host that is really vulnerable.

Various implementations and products including Check Point, Cisco, Cray Inc, Hitachi, Internet Initiative Japan, Inc (IIJ), Juniper Networks, NEC, Polycom, and Yamaha are currently undergoing review. Contact the vendors to obtain more information about affected products and fixes. NISCC Advisory 236929 - Vulnerability Issues in TCP details the vendor patch status as of the time of the advisory, and identifies resolutions and workarounds.

The Internet Engineering Task Force (IETF) has developed an Internet-Draft titled Transmission Control Protocol Security Considerations that addresses this issue.


The following BGP-specific workaround information has been provided.

For BGP implementations that support it, the TCP MD5 Signature Option should be enabled. Passwords that the MD5 checksum is applied to should be set to strong values and changed on a regular basis.

Secure BGP configuration instructions have been provided for Cisco and Juniper at these locations:

Tested on port 1723 with an injected SYN/RST offset by 16 bytes.

The last threat is:

Pre-shared Key Off-line Bruteforcing Using IKE Aggressive Mode port 500/udp



IKE is used during Phase 1 and Phase 2 of establishing an IPSec connection. Phase 1 is where the two ISAKMP peers establish a secure, authenticated channel with which to communicate. Every participant in IKE must possess a key which may be either pre-shared (PSK) or a public key. There are inherent risks to configurations that use pre-shared keys which are exaggerated when Aggressive Mode is used.


Using Aggressive Mode with pre-shared keys is the least secure option. In this particular scenario, it is possible for an attacker to gather all necessary information in order to mount an off-line dictionary (brute force) attack on the pre-shared keys. For more information about this type of attack, visit


IKE Aggressive mode with pre-shared keys should be avoided where possible. Otherwise a strong pre-shared key should be chosen.

Note that this attack method has been known and discussed within the IETF IPSec Working Group. The risk was considered as acceptable. For more information on this, visit

Richard Burts Fri, 07/13/2007 - 13:15


TCP port 1723 is used for PPTP. Depending on how your concentrator is configured it may be running PPTP. If you are using that port, then you need it and the solution provided does not discuss how to mitigate the threat. It provides some information about mitigation for BGP but not for port 1723. My opinion is that the risk from this is not great.

I do not believe that any changes are required on your concentrator because of anything that this report says.




This Discussion