Colm O hEigeartaigh

Subscribe to Colm O hEigeartaigh feed
Colm O hEigeartaigh
Updated: 21 hours 13 min ago

Denial of Service attacks on Apache CXF

Thu, 06/27/2013 - 16:52
A significant new paper has emerged called "A new Approach towards DoS Penetration Testing on Web Services" by Andreas Falkenberg of SEC Consult Deutschland GmbH, and Christian Mainka, Juraj Somorovsky and Joerg Schwenk of Ruhr-University Bochum. In this paper, the authors developed a suite of automated tests for various Denial of Service (DoS) attacks on Web Services, and ran them against different web service stacks. In this post I will describe the attacks that were successful on Apache CXF and how they were fixed.

The authors found that Apache CXF (prior to 2.7.4/ 2.6.7/ 2.5.10) was vulnerable (see CVE-2013-2160) to the following attacks:
  • Coercive Parsing Attack: The attacker sends a deeply nested XML document to the service.
  • Attribute Count Attack: The attacker sends a message with a (very) high attribute count.
  • Element Count Attack: The attacker sends a message with a (very) high number of non-nested elements.
  • DJBX31A Hash Collision: A specific hash collision attack.
The effects of these attacks can vary from causing high CPU usage, to causing the JVM to run out of memory. Clearly the latter is a critical vulnerability. Prior to CXF 2.7.4 / 2.6.7 / 2.5.10, a CXF service was vulnerable to these attacks "out of the box". However, it was possible to avoid some of the attacks using CXF's DepthRestrictingInterceptor. If this was added to the InInterceptor chain, then it was possible to control the stack depth + the number of elements in the request. However it was not possible to control the number of attributes with this interceptor, and it also came with a performance cost.

CXF uses Woodstox by default as the StAX XML Processor. It was decided that the best place to fix the vulnerabilities was at this level, both to offer protection to other stacks that use Woodstox, and also to remove the performance penalties associated with the DepthRestrictingInterceptor. From Woodstox 4.2.0, new functionality has been added to prevent Denial of Service attacks by restricting the size of XML. It uses the following defaults:
  • Maximum Attributes per Element: 1000.
  • Maximum Children per Element: (no effective bound).
  • Maximum Stack Depth: 1000.
  • Maximum Element Count: (no effective bound).
  • Maximum Number of Characters: (no effective bound).
These bounds are quite loose to preserve backwards compatibility. CXF 2.7.4 / 2.6.7 / 2.5.10 pick up Woodstox 4.2.0. Other parser implementations are defined as "insecure parsers" and are rejected by default from CXF 2.7.5 unless a System property is set. CXF restricts the Woodstox default values further:
  • Maximum Attributes per Element: 500.
  • Maximum Children per Element: 50000.
  • Maximum Stack Depth: 100.
CXF 2.7.4 / 2.6.7 / 2.5.10 are not vulnerable to any of the DoS attacks listed above due to these restrictions.

Categories: Colm O hEigeartaigh

Apache XML Security for Java 1.4.8 and 1.5.5 released

Tue, 06/25/2013 - 17:32
Two new versions of the Apache XML Security for Java project have been released and are available for download. These releases contain a fix for a critical security advisory CVE-2013-2172, which involves an XML Signature spoofing attack. Thanks to James Forshaw for reporting the vulnerability to the Apache Santuario project.
Categories: Colm O hEigeartaigh

Apache CXF 2.7.5 released

Wed, 05/22/2013 - 17:09
Apache CXF 2.7.5 has been released. The list of issues fixed is available here. The following security fixes of note have been made in this release:
  • The OpenSAML dependency has been upgraded from 2.5.1 to 2.5.3.
  • A change was made to the logic the STS uses to encrypt tokens that it issues. Previously it threw an exception if a key could not be found (at either service or at a more generic level) to use to encrypt the token. Now it only encrypts the token if a matching key can be found. This allows the ability to only encrypt tokens to specific "AppliesTo" endpoint addresses.
  • LDAP groups are now (better) supported as claims in the STS. See the following blog entry for more detail.
  • The CryptoCoverageChecker interceptor has been enhanced so that you can disable coverage checking for SOAP Faults. This is useful for testing/debugging if you want to figure out the root cause of a remote exception.
Categories: Colm O hEigeartaigh

Apache CXF 2.7.4 released

Thu, 04/25/2013 - 17:04
Apache CXF 2.7.4 (and 2.6.7 + 2.5.10) have been released. Users are strongly encouraged to upgrade to the latest versions, due to a critical security issue which must remain undisclosed for the moment. These latest releases pick up Apache Santuario 1.5.4 and Apache WSS4J 1.6.10. In addition to the fixes in these projects, CXF 2.7.4 contains a number of security fixes of interest.

1) WS-SecurityPolicy fixes

A large number of negative tests for WS-Security(Policy) were added to CXF to try to smoke out some remaining issues surrounding validating a request against a defined security policy. The following issues were fixed as a result:
  • Layout policies "LaxTimestampFirst" and "LaxTimestampLast" were not validated correctly.
  • X509Token "PKI" policies were not validated correctly.
  • The "OnlySignEntireHeadersAndBody" policy was not validated correctly.
  • The "ProtectTokens" policy was not validated correctly in conjunction with EndorsingSupportingTokens.
  • SAML Token versions weren't validated against policy versions in certain circumstances.
2) Populating the SecurityContext from a JAAS Subject from WSS4J

An additional improvement to the WS-Security layer in CXF is that the SecurityContext is now populated from a JAAS Subject from WSS4J, if one is available. For example, if you are using a custom UsernameTokenValidator with WSS4J to validate a received UsernameToken via JAAS, and are returning the Subject (as per WSS4J's JAASUsernameTokenValidator), then CXF will attempt to extract roles from the Subject and populate the SecurityContext accordingly. The advantage of this is that a user can check the standard SecurityContext methods (e.g. "isUserInRole") to perform authorization.

This is controlled by two JAX-WS properties (see the documentation for more information):
  • ws-security.role.classifier - The Subject Role Classifier to use.  If this value is not specified, then it tries to get roles using the DefaultSecurityContext in cxf-rt-core. Otherwise it uses this value in combination with the "ws-security.role.classifier.type" property to get the roles from the Subject.
  • ws-security.role.classifier.type - The Subject Role Classifier Type to use. Currently accepted values are "prefix" or "classname". Must be used in conjunction with the "ws-security.role.classifier". The default value is "prefix".
3) STS fixes

