eSENTIRE discovers a Cisco VPN Denial of Service (DoS)
RESOLVED: Cisco Advisory
Historical Reference
As publicly disclosed on 2006-01-14 at Shmoocon 2006
A specific stream of 40-some packets, sent once, will remotely halt a Cisco VPN Concentrator running WebVPN within thirty seconds.
This remote exploit involves sending a small stream (less than 50 packets) of tcp/80 traffic to a Cisco VPN 3000 Concentrator appliance running the WebVPN service. After this occurs, all sessions currently accessing the appliance are dropped, and no further communication is possible until the system is powered down and restarted. No authentication or credentials are required to exercise this vulnerability.
By default, the WebVPN Service permits both tcp/80 (HTTP) and tcp/443 (HTTPS) inbound; the appliance performs a redirect from the HTTP query to the HTTPS. The vulnerability exists within the code base responsible for the redirect.
At present, we believe there is no firmware available from Cisco to resolve this issue. As a result, we strongly recommend that inbound tcp/80 be immediately disabled on all Cisco VPN 3000 Concentrator appliances as a workaround.
Updates at the end of the page.
Advisories:
Secunia Advisory (updated and accurate)
Cisco confirms VPN vulnerability
Background:
In the middle of August 2005, as part of a team performing an in-depth Internet security vulnerability assessment (one portion of a penetration test - also known as a "pen test" or "pentest") for a hedge fund client, security researcher Eldon Sprickerhoff discovered a method to remotely halt a Cisco VPN Concentrator running the popular WebVPN service in a default configuration. The Internet Storm Center (ISC) was contacted, and issued ticket 105494. Two ISC incident handlers recommended that the Cisco Product Security Incident Response Team (PSIRT) be contacted.
The exploit, instructions, and packet traces were sent to Cisco PSIRT on August 26th 2005, with a follow-up call from Cisco on September 2nd 2005. On October 3rd 2005, the Cisco Incident handler stated that code to resolve the problem had been written and that an advisory would be released later that month.
On January 5th 2006, eSentire requested a status update from the Cisco PSIRT contact. The PSIRT contact replied on January 6th and said that he had to check with some engineers. On January 12th 2006, the PSIRT contact replied that the problem would be resolved in an upcoming release but did not give a time.
Due to the fact that in excess of four months had passed since the vulnerability had been raised, Eldon Sprickerhoff chose to discreetly disclose certain aspects of it at the end of his Wireless Intrusion Prevention Systems talk on January 14th 2006 at Shmoocon 2006. Shmoocon is a small security convention, offering a forum to discuss "technology exploitation, inventive software and hardware solutions, as well as open discussion of critical information security issues" (from their website). The exploit was never given, but only an opaque description of the problem (partially involving charades) and the workaround suggested by eSentire.
Less than two weeks after Shmoocon, Cisco released an advisory. However, we believe that some errors exist within the advisory.
First, it states that this exploit may reload the affected device. In fact, it never reloads the device. The exploit completely freezes the device, requiring that the power cord be pulled out and reinserted to restart.
Second, it states that repeated exploitation of the vulnerability could result in a sustained Denial of Service. In fact, it is possible by performing the exploit once - the appliance is offline until the power can be manually recycled.
Finally, the advisory states that upgrading to firmware version 4.7.2B is sufficient to defend against this exploit. In October 2005, Eldon Sprickerhoff tested version 4.7.2B and found that this is not the case. The original tests were performed against VPN 3000 appliances running 4.7.1 but subsequent tests showed that 4.7.2B is also susceptible to this exploit.
The only way to currently protect one's Cisco VPN 3000 Concentrator running WebVPN is through the use of Access Control Lists (ACL's) or by disabling inbound tcp/80.
eSentire clients were informed of this vulnerability by September 2005. In accordance with responsible disclosure guidelines, we believe that seventeen weeks should be sufficient time to release an advisory regarding vulnerabilities to critical security infrastructure.
Cisco PSIRT has been informed of these issues, in greater depth than that detailed on this page.
UPDATE: 2006-02-01 We have been informed that release 4.7.2C resolves these issues. While eSentire has not tested this release, we recommend that all users upgrade to 4.7.2C AND disable inbound tcp/80 access.
UPDATE: 2006-02-06 We strongly urge all users to upgrade to the newest version (4.7.2D) AND disable inbound tcp/80 access as soon as they can. We will be releasing more details by the end of day.
UPDATE: 2006-02-07-a Many of you have mailed in, asking where is the update promised yesterday. We have been asked to postpone our update until 22h00 UTC (5PM Eastern) today.
UPDATE: 2006-02-07-b We have been informed by Cisco that the original vulnerability did not exist within the WebVPN code (as we had initially reported). Apparently, WebVPN did not need to be enabled on the concentrator for it to be vulnerable. While this does not change the external security perspective, it does leave the concentrator additionally vulnerable to an internal attack (for example, from a malicious insider).
UPDATE: 2006-02-07-c We have been working with Cisco PSIRT to demonstrate and reproduce the problem with 4.7.2B. To date, we have been successful in demonstrating that there is a problem (but from their perspective, it appears that it is somewhat different from the pre-4.7.2B problem). Nevertheless, the end result is: all network connectivity to the box is halted, post-exploit.
While our tests to date have been exclusively against firmware 4.7.2B, we believe that all currently-available firmware (including 4.7.2C and 4.7.2D) are susceptible to the exploit as well, as they appear to be bug fixes which do not appear to involve the vulnerable code.
Cisco is currently working in analyzing the traffic capture, intent on correcting the defect in their code and will update their advisory when a fix is available. In the meantime, we recommend (again) that inbound tcp/80 be blocked to all Cisco VPN concentrators - whether or not they are running WebVPN.
UPDATE: 2006-02-07-d As a side research idea, we are willing to entertain the possibility that the errant software modules might be conceivably be deployed within other Cisco products (due to code reuse) including their Self-Defending Network security strategy (as mentioned in the URL). We do not have access to this product line, but if anyone out there does, and is willing to offer up an externally-accessible tcp/80 and tcp/443 connection to it, we would be interested in testing the exploit against it (email me at eldons@ to arrange).
UPDATE: 2006-02-10 Received a call from our Cisco PSIRT contact saying that while version 4.7.2E will be released shortly, it was a bug fix that was already "in the pipe" and will not address this vulnerability.
UPDATE: 2006-02-23 In this month's Information Security magazine, their Products Of The Year feature states that the Gold medal for Remote Access products belongs to the Cisco VPN 3000 Series Concentrators.
UPDATE: 2006-03-07 While the title for this Internet Storm Center's alert seems like it applies to this exploit, it's a bit of a misnomer (and the alert is a bit old, as well). I'm glad that there's not yet a tool deployed to specifically look for VPN Concentrator 3000 web pages.
UPDATE: 2006-04-14 On March 21st, a new firmware version was extensively tested in Cisco's DMZ by eSentire staff. It looks like the vulnerability has been patched. We have no idea when the new firmware (and advisory) will be released by Cisco but it appears that the problem is solved!
UPDATE: 2006-04-26 Cisco has updated their advisory to describe the bugs uncovered, and list the firmware which addresses the exploit.