Vulnerable Systems:
* Cisco CSS 11500 version 08.20.1.01
* Cisco ACE 4710 version A3(2.5) [build 3.0(0)A3(2.5)]
Immune Systems:
* Cisco CSS 11500 version 8.20.4.02
* Cisco ACE version A2(3.0).
On June 4th 2009, multiple weaknesses were identified in the Cisco CSS 11500's handling of HTTP header interpretation and client-side SSL certificates. Individually, these issues may be considered minor, but combined they could allow for the compromise of an application that relies on a vulnerable CSS to assist in authenticating clients. If successfully exploited, an attacker could spoof another application user's identity without possession of the victim's client certificate.
Additionally, due to the fact that the Cisco CSS product has been effectively superceded by the Cisco ACE, similar issues were also identified to those described below in the ACE in particular configurations.
These issues may affect any CSS installation, but would have the greatest impact on deployments that have the following feature enabled in the configuration:
ssl-server http-header client-cert
Similarly, on the Cisco ACE, these issues may manifest themselves when using a policy map with a class-default class, as shown below:
policy-map type loadbalance first-match SLB-VIP-REDIRECT
class class-default
serverfarm TEST-FARM
action DO-SOMETHING-WITH-HEADERS
insert-http X-SRC-IP header-value "%is"
Issue 1: Weak Enforcement of Authority in HTTP Certificate Headers
------------------------------------------------------------------
Cisco Bug Id - CSCSZ04690
Affects - Cisco CSS
The first weakness affecting the Cisco CSS is that, in a typical client certificate configuration, HTTP clients may confuse web applications by injecting their own certificate headers. When utilizing the CSS to terminate SSL communications, SSL client certificates are first authenticated by the CSS. From there, the CSS will normally pass the client's identity to the back-end web server in the form of several HTTP headers as shown below:
However, there is no attempt by the CSS to prevent clients from supplying their own ClientCert-* headers. Depending on how application developers handle multiple copies of these headers, an attacker may be able to impersonate other users. For example, assuming that a back-end web application simply trusts the user identity supplied by the CSS in the ClientCert-Subject-CN header and userX wants to impersonate userY, he may simply insert the following HTTP header(s) in the HTTP request issued to the server:
Since existing ClientCert-* headers are left intact, application developers are expected to trust only the last instance of a given certificate header. This approach is clearly prone to error if application developers do not carefully test this attack scenario.
An alternative approach to securing these headers can be achieved through an optional configuration where the CSS places an additional prefix string on the inserted certificate headers. For instance, a server administrator could select a random header prefix through a command such as:
This would cause the new certificate headers to be included with the form: <random_prefix>-ClientCert-*
So long as an attacker could not discover this random prefix, then there would be no way to spoof these headers. However, this solution is far from ideal, since there may be several ways for an attacker to obtain a copy of these headers. Examples include TRACE/TRACK requests being honored by the back-end web servers or debugging components in web applications which echo client headers.
Issue 2: Lack of HTTP Request Validation
----------------------------------------
Cisco Bug Id - CSCTA04885
Affects - Cisco CSS & ACE
A second weakness that manifests itself on the CSS and ACE through different interpretation of HTTP newline sequences between the content switch and commonly used web servers. RFC 2616 defines the US ASCII carriage return/line feed (CRLF) sequence as the end-of-line marker for protocol elements (excluding the entity-body). Indeed, the CSS and ACE appear to adhere relatively closely to this requirement.
Popular web servers, however, permit various permutations of the CRLF sequence as end-of-line markers, including: LF, CR, and LFCR. This difference in interpretation could lead to serious consequences if the device relies on any of these headers and end-of-line delimiters or makes changes to any of them. This has been well documented in the past in relation to HTTP request smuggling and related attacks.
Workaround:
There are currently no known workarounds for the end-of-line marker parsing vulnerability on the Cisco CSS. On the Cisco ACE customers are encouraged to utilize a layer 7 class map rather than simply using a VIP redirect.
In order to mitigate the risk of the ClientCert header insertion that may lead to user impersonation it is recommended the use of the following CSS/ACE command:
Where <random_prefix> is a difficult to guess value that is comprised of a combination of 3 of the 4 following character classes: lowercase alphabetic, uppercase alphabetic, numeric and special characters. The value should consist of a minimum of 8 characters, decreasing the likelihood of successful brute-force attacks.
It is strongly recommended disabling the TRACE/TRACK HTTP methods on the target web/application server and periodically changing the random prefix.
Other work arounds are possible if application administrators/developers are able to perform additional validation of user identities. One possibility would be to simply disable SSL termination at the Cisco CSS, instead performing certificate validation at the application server level. However, this may not be feasible in many environments.
As an alternative, user certificate headers could undergo a second round of validation at the application server level. For instance, randomized user IDs or user-specific secret values could be embedded in user certificate headers which would be passed along by the CSS to applications. Once received, application servers would validate this additional parameter to help prevent header spoofing in a user-specific way. However, while this could prevent blind certificate spoofing, an attacker who could perform man-in-the-middle attacks would likely be able to obtain certificate headers of other users