The SecurityTokenService (STS) fixes contained in this release are:
  • The STS Client was not always sending an "AppliesTo" address in a request to the STS, depending on how the STS Client was deployed.
  • The STS Client was always using the "old" WS-Policy namespace for "AppliesTo", instead of getting the namespace from the policy.
  • The STS now supports processing Claims in a request that are retrieved from a security policy as "IssuedToken/Claims". Previously, it would only issue claims that were contained in a "RequestSecurityTokenTemplate" policy. 
4) CVE-2012-5572

Finally, a note on security advisory CVE-2012-5572 was added to the CXF security advisories page. This attack exploits the fact that Apache CXF will attempt to decrypt arbitrary ciphertexts, without first checking to see if the algorithm corresponds to the given encryption algorithm defined by the WS-SecurityPolicy AlgorithmSuite definition. This can be exploited by chosen ciphertext attacks to retrieve the plaintext. Please note that this issue has been fixed since CXF 2.5.7, 2.6.4, and 2.7.1.

    Categories: Colm O hEigeartaigh

    Apache Santuario 1.5.4 and Apache WSS4j 1.6.10 released

    Fri, 04/19/2013 - 17:37
    Two new bug-fix releases of note in Apache security products:

    Apache Santuario 1.5.4 has been released. Amongst the issues fixed is a thread-safety problem when secure validation is enabled, and a possible NPE due to ThreadLocal storage when an application is deployed in certain containers.

    Apache WSS4J 1.6.10 has also been released. The issues fixed are available here. A performance issue was fixed in the MemoryReplayCache, which is used to guard against replay attacks. An interop issue was fixed with older Axis 1.x stacks. UsernameTokens with no password elements have been explicitly disallowed by default (although this is configurable). Finally, "time-to-live" functionality has been added to disallow "stale" UsernameTokens (with older Created values).
    Categories: Colm O hEigeartaigh

    Signature and Encryption Key Identifiers in Apache WSS4J

    Thu, 03/14/2013 - 14:31
    The Apache WSS4J configuration allows you to specify how to reference a public key or certificate when signing or encrypting a SOAP message via the following configuration items:
    This blog entry will explain what values are valid for each of these configuration items, and will explain what each of these values means. Firstly, let's look at what these configuration items refer to.

    When creating a Signature you have the option of adding content to the Signature KeyInfo Element. This lets the recipient know what certificate/public key to use to verify the signature. Specifying a value for WSHandlerConstants.SIG_KEY_ID allows you to change how to refer to the key.

    When encrypting some part of the message, a session key is typically generated and used to encrypt the message part, which is then wrapped in an EncryptedData Element. This refers (typically via a Direct Reference) to a EncryptedKey Element in the security header, where the session key is encrypted using the public key of the recipient. Specifying a value for WSHandlerConstants.ENC_KEY_ID allows you to change how to refer to the public key of the recipient in the EncryptedKey KeyInfo element.

    The following valid values for these configuration items are:
    • IssuerSerial (default)
    • DirectReference
    • X509KeyIdentifier
    • Thumbprint
    • SKIKeyIdentifier
    • KeyValue (signature only)
    • EncryptedKeySHA1 (encryption only)
    1) IssuerSerial

    This (default) key identifier method means that the Issuer Name and Serial Number of a X.509 Certificate is included directly in the KeyInfo Element. For example:


    The certificate is not included in the message and so the recipient will have to have access to the certificate matching the given Issuer Name and Serial Number in a keystore.

    2) DirectReference

    This key identifier method is used when the X.509 Certificate is included in the message, unlike the IssuerSerial case above. The certificate is Base-64 encoded and included in the request via a BinarySecurityToken element, e.g.:

    <wsse:BinarySecurityToken EncodingType="...#Base64Binary"

    This Certificate is then referred to directly from the KeyInfo Element as follows:

            <wsse:Reference URI="#X509-..." ValueType="...#X509v3"/>

    3) X509KeyIdentifier 

    This key identifier method is similar to DirectReference, in that the certificate is included in the request. However, instead of referring to a certificate, the certificate is included directly in the KeyInfo element, e.g.:

            <wsse:KeyIdentifier EncodingType="...#Base64Binary"

    4) Thumbprint

    This Key Identifier method refers to the Certificate via a SHA-1 Thumbprint. The certificate may or may not be included in the request. For example:

            <wsse:KeyIdentifier EncodingType="...#Base64Binary"

    5) SKIKeyIdentifier

    This Key Identifier method refers to a Certificate via a Base-64 encoding of the Subject Key Identifier, e.g.:

            <wsse:KeyIdentifier EncodingType="...#Base64Binary"

    6) KeyValue

    This Key Identifier method only applies for Signatures. It includes the (RSA) PublicKey directly in the Signature KeyInfo Element as follows:


    7) EncryptedKeySHA1

    This Key Identifier method only applies for Encryption. Unlike the previous methods it refers to the way the EncryptedData references the EncryptedKey Element, rather than the way the EncryptedKey Element refers to the public key. For example:

        <wsse:KeyIdentifier EncodingType="...#Base64Binary"   

    Categories: Colm O hEigeartaigh

    Recent security advisories for Apache CXF

    Thu, 02/28/2013 - 23:46
    Apache CXF 2.7.3 (release notes), 2.6.6, and 2.5.9 have been released and are available for download. These releases contain fixes for a number of critical security issues, which I will describe below.

    1) CVE-2012-5633

    A security advisory has been issued in relation to a possible circumvention of WS-Security processing of an inbound request, due to the URIMappingInterceptor in CXF. This is a legacy interceptor (largely made redundant by JAX-RS) that allows some basic "rest style" access to a simple SOAP service. The vulnerability occurs when a simple SOAP service is secured with the WSS4JInInterceptor. WS-Security processing is completely by-passed in the case of a HTTP GET request, and so unauthenticated access to the service can be enabled by the URIMappingInterceptor.

    This is a critical vulnerability if you are using a WS-Security UsernameToken
    or a SOAP message signature via the WSS4JInInterceptor to authenticate users
    for a simple SOAP service. Please note that this advisory does not apply if
    you are using WS-SecurityPolicy to secure the service, as the relevant policies
    will not be asserted. Also note that this attack is only applicable to
    relatively simple services that can be mapped to a URI via the URIMappingInterceptor.

    Although this issue is fixed in CXF 2.5.8, 2.6.5 and 2.7.2, due to a separate
    security vulnerability (CVE-2013-0239), CXF users should upgrade to either 2.5.9, 2.6.6, or 2.7.3.

    2) CVE-2013-0239

    A security advisory has been issued in relation to an authentication bypass involving a UsernameToken WS-SecurityPolicy requirement. If a UsernameToken element is sent with no password child element, then authentication is bypassed by default. This is due to the use-case of supporting deriving keys from a UsernameToken, where a password element would not be sent in the token.

    The vulnerability does not apply in any of the following circumstances:
    • You are using a custom UsernameTokenValidator which does not allow the 'verifyUnknownPassword' use-case, or that otherwise insists that a password must be present in the token (such as the 'JAASUsernameTokenValidator' in WSS4J).
    • You are using a 'sp:HashPassword' policy that requires a hashed password to be present in the token.
    • You are using the older style of configuring WS-Security without using WS-SecurityPolicy.
    If you are relying on WS-SecurityPolicy enabled plaintext UsernameTokens to
    authenticate users, and if neither points a) nor b) apply, then you must
    upgrade to either CXF 2.5.9, 2.6.6 or 2.7.3, or else configure a custom
    UsernameTokenValidator implementation to insist that a password element must
    be present.

    3) Note on CVE-2011-2487

    A security advisory 'note' was also published to the CXF Security Advisories page, giving details on an attack against XML Encryption that affects users of older versions of CXF (prior to 2.5.3 and 2.4.7). It carries the following recommendation:
    It is recommended that the use of the RSA v1.5 key transport algorithm be discontinued. Instead the RSA-OAEP key transport algorithm should be used. This algorithm is used by default from WSS4J 1.6.8 onwards. If you are using WS-SecurityPolicy, then make sure not to use the AlgorithmSuite policies ending in "Rsa15.
    Categories: Colm O hEigeartaigh

    WS-Federation support in Apache CXF

    Sat, 02/23/2013 - 15:39
    Apache CXF is a leading web services stack with excellent support for a long list of security protocols such as WS-Security, OAuth, etc. A recent addition to this list is support for WS-Federation via the Apache CXF Fediz subproject. In this post, we will introduce Fediz and illustrate how to secure a web application with Fediz via an example.

    1) Introducing Apache CXF Fediz

    The Apache CXF Fediz subproject provides an easy way to secure your web applications via the WS-Federation Passive Requestor Profile. A good place to start in understanding this profile is to look at the Fediz architecture page. A typical scenario is that a client browser will attempt to access a web application secured with a Fediz plugin. Fediz will redirect the brower to an Identity Provider (IdP) for authentication, if no token/cookie is present in the request. In this way, authentication is externalized from the web application to a third party IdP.

    Fediz ships with an IdP component, but naturally the Fediz container plugin is also tested with other implementations. The IdP prompts the user for her credentials, and authenticates them via a Security Token Service (STS). The IdP requests that the STS issues a signed SAML Token on successful authentication. The IdP is configured to request that the STS inserts certain "Claim" attributes in the SAML Token, where the specific "Claim" types are configured per-realm. The client brower is then redirected back to the application server with the inclusion of the SAML Token.

    The Fediz plugin parses the received SAML Token. Authentication is established via the trust verification of the signature on the token. Role-based Access Control (RBAC) is supported by configuring the plugin with a "roleURI" attribute (which should correspond to the standard Claims URI for a role). The corresponding attribute values are extracted from the SAML Token and stored as the role(s) of the user. The actual security enforcement is delegated to the underlying container / application server. The containers that are (planned to be) supported are:
    • Apache Tomcat - See here.
    • Jetty - See here, available in the forthcoming 1.1 release.
    • Spring - See here, available in the forthcoming 1.1 release.
    • JBoss - Planned for the forthcoming 1.1 release. 
    An important point to note is that the Fediz container plugin is actually protocol-agnostic. WS-Federation is the only protocol supported to date, but support for the SAML Web SSO Profile may be added at a later date. For more detailed information on Fediz you should refer to the documentation, and also to the excellent series of blog articles by Oliver Wulff, who is the main developer on Fediz.

    2) Fediz example

    Download the latest Apache CXF Fediz release (currently 1.0.3) here, and extract it to a new directory (${fediz.home}). It ships with two examples, 'simpleWebapp' and 'wsclientWebapp'. We will cover the former as part of this tutorial. We will use a Apache Tomcat 7 container to host both the Idp/STS and service application - this is not recommended, but is an easy way to get the example to work. Please see the associated README.txt of the simpleWebapp example for more information about how to deploy the example properly. Most of the deployment information in this section is based on the Fediz Tomcat documentation, which I recommend reading for a more in-depth treatment of deploying Fediz to Tomcat.

    a) Deploying the IdP/STS

    To deploy the Idp/STS to Tomcat:
    • Create a new directory: ${catalina.home}/lib/fediz
    • Edit ${catalina.home}/conf/ and append ',${catalina.home}/lib/fediz/*.jar' to the 'common-loader' property.
    • Copy ${fediz.home}/plugins/tomcat/lib/* to ${catalina.home}/lib/fediz
    • Copy ${fediz.home}/idp/war/* to ${catalina.home}/webapps
    Now we need to set up TLS:
    • Copy ${fediz.home}/examples/samplekeys/tomcat-idp.jks to ${catalina.home}.
    • Edit the TLS Connector in ${catalina.home}/conf/server.xml', e.g.: <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" keystoreFile="tomcat-idp.jks" keystorePass="tompass" clientAuth="false" sslProtocol="TLS" URIEncoding="UTF-8"  />
    Now start Tomcat, and check that the STS is live by opening the STS WSDL in a web browser: 'https://localhost:8443/fediz-idp-sts/STSService?wsdl'

    b) Deploying the service

    To deploy the service to Tomcat:
    • Copy ${fediz.home}/examples/samplekeys/tomcat-rp.jks to ${catalina.home}.
    • Copy ${fediz.home}/examples/simpleWebapp/src/main/config/fediz_config.xml to ${catalina.home}/conf/
    • Edit ${catalina.home}/conf/fediz_config.xml and replace '9443' with '8443'.
    • Do a "mvn clean install" in ${fediz.home}/examples/simpleWebapp
    • Copy ${fediz.home}/examples/simpleWebapp/target/fedizhelloworld.war to ${catalina.home}/webapps.
    c) Testing the service

    To test the service navigate to:
    • https://localhost:8443/fedizhelloworld/  (this is not secured) 
    • https://localhost:8443/fedizhelloworld/secure/fedservlet
    With the latter URL, the browser is redirected to the IDP and is prompted for a username and password. Enter "alice/ecila" or "bob/bob" or "ted/det" to test the various roles that are associated with these username/password pairs.

    Finally, you can see the metadata of the service via the standard URL:
    • https://localhost:8443/fedizhelloworld/FederationMetadata/2007-06/FederationMetadata.xml
    Categories: Colm O hEigeartaigh

    Recent security enhancements in Apache CXF 2.7.x

    Thu, 01/24/2013 - 20:17
    In this post, I will cover some new security features and enhancements that are contained in Apache CXF 2.7.2 (release notes), as well as the previous 2.7.1 release (release notes).

    1) STS Enhancements
    • The STS ClaimsManager used to call all ClaimsHandler implementations for processing. Now it only calls the implementations that support the requested claim (CXF-4461).
    • New functionality was added to the STS to support processing 'primary' and 'secondary' claims, and to merge claims with the same dialects (CXF-4664).
    • It is now possible for the STSClient to send a 'Claims' Element to the STS via a CallbackHandler (CXF-4638).
    • You can now configure signature + encryption Crypto objects in the STS via a URL or properties object, as per the runtime (CXF-4705).
    2) SAML Enhancements
    • SAML SubjectConfirmation requirements are now enforced for the non-policy case (CXF-4655).
    • The JAX-RS SAML interceptors have been enhanced to allow sending an existing SAML Token, rather than always creating one (CXF-4639).
    3) XACML Enhancements

    A new 'cxf-rt-security' module was introduced in CXF 2.7.1, for security functionality that is common to several of the runtime modules (WS-Security, RS-Security, etc.). For now this module contains some new security functionality based around XACML:
    • It contains some helper classes to construct XACML Request statements using OpenSAML for the XACML 2.0 core specification (see here), as well as the SAML Profile of XACML 2.0 (and here).
    • It contains an interface to create an XACML request given a Principal, list of roles and a CXF Message object, as well as a default implementation. This implementation follows the SAML 2.0 profile of XACML 2.0. The principal name is inserted as the Subject ID, and the list of roles associated with that principal are inserted as Subject roles.  The action to send defaults to "execute". The resource is the WSDL Operation for a SOAP service, and the request URI for a REST service. The current DateTime is also sent in an Environment.
    • An abstract interceptor is provided that wraps the XACML request creation functionality given above. It can perform an XACML authorization request to a remote PDP, and make an authorization decision based on the response. It takes the principal and roles from the CXF SecurityContext, and uses the XACMLRequestBuilder to construct an XACML Request statement.
    Categories: Colm O hEigeartaigh

    Apache WSS4J 1.6.9 released

    Mon, 01/07/2013 - 12:58
    Apache WSS4J 1.6.9 has been released. This release contains a single (critical) fix for a bug which prevented WSS4J 1.6.8 from working correctly in an OSGi container.
    Categories: Colm O hEigeartaigh

    Apache WSS4J 1.6.8 released

    Mon, 12/10/2012 - 15:33
    Apache WSS4J 1.6.8 has been released. The list of issues fixed is available here. One of the most significant improvements is a fix for using WSS4J with XML Signature on Websphere. A new feature has also been added to WSS4J 1.6.8, namely the ability to define which algorithms are acceptable when processing an inbound request. This functionality has already been integrated into CXF and will be available in the 2.7.1, 2.6.4 and 2.5.7 releases. This essentially means that rather than check the algorithms against the relevant AlgorithmSuite used as part of WS-SecurityPolicy after WSS4J has finished processing the security header, the algorithms will be checked by WSS4J in real-time when processing the header.

    A new page has been added to the WSS4J website which describes 'security best practices' when using WSS4J. The points are summarised as follows:
    • Upgrade from WSS4J 1.5.x to WSS4J 1.6.x
    • Upgrade to the latest minor release as soon as possible
    • Use WS-SecurityPolicy to enforce security requirements
    • Use RSA-OAEP for the Key Transport Algorithm
    • Avoid using a cbc Symmetric Encryption Algorithm
    • Use Subject DN regular expressions with chain trust
    • Specify signature algorithm on receiving side

    Categories: Colm O hEigeartaigh

    Apache XML Security for Java 1.5.3 released

    Mon, 10/22/2012 - 15:57
    Apache XML Security for Java 1.5.3 has been released. This release features support for new XML Signature 1.1 KeyInfo extensions. It also fixes a number of bugs including a problem when message sizes are greater than 512 MB. The list of issues fixed is available at the Apache JIRA.
    Categories: Colm O hEigeartaigh

    XML Signature Wrapping attacks on Web Services

    Wed, 10/03/2012 - 18:17
    The previous blog post looked at SOAP Action spoofing attacks on Web Services and discussed a recent security advisory in this area in Apache CXF. This vulnerability was uncovered with the help of the WS-Attacker tool referenced here. This paper also covers a different type of attack on WS-Security enabled Web Services, namely XML Signature Wrapping attacks. The WS-Attacker tool also offers some functionality to test Web Service endpoints for vulnerability against these types of attacks. In this post we will look at how to protect against XML Signature Wrapping attacks in Apache CXF.

    1) XML Signature wrapping attacks

    It is possible to sign a portion of a SOAP Web Service request or response at the message level using XML Signature. The message contains a security header with a Signature Element, that references one or more message parts that have been signed. Typically, the message parts are referenced by an Id, and so to validate the signature the recipient must find the Element in the request that has the corresponding Id. An XML Signature wrapping attack essentially exploits the fact that the Signature Element does not convey any information as to where the referenced Element(s) is(are) in the Document tree.

    Consider a scenario where the SOAP Body of a request is signed by a signature placed in the security header of the request. The message recipient checks that the signature is correct and validates trust in the signing credential. Finally, the recipient checks to see that the required Element (in this case the SOAP Body) was actually signed, by comparing the wsu:Id of the SOAP Body to the Reference URI in the Signature.

    An XML Signature wrapping attack against this scenario could work as follows. A malicious (man-in-the-middle) user could take a valid request and copy the SOAP body and insert it as part of a header in the request. The malicious user then freely alters the SOAP Body, but preserves the same wsu:Id. The message recipient must search for the Reference URI as part of the signature validation process, and hits the copied SOAP Body Element first. This verifies correctly as it has not been changed. Finally, the recipient checks to see if the Id of the SOAP Body was actually referenced in the signature (which it was, even though the SOAP Body itself was not signed).

    Apache WSS4J has a built-in guard against this kind of attack, whereby an ID referenced in an XML Signature cannot appear more than once in a SOAP Envelope. However, there are more sophisticated types of wrapping attacks which can defeat this defence. The crucial thing to realise is that for XML Signature you must check to see that what you are expecting to be signed was actually signed. Apache WSS4J does not perform this kind of check, instead it is left up to the third party application (Apache CXF for the purposes of this article). 

    2) Protecting against XML Signature wrapping attacks in Apache CXF

    There are two ways to configure WS-Security in Apache CXF, the recommended approach based on WS-SecurityPolicy, and the older and less sophisticated approach of specifying individual security actions to perform.

    2.1) WS-SecurityPolicy

    The WS-SecurityPolicy approach offers easy protection against signature wrapping attacks via the WS-SecurityPolicy SignedParts and SignedElements policies. The SignedElements policy takes a number of XPath expressions corresponding to the Elements that must be signed, should they be included in the request. The XPath expression must not be a relative expression for the purposes of protection against this attack.

    A more common approach is to use the WS-SecurityPolicy "SignedParts" policy. This policy allows the user to specify that the SOAP Body and any number of SOAP Headers must be signed. For example:

    <sp:Body />
    <sp:Header Name="..." Namespace="..."

    Apache CXF makes sure that the SOAP Body and any specified SOAP header is actually signed, rather that just comparing Id's as outlined in the attack scenario above, this circumventing any XML Signature wrapping attack.

    2.2) Older WS-Security approach

    The older non-policy based approach to configuring WS-Security does not perform any checking by default of what Elements were signed, and so is vulnerable to XML Signature wrapping attacks out of the box. One way to remedy this since CXF 2.2.8 is to install the CryptoCoverageChecker interceptor. This allows you to define an XPath Expression corresponding to an Element that must be signed (or encrypted). Installing this interceptor defeats an XML Signature Wrapping attack (see the wiki for more details).

    However, the CryptoCoverageChecker is somewhat complex to set up for the most common use-cases for signature verification and decryption, as it involves adding XPath expressions and the corresponding prefix/namespace pairs. In Apache CXF 2.4.9, 2.5.5 and 2.6.2, a new subclass of CryptoCoverageChecker has been introduced. The DefaultCryptoCoverageChecker provides an easy way to ensure that the SOAP Body is signed or encrypted, that the Timestamp is signed, and that the WS-Addressing ReplyTo and FaultTo headers are signed (if they are present in the message payload).

    The default configuation is that the SOAP Body, (WSU) Timestamp and WS-Addressing ReplyTo and FaultTo headers must be signed (if they exist in the message payload). This provides an out-of-the-box way of preventing XML Signature wrapping attacks. All that is required is that the DefaultCryptoCoverageChecker be added to the in-interceptor chain. I strongly recommend that you consider doing this if you are still using the older configuration for a WS-Security enabled endpoint. For example:

        <bean class="">
                    <entry key="action" value="Signature Timestamp"/>
                    <entry key="signaturePropFile" value="..."/>
                    <entry key="passwordCallbackClass"value="..."/>
        <bean class=""/>
    Categories: Colm O hEigeartaigh

    SOAP Action Spoofing Attacks on Web Services

    Thu, 09/20/2012 - 12:49
    A recent paper by Christian Mainka, Juraj Somorovsky and Jörg Schwenk at the Horst Görtz Institute for IT Security of the Ruhr University Bochum, describes an open-source tool that can be used to perform penetration testing attacks on Web Services. In particular, this tool has uncovered a vulnerability in Apache CXF to a type of SOAP Action spoofing attack, that is the content of a recently disclosed security vulnerability. This vulnerability has been fixed in versions 2.4.9, 2.5.5, and 2.6.2 of CXF.
    Each operation in a SOAP web service can be associated with a SOAP Action String, for example in the WSDL binding or via an annotation. The web service client can send the SOAP Action String as a header with the request as a way of letting the web service know what operation is required.

    In some cases, Apache CXF uses the received SOAP Action to select the correct operation to invoke, and does not check to see that the message body is correct. This can be exploitable to execute a SOAP Action spoofing attack, where an adversary can execute another operation in the web service by sending the corresponding SOAP Action. This attack only works if the different operation takes the same parameter types, and hence has somewhat limited applicability.

    This attack also only applies for web services that use unique SOAP Actions per service operation which is not the default in CXF. Also note that WS-Policy validation is done against the operation being invoked and thus the incoming message must meet those policy requirements as well, also limiting applicability.
    Categories: Colm O hEigeartaigh

    Apache WSS4J 1.6.7 released

    Fri, 08/03/2012 - 13:04
    Apache WSS4J 1.6.7 has been released. The release notes are available here. The main features of the release are:
    • A critical fix for a concurrency bug in the MemoryReplayCache
    • Subject DN Certificate Constraint support (as blogged previously).
    • A number of relatively minor fixes identified by interop testing with WCF.
    • A fix that prevented the 1.6.6 release from being deployed in an OSGi container.
    Categories: Colm O hEigeartaigh

    Subject DN Certificate Constraint support in Apache WSS4J and CXF

    Thu, 08/02/2012 - 17:18
    Apache WSS4J 1.6.7 features support for specifying constraints on the subject DN of the certificate used for signature validation. This functionality will also be available in the forthcoming Apache CXF 2.6.2, 2.5.5 and 2.4.9 releases.

    After a successful signature validation using a certificate referenced in the KeyInfo structure of an XML Signature, the next step is to establish trust in the certificate. The term "direct trust" applies to when the certificate is contained directly in the signature keystore. In this case, certificate constraints are not required as we "directly trust" the certificate. The term "chain trust" refers to when the issuing certificate of the certificate used for signature validation is contained in the signature truststore, and the certificate path of the received certificate is verified.

    There is a potential security issue when "chain trust" is applicable. Although the certificate used for signature validation might be "trusted" in a general sense (via a trusted issuing certificate), you may not wish to accept every certificate issued by the trusted certificate. This is particularly relevant if any certificate in your signature truststore is (or can potentially be) used to issue a wide range of certificates.

    This is where the concept of constraints on the subject DN of a trusted certificate comes in. The idea is that the user can specify a list of regular expressions, one of which (note not all) must be applicable to the subject DN of a (trusted) certificate used for signature verification. These constraints are not used when the certificate is contained in the keystore (direct trust). If no cert constraints are defined, and a successful trust validation is done using "chain trust", a warning message is logged indicating that a potential security risk exists in signature validaition.

    Subject DN Cert Constraints can be configured in WSS4J by specifying a WSHandlerConstants tag, see the WSS4J configuration page for more information. To see this functionality in action take a look at the corresponding WSS4J Unit Test, which uses a cert constraint of ".*CN=Colm.*O=Apache.*". Certificate constraint support can also be enabled in CXF via the endpoint property tag "ws-security.subject.cert.constraints". See the CXF WS-SecurityPolicy for more information.
    Categories: Colm O hEigeartaigh

    SAML Web SSO profile support in Apache CXF

    Tue, 06/19/2012 - 11:57
    Apache CXF has an impressive range of security features for JAX-RS endpoints. It also has excellent documentation in this space, see for example the JAX-RS documentation for OAuth, SAML Assertions and XML Encryption/Signature.  Apache CXF 2.6.1 enhances the JAX-RS security story further by featuring support for the SAML 2.0 Web SSO profile.

    The basic standard scenario for Web SSO involves a client browser accessing a secured (JAX-RS) endpoint. The endpoint constructs a SAML AuthnRequest and includes it in redirecting the browser to a Identity Provider (IDP) for authentication (via a dialog). The IDP constructs a SAML Response, and redirects the browser to a Request Assertion Consumer Service (RACS) URI contained in the AuthnRequest.  The RACS validates the SAML Response and redirects the browser yet again to the original secured endpoint. The endpoint stores the session in a cookie (hence single sign-on) and access is granted to the resource. The following steps detail how to implement this scenario in Apache CXF using the new "cxf-rt-rs-security-sso-saml" module.

    1) JAX-RS binding filters

    The SAML 2.0 bindings specification defines HTTP redirect and HTTP POST bindings which can be used to "redirect" the client browser, e.g. from the secured endpoint to the IDP. Apache CXF 2.6.1 provides a separate JAX-RS filter to support these bindings. Therefore, the first step in securing a JAX-RS endpoint is to decide which of these two bindings to use. The SamlRedirectBindingFilter class providers support for the HTTP redirect binding, and the SamlPostBindingFilter provides support for the HTTP POST binding. Both of these filters share the following configuration properties.

    1.1) Required Configuration Properties

    Each filter implementation must be configured with the URL of the IDP, as well as the URL of the RACS. It must also be configured with a SPStateManager implementation to keep track of the Authenticated sessions. CXF ships with an EhCache based implementation:
    • SPStateManager stateProvider - An object which keeps track of authenticated sessions.
    • String idpServiceAddress - The URL of the IDP.
    • String assertionConsumerServiceAddress - The URL of the RACS. This can be a relative or absolute URL.
    1.2) Signature Configuration Properties 

    The following configuration properties are only required if you wish to sign the AuthnRequest:
    • boolean signRequest - Whether to sign the AuthnRequest or not. The default is false.
    • String signatureUsername - The keystore alias to use to sign the AuthnRequest.
    • Crypto signatureCrypto - A WSS4J Crypto object if the SAML AuthnRequest is to be signed.
    • String signaturePropertiesFile - This points to a properties file that can be used to load a Crypto instance if the SAML AuthnRequest is to be signed. 
    • CallbackHandler callbackHandler - A CallbackHandler object to retrieve the private key password used to sign the request.
    • String callbackHandlerClass - A class name that is loaded for use as the CallbackHandler object. 
    Either the "signatureCrypto" or "signaturePropertiesFile" properties must be set if "signRequest" is set to true. Similarly, either "callbackHandler" or "callbackHandlerClass" must be configured.

    1.3) Optional Configuration Properties

    Here are some optional configuration properties that can be set:
    • long stateTimeToLive - The default value (in milliseconds) that a session is valid for. The default value is 2 minutes. 
    • String issuerId - The Issuer Id value to be included in the AuthnRequest. It defaults to the Base URI.
    • AuthnRequestBuilder authnRequestBuilder - An object that constructs the AuthnRequest. It defaults to DefaultAuthnRequestBuilder.
    There are some additional optional configuration properties relating to domains and web application contexts that will be covered in more detail on the CXF wiki.

    1.4) Sample Spring configuration

    Here is a sample spring configuration extract to support the redirect binding filter which signs AuthnRequests:

    <bean id="stateManager" class=""/>

    <bean id="ssoSignedRedirectURI"  class="">
            <property name="idpServiceAddress" value="https://.../idp-sig/"/>
            <property name="assertionConsumerServiceAddress"
            <property name="stateProvider" ref="stateManager"/>
            <property name="addEndpointAddressToContext" value="true"/>
            <property name="callbackHandlerClass" value="....SSOCallbackHandler"/>
            <property name="signatureUsername" value="myservicekey"/>
            <property name="signaturePropertiesFile" value=""/>
            <property name="signRequest" value="true"/>

    <jaxrs:server address="/app1">
           <jaxrs:serviceBeans><ref bean="..."/></jaxrs:serviceBeans>
           <jaxrs:providers><ref bean="ssoRedirectURI"/></jaxrs:providers>

    2) The Request Assertion Consumer Service

    The JAX-RS filters described above take care of creating a SAML AuthnRequest, optionally signing it, and redirecting the client browser to the IDP. The next step is to define a RequestAssertionConsumerService (RACS) which will intercept the SAML Response from the IDP. The RACS processes the SAML Response, and validates it in a number of ways:
    • The SAMLProtocolResponseValidator validates the Response against the specifications and checks the signature of the Response (if it exists), as well as doing the same for any child Assertion of the Response. It validates the status code of the Response as well. 
    • The SAMLSSOResponseValidator validates the Response according to the Web SSO profile. 
    If validation is successful the RACS redirects to the service provider endpoint.

    2.1) Configuration properties shared with the filters

    The RequestAssertionConsumerService that ships with CXF shares a number of configuration properties with the filters, mainly relating to state and signature configuration:
    • SPStateManager stateProvider - An object which keeps track of authenticated sessions. This is required.
    • long stateTimeToLive - The default value (in milliseconds) that a session is valid for. The default value is 2 minutes.
    • Crypto signatureCrypto - A WSS4J Crypto object to use to validate a signed Response.
    • String signaturePropertiesFile - This points to a properties file that can be used to load a Crypto instance for signature validation.
    • CallbackHandler callbackHandler - A CallbackHandler object to retrieve the private key password used to decrypt an encrypted request.
    • String callbackHandlerClass - A class name that is loaded for use as the CallbackHandler object.  
    Only the "stateProvider" property is required. Either the "signatureCrypto" or "signaturePropertiesFile" properties must be set if you wish to support verifying signed Responses, or signed Assertions contained in a Response. Similarly, either "callbackHandler" or "callbackHandlerClass" must be configured if you wish to support decrypting encrypted Assertions. 

    2.2) Additional Optional Configuration properties

    The RACS supports the following additional (optional) configuration properties:
    • boolean supportDeflateEncoding - Whether Deflate encoding is used to inflate a token received via the Redirect binding. The default is true.
    • boolean supportBase64Encoding - Whether the token is Base64 decoded or not. The default is true.
    • boolean enforceAssertionsSigned - Whether the Assertions contained in a Response must be signed or not. The default is true.
    • boolean enforceKnownIssuer - Whether the Issuer of the Response (and child Assertions) is "known" to the RACS. This value is compared against the IDP URL configured on the filter. The default value is true.
    • TokenReplayCache<String> replayCache - A TokenReplayCache implementation to store Assertion ID's for the POST binding to guard against replay attacks. The default uses an implementation based on EhCache.
    2.4) Sample Spring Configuration

    Here is a sample spring configuration extract to set up a RACS, that could be used with the filter configuration in section 1.4:

     <bean id="consumerService" class="">
            <property name="stateProvider" ref="stateManager"/>
            <property name="signaturePropertiesFile" value=""/>
            <property name="enforceKnownIssuer" value="false"/>
            <property name="callbackHandlerClass" value="...SSOCallbackHandler"/>

    3) The Identity Provider (IDP)

    The remaining piece of the puzzle is the Identity Provider (IDP) which receives the SAML AuthnRequest from the service provider, processes it accordingly, and then interacts with the client browser to authenticate the client. It then creates a SAML Response and redirects the client browser to the RACS defined in the AuthnRequest. Apache CXF does not (yet) ship with an IDP, although this may change in the near future. However, there are a number of open-source IDPs that can be used with a CXF JAX-RS endpoint that supports SAML Web SSO. These include Shibboleth, PicketLink, OpenAM, JOSSO, etc. I have tested against all of these products. Report any interop issues to the CXF JIRA.

    4) Ongoing Development

    SAML Web SSO profile support is still being actively developed. A number of bugs have been fixed that do not yet appear in a released version of CXF. For example, support for decrypting encrypted Assertions in a SAML Response, and some bugs relating to signed Assertions (CXF-4352 and CXF-4365).
    Categories: Colm O hEigeartaigh

    Simplified Apache CXF STS configuration

    Thu, 06/14/2012 - 15:29
    The Apache CXF STS configuration options have been covered in detail in previous posts on this blog. Following some suggestions by Glen Mazza, a new simplified way of configuring the STS will be available in Apache CXF 2.6.2. This new configuration is essentially a simpler and more intuitive way of catering for the most common STS scenarios. The older configuration style is still fully supported.

    An example of how to configure the CXF STS using the old configuration is available here. It involves a mixture of the STS Provider API that lives in the WS-Security module in CXF, and the concrete STS functionality that is available in the STS services module in CXF. The SecurityTokenServiceProvider in the CXF API is instantiated with implementations of the various Operations (Issue/Validate/etc.) that are available in the CXF STS. However, the flexibility of this approach leads to a slightly verbose configuration style, which is perhaps overly complicated for the most common use-cases.

    An example of the simpler configuration approach is available here. Rather than use the SecurityTokenServiceProvider in the CXF API, it uses a sub-class in the CXF STS (DefaultSecurityTokenServiceProvider). This implementation supports the issue and validate bindings by default. It also supports the ability to issue and validate SAML Tokens, and to validate UsernameTokens and X.509 Tokens. Therefore, for any of these use-cases there is no need to use the old-style configuration, which involves explicitly instantiating each TokenProvider or TokenValidator instance and setting them on an IssueOperation/ValidateOperation instance.  However, if you want to use the renew or cancel bindings, or do anything with SecurityContextTokens, it's necessary to use the old configuration.

    The DefaultSecurityTokenServiceProvider can be configured with the following (optional) properties:
    • boolean encryptIssuedToken - Whether to encrypt the issued token or not. The default is false.
    • List<ServiceMBean> services - A list of service endpoints to support. See here for more information.
    • boolean returnReferences - Whether to return references to an issued token or not. The default is true.
    • TokenStore tokenStore - The TokenStore caching implementation to use. See here for more information.
    • ClaimsManager claimsManager - The ClaimsManager to use if you want to be able to handle claims. See here for more information.
    Categories: Colm O hEigeartaigh

    New security vulnerabilities in Apache CXF

    Thu, 06/07/2012 - 11:50
    Two new security vulnerabilities have been announced in Apache CXF. Those of you using WS-SecurityPolicy should read the announcements carefully to make sure that you are not affected. If these vulnerabilities apply to your deployment then you should upgrade to a more recent version of CXF that contains fixes for these vulnerabilities. The issues in question are:
    • CVE-2012-2378 - Apache CXF does not pick up some child policies of
      WS-SecurityPolicy 1.1 SupportingToken policy assertions on the client
    • CVE-2012-2379 - Apache CXF does not verify that elements were
      signed or encrypted by a particular Supporting Token.

    Categories: Colm O hEigeartaigh

    Transforming Claims and Tokens in the CXF STS

    Wed, 06/06/2012 - 16:07
    The Security Token Service (STS) shipped with Apache CXF 2.6.0 contains some advanced functionality relating to handling claims, as well as transforming both claims and security tokens.

    1) ClaimsValue support

    The following article describes in detail how Claims are handled by the STS. The client includes a Claims element in the request to the STS, which typically contains one or more ClaimType URIs, that describe the types of claims that are to be included in the issued token. For example, the following element indicates that the client wants the STS to embed the role of the authenticated client in the issued token:

    <t:Claims Dialect="http://.../identity">
        <ic:ClaimType Uri="http://.../claims/role"/>

    The RequestParser object parses the client request and converts a received Claims element into a RequestClaimCollection object. The RequestClaimCollection is just a list of RequestClaim objects, along with a dialect URI. The RequestClaim object holds the claimType URI as well as a boolean indicating whether the claim is optional or not. Since the 2.6.0 (and 2.5.3) release, the RequestClaim object now also holds a claimValue String. This means that the STS now supports processing a Claims element with ClaimValue elements rather than ClaimType elements, e.g.:

    <t:Claims Dialect="http://.../identity">
        <ic:ClaimValue Uri="http://.../claims/role">

    2) Custom Claims Parsing

    Prior to CXF 2.5.3 and 2.6.0, it was not possible to change how the RequestParser parses a received Claims child element into a RequestClaim object. In CXF 2.5.3 and 2.6.0 this behaviour is configurable. The ClaimsParser interface defines a method to parse a Claims child element, as well as return the supported dialect URI that the implementation can handle. CXF ships with a default implementation that handles the "" URI, and can parse both ClaimType and ClaimValue elements.

    The RequestParser is passed a list of ClaimsParser objects, and iterates through the list to find a ClaimsParser implementation that can handle the given dialect. It uses the first ClaimsParser implementation that matches the supported dialect to generate a RequestClaim object. Therefore, to support a custom or non-standard Claims dialect, it is necessary to implement one or more ClaimsParser implementations to handle that dialect. These ClaimsParser objects must then be set on the ClaimsManager.

    3) Token and Claims Transformation

    The following blog article describes how token transformation works in the STS prior to CXF 2.5.3 and 2.6.0. Token transformation occurs when the user calls the WS-Trust Validate binding to validate a given token. If the token is valid, and if the user specifies a TokenType that differs from the type of the given token, the STS will attempt to transform the validated token into a token of the requested type. If the token is being issued in a different realm to that of the validated token, the principal associated with the validated token may also need to be transformed. This can be done by specifying an IdentityMapper object on the STSPropertiesMBean object used to configure the STS. This interface is used to map identities across realms. It has a single method:
    • Principal mapPrincipal(String sourceRealm, Principal sourcePrincipal, String targetRealm) - Map a principal from a source realm to a target realm
    If the source realm is not null (the realm of the validated token as returned in TokenValidatorResponse), and if it does not equal the target realm (as set by the RealmParser), then the identity mapper is used to map the principal to the target realm and this is stored in TokenProviderParameters for use in token generation.

    3.1) Transformation via Relationships

    The logic for token transformation as described above is abstracted in CXF 2.5.3 and 2.6.0 to add the ability to perform more powerful and custom token and claim transformations. Two new properties are added to the STSPropertiesMBean object:
    • List<Relationship> getRelationships() - Get the list of Relationship objects to use.
    • RelationshipResolver getRelationshipResolver() - Get the RelationshipResolver object to use.
    The Relationship class holds the parameters that will be required to define
    a one-way relationship between a source and target realm. It consists of five properties:
    • String sourceRealm - The source realm of this relationship.
    • String targetRealm - The target realm of this relationship.
    • IdentityMapper identityMapper - The IdentityMapper to use to map a principal from the source realm to the target realm.
    • ClaimsMapper claimsMapper - The ClaimsMapper to use to map claims from the source realm to the target realm.
    • String type - The relationship type. Two types of relationships are supported: FederatedIdentity and FederatedClaims.
    The RelationshipResolver is instantiated with a list of Relationship objects and contains the following method:
    • Relationship resolveRelationship(String sourceRealm, String targetRealm) - Retrieve the Relationship object that maps from the given source realm to the given target realm. 
    3.2) Principal Transformation using Relationships

    The logic described above for transforming principals when doing token transformation is still valid, but is deprecated in favour of using Relationships. When the token is being issued in a different realm to that of the validated token, the STS will first try to retrieve a RelationshipResolver object from the STSPropertiesMBean. If it exists, it will query it to retrieve a Relationship object that can map claims and principals from the source realm to the target realm. If it finds a match it will store this object on the token provider parameters, so the TokenProvider implementation can use this RelationshipResolver to perform some internal or custom mapping when generating the transformed token.

    If the type of the Relationship object matches the FederatedIdentity type, then the STS will try to retrieve an IdentityMapper object to map the principal from the Relationship object. Failing this it will try to query the STSPropertiesMBean object for a generic IdentityMapper object if one is configured. This IdentityMapper object will be used to map the principal to the target realm. 

    3.4) Claims Transformation using Relationships

    If the type of the Relationship object retrieved above is "FederatedClaims", then the principal is not mapped, as claims are transformed at the time when the claims are required to create a token, e.g. in ClaimsAttributeStatementProvider.

    Categories: Colm O hEigeartaigh