When misconfiguration means insecurity

Today Fortify announced that Web Services platforms, such as IBM WebSphere and Microsoft .NET WCF can be configured in ways which permit attacks.

They don't go into specifics, but it's long been well known that one vulnerability relates to the famous "Defective Sign and Encrypt" paper of Don Davis. That is, many Web Services platforms allow you to configure a policy which will sign the body of a SOAP message, using WS-Security, and then encrypt the body of the SOAP message, again using WS-Security. What is wrong with that?, you may ask. Well, a couple of things. Firstly, it means that the digest part of the signature is unencrypted, since it's up in the WS-Security block in the SOAP header and therefore escapes the encryption of the SOAP body. An attacker can use the digest to mount a plaintext-guessing attack on the SOAP body. Plaintext attacks in the world of Web Services are aided by the fact that most Web Services platforms expose WSDL for services by default, and that WSDL generally includes a Schema. The Schema gives the structure needed for the plaintext-guessing attack.

Timestamps are another common issue. Developers often do not understand what a replay attack is, assuming that it is something like a Denial-Of-Service attack (which, understandably, also may include a replayed message). But, a replay attack involves a valid message being obtained by an attacker, then replayed to a Web Service. This valid message may include a valid username/password combination, or a valid username and password digest combination, or a valid XML Signature. Often, a Web Services platform will be setup to validate incoming Usernames+Passwords, or validate an XML Signature and check that the signer is trusted. In these cases, without timestamp checking, the Web Services platform is vulnerable to a replay attack. A nonce ("number once") can also be used to block this attack.

Of course, XML Gateways such as Vordel's XML Gateway block these attacks, and add a level of security in front of the Web Services platform, even if the Web Services platform is misconfigured. And on the client side, you can test for Replay Attack vulnerability by using the Vordel SOAPbox as a testing client, create a WS-Security UsernameToken message or a WS-Security X.509 Certificate Token message, and simply send it through twice.


As a footnote, I should mention here Microsoft's "Project Somoa". This validates policies in .NET for security weaknesses. The Web page for Somoa on the Microsoft Research site seems to imply that it hasn't found its way into WCF yet [people from Microsoft please correct me if I'm wrong!].