Friday, February 20, 2015

New Apache WSS4J and CXF releases

Apache WSS4J 2.0.3 and 1.6.18 have been released. Both releases contain a number of fixes in relation to validating SAML tokens, as covered earlier. In addition, Apache WSS4J 2.0.3 has unified security error messages to prevent some attacks (see here for more information). Apache CXF 3.0.4 and 2.7.15 have also been released, both of which pick up the recent WSS4J releases.

Monday, February 16, 2015

Unified security error messages in Apache WSS4J and CXF

When Apache WSS4J encounters a error on processing a secured SOAP message it throws an exception. This could be a configuration error, an invalid Signature, incorrect UsernameToken credentials, etc. The SOAP stack in question, Apache CXF for the purposes of this post, then converts the exception into a SOAP Fault and returns it to the client. However the SOAP stack must take care not to leak information (e.g. internal configuration details) to an attacker. This post looks at some changes that are coming in WSS4J and CXF in this area.

The later releases of Apache CXF 2.7.x map the WSS4J exception message to one of the standard error QNames defined in the SOAP Message Security Profile 1.1 specification. One exception is if a "replay" error occurred, such as if a UsernameToken nonce is re-used. This type of error is commonly seen in testing scenarios, when messages are replayed, and returning the original error aids in figuring out what is going wrong. Apache CXF 3.0.0 -> 3.0.3 extends this functionality a bit by adding a new configuration option:
  • ws-security.return.security.error - Whether to return the security error message to the client, and not one of the default error QNames. Default is "false".
However, even returning one of the standard security error QNames can provide an "oracle" for certain types of attacks. For example, Apache WSS4J recently released a security advisory for an attack that works if an attacker can distinguish whether the decryption of an EncryptedKey or EncryptedData structure failed. There are also attacks on data encrypted via a cipher block chaining (CBC) mode, that only require the knowledge about whether the specific decryption failed.

Therefore from Apache WSS4J 2.0.3 onwards (and CXF 3.0.4 onwards) a single error fault message ("A security error was encountered when verifying the message") and code ("http://ws.apache.org/wss4j", "SecurityError") is returned on a security processing error. It is still possible to set "ws-security.return.security.error" to "true" to return the underlying security error to aid in testing etc.

Tuesday, February 10, 2015

Two new security advisories released for Apache WSS4J

Two new security advisories have been released for Apache WSS4J, both of which were fixed in Apache WSS4J 2.0.2 and 1.6.17.
  • CVE-2015-0226: Apache WSS4J is (still) vulnerable to Bleichenbacher's attack
  • CVE-2015-0227: Apache WSS4J doesn't correctly enforce the requireSignedEncryptedDataElements property
Please see the Apache WSS4J security advisories page for more information.

Tuesday, February 3, 2015

New SAML validation changes in Apache WSS4J and CXF

Two new Apache WSS4J releases are currently under vote (1.6.18 and 2.0.3). These releases contain a number of changes in relation to validating SAML tokens. Apache CXF 2.7.15 and 3.0.4 will pick up these changes in WSS4J and enforce some additional constraints. This post will briefly cover what these new changes are.

1) Security constraints are now enforced on SAML Authn (Authentication) Statements

From the 1.6.18 and 2.0.3 WSS4J releases, security constraints are now enforced on SAML 2.0 AuthnStatements and SAML 1.1 AuthenticationStatements by default. What this means is that we check that:
  • The AuthnInstant/AuthenticationInstant is not "in the future", subject to a configured future TTL value (60 seconds by default).
  • The SessionNotOnOrAfter value for SAML 2.0 tokens is not stale / expired.
  • The Subject Locality (IP) address is either a valid IPv4 or IPv6 address.
2) Enforce constraints on SAML Assertion "IssueInstant" values

We now enforce that a SAML Assertion "IssueInstant" value is not "in the future", subject to the configured future TTL value (60 seconds by default). In addition, if there is no "NotOnOrAfter" Condition in the Assertion, we now enforce a TTL constraint on the IssueInstant of the Assertion. The default value for this is 30 minutes.

3) Add AudienceRestriction validation by default

The new WSS4J releases allow the ability to pass a list of Strings through to the SAML validation code, against which any AudienceRestriction address of the assertion are compared. If the list that is passed through is not empty, then at least one of the AudienceRestriction addresses in the assertion must be contained in the list. Apache CXF 3.0.4 and 2.7.15 will pass through the endpoint address and the service QName by default for validation (for JAX-WS endpoints). This is controlled by a new JAX-WS security property:
  • ws-security.validate.audience-restriction: If this is set to "true", then IF the SAML Token contains Audience Restriction URIs, one of them must match either the request URL or the Service QName. The default is "true" for CXF 3.0.x, and "false" for 2.7.x.

Wednesday, January 28, 2015

LDAP support in Apache Camel

Apache Camel allows you to add LDAP queries to your Camel routes via the camel-ldap and camel-spring-ldap components. The camel-ldap component allows you to perform an LDAP query using a filter as the message payload. The spring-ldap component is a wrapper for Spring LDAP, and is a bit more advanced than the camel-ldap component, in that it also supports the "bind" and "unbind" operations, in addition to "search".

I've created two test-cases that show how to use each of these components. Both test-cases use the Camel file component to read in files that contain LDAP queries. These queries are then dispatched to an Apache DS server that is configured via annotations in the test code, using an LDIF file containing some test data. The results are then processed and written out in the target directory. The test-cases are available here

Monday, January 19, 2015

Apache Santuario - XML Security for Java 2.0.3 and 1.5.8 released

Versions 2.0.3 and 1.5.8 of Apache Santuario - XML Security for Java have been released. Version 2.0.3 contains a critical security advisory (CVE-2014-8152) in relation to the new streaming XML Signature support introduced in version 2.0.0:
For certain XML documents, it is possible to modify the document and the streaming XML Signature verification code will not report an error when trying to validate the signature.

Please note that the "in-memory" (DOM) API for XML Signature is not affected by this issue, nor is the JSR-105 API. Also, web service stacks that use the streaming functionality of Apache Santuario (such as Apache CXF/WSS4J) are also not affected by this vulnerability.
Apart from this issue, version 2.0.3 contains a significant performance improvement, and both releases contain minor bug fixes and dependency upgrades.

Wednesday, January 14, 2015

XML Advanced Electronic Signature (XAdES) support in Apache Camel

I have previously covered some XML Signature and Encryption testcases in Apache Camel. Camel 2.15 will feature some new limited support for XML Advanced Electronic Signatures (XAdES) in the XML Security component. This post will briefly cover what XML Advanced Electronic Signatures are, and show how they can be produced in Camel. No support exists yet for validating XAdES Signatures in Camel. Note that as Camel 2.15 is not yet released, some of the details are subject to change.

XML Signature has a number of shortcomings in terms of conveying meta-data describing the signing process to the recipient. It does not include the signing certificate/key in the signature itself. It does not tell the recipient when or where the signature was created, which role the signer had at the time of signing, what format the signed data is in, what the signature policy was, etc. XAdES attempts to solve these problems by introducing standard properties that are inserted into the "Object" part of an XML Signature. Some of these properties are then included in the message signature.

Camel 2.15 will support XAdES in the XML Security component by a new "properties" configuration option, which must reference a XAdESSignatureProperties implementation. I added a new test to the camel-xmlsecurity project in github that illustrates how to do this. The spring configuration for the test is here. The xmlsecurity route links to a DefaultXAdESSignatureProperties implementation, which is configured with the signing key (and alias), an "Implied" Signature policy, and a role of "employee". The resulting ds:Object in the XML Signature looks like:

<ds:Object>
  <etsi:QualifyingProperties xmlns:etsi="..." Target="#...">
    <etsi:SignedProperties Id="_1c03790b-8e46-4837-85bc-d6562e4c713c"> 
      <etsi:SignedSignatureProperties>
        <etsi:SigningTime>2015-01-14T11:19:49Z</etsi:SigningTime>
        <etsi:SigningCertificate>
          <etsi:Cert>
            <etsi:CertDigest>
              <ds:DigestMethod Algorithm="...#sha256"/>
              <ds:DigestValue>KsquBA...=</ds:DigestValue>
            </etsi:CertDigest>
            <etsi:IssuerSerial>
              <ds:X509IssuerName>...,C=US</ds:X509IssuerName>
              <ds:X509SerialNumber>1063337...</ds:X509SerialNumber>
            </etsi:IssuerSerial>
          </etsi:Cert>
        </etsi:SigningCertificate>
        <etsi:SignaturePolicyIdentifier>
          <etsi:SignaturePolicyImplied/>
        </etsi:SignaturePolicyIdentifier>
        <etsi:SignerRole>
          <etsi:ClaimedRoles>
            <etsi:ClaimedRole>employee</etsi:ClaimedRole>
          </etsi:ClaimedRoles>
        </etsi:SignerRole>
      </etsi:SignedSignatureProperties>
    </etsi:SignedProperties>
  </etsi:QualifyingProperties>
</ds:Object>