Thursday, July 31, 2008

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!].

Wednesday, July 30, 2008

Unloved ESBs

It's open season on ESBs. Peter Lacey memorably described some of the reports he wrote as an analyst ( “Here’s 30 pages on how you might want to re-architect your software. Here’s 40 pages on why ESBs suck..."). Joe McKendrick wrote an excellent round-up, describing how ESBs are compared variously to Happy Meal freebie toys and house flies.

David Linthicum picks up the riff and describes how ESBs are "on trial". They certainly are, and I would say that the main trial offense is misrepresentation. Too many non-ESB products [app servers, EAI integration hubs] were rebadged as ESBs. This generated skepticism and annoyance.

It is an interesting fact that people are deploying XML Gateways as a kind of "ESB in a box" or "Lightweight ESB". It's been known for some time that you can do this with XML Gateways, but I suspect that the poor public reputation of the ESB product category is the reason why this is not shouted about this so much. Nobody wanted to be associated with ESBs. But, the use cases are valid, and products like Gateways can act as Lightweight ESBs.

Tuesday, July 29, 2008

When is it "SOA"? Ever?

Joe McKendrick asks "When is it SOA?"

When you have a bunch of Web Services, is that an SOA?

To give my answer on this question, I'll take a step back first. Twelve years ago, I was working in the EDI area. The company which I worked for managed the flow of structured business documents on its network. These documents were sales catalogs, purchase orders, corporate tax returns, and medical test results. Fast-forward to 2008, and now many of those documents are formatted as XML and sent over the Internet through secure pipes, making use of SSL and WS-Security.

At Vordel, many of our customers would fit into the category of "linking systems together using structured XML documents as the intermediate data format". Is this "SOA"? I can think of one example, a Vordel customer who provides services to telecoms providers. They receive feeds of data from their customers as XML. If I asked them "do you have an SOA?", they may answer "No", even through they are sending gigabytes of XML data between systems daily. What would make it an SOA? I would say the answer depends on where the initiative came from. If it came top-down from a CIO, with the registry bought up-front, then it's an SOA. If it's a grassroots pathfinder project from developers who want to make use of XML technology for integration, then it's not an SOA for the simple reason that nobody calls it an SOA. In that case, it is just a bunch of (very successful) Web Services.

Posts on Progress, and on XML Appliances

I am moving over to Blogger, so I'm coping over a recent blog post from my old Radio blog....

Monday, July 07, 2008

It almost seems like there is more blog comment on Progress Software's acquisition of Mindreef (terms not disclosed) then Progress Software's acquisition of the much larger Iona. The Progress/Iona news was originally broken by Jeff Schneider of Momentum SI, as reported by Joe McKendrick.

Joe McKendrick comments that:
"With IONA and Mindreef, Progress is clearly aiming to develop and offer an end-to-end suite of SOA products � from integration to management".

Progress has acquired in this area before, e.g. one of Vordel's competitors in the XML Networking area, Westbridge Technology, is part of the Progress/Sonic family. So is Actional which focussed on Web Services Management. The addition of Iona and Mindreef can be seen as Progress "going wide" by offering, as Joe McKendick says, a "full end-to-end suite of SOA products".

This makes sense. In our own Vordel product suite , we have the SOAPbox testing tool which, although not competing directly with Mindreef, is an example of an SOA testing tool. It is part of our product suite which includes our XML Gateway, XML Firewall, Service Usage Reporting, and, managing it all, our Policy Director (which direct policy out to the XML Networking components around the network).

As in the wider world beyond SOA, testing is often seen as an afterthought. But, like Progress, we have seen that is it important to have a testing tool as part of our suite. SOAPbox allows back-end services to be tested prior to the placement of an XML Gateway on the network. For example, if the XML Gateway is going to be used to throttle back the XML load to a level which can be managed by the back-end Services, then SOAPbox is used to test to see what this throttling level should be. The latest version of SOAPbox also simulates attacks on Services, attacks which of course are blocked by our XML Networking products.

So, it is important to "go wide" by having a testing tool as part of an overall suite.

But, it is also important to "do deep". When I read Joe McKendrick's analysis, I noticed the trackback from the iTKO blog. I jumped to the take on the iTKO blog, because I was very interested in their analysis, coming as it does from another SOA testing tool vendor. They were keep to point out that iTKO is a "SOA testing" company, not a "SOAP testing" company as in the case of Mindreef which focussed on SOAP and WSDL. But, they also mentioned an elephant in the room: SOAPUI. SOAPUI is a very capable SOAP testing tool which has a free basic version. The "basic" version is actually very capable. At Vordel we've often seen it used in Proof Of Concept bake-offs between vendors. The existence of SOAPUI means that other testing tools must "go deep" in order to add value. SOAPbox, as you might expect, goes deep on security. If you want to generate SAML 2.0 assertions on the client to send up to a SAML Relying Party, there aren't a lot of tools out there which will allow you to do this in just a few clicks, and with no coding. But, SOAPbox will. Similarly, in the latest version of SOAPbox, the insertion of attacks into XML messages is simple, in order to use it as an "attack dog" against Services which must be tested.

So, the message from the Progress acquisition of Mindreef is that it's important for testing tools to both "go wide" (as part of an overall suite) and "go deep" (not be commoditized by SOAPUI).
3:51:41 PM comment [0]

Steve Craggs on the "Litebytes" blog from Lustratus Research discusses Intel's foray into the XML software library market:

Turns out Intel are striking back at the burgeoning SOA Appliances market. The Intel claim is that its 'software appliance' performs at least as well as Appliances, and is therefore a better option.

As background, the software which Intel sells is the core of the old Sarvega product, which Intel acquired. They now sell this as a software XML toolkit.

Here at Vordel we make both software XML appliances and hardware XML appliances. Both have their advantages. Software XML Appliances have two key niches:
  1. Virtualization. In a virtualized environment, you can bring new instances of software XML Gateways on-stream instantly. This is simply not possible for a hardware product, where there are delivery lead-times.
  2. Policy development and testing. Even in situations where an organization wishes to go live with hardware XML appliances, it often makes sense to develop and test policies using a software instance of the XML appliance. This makes sense for cost and logistical reasons.
One aspect of software XML appliances is the (often mistaken) impression that "if it's software, anyone could built it". Steve Craggs acknowledges this, and mentions patents.

Perhaps the biggest worry I have, however, is that whatever one company has done in software, someone else can do too, and unless it is patent protected, there would be nothing to stop an appliance maker coming up with a super-fast parser, and then putting it into microcode.

This is a good point. Let's look at a case in point, in detail:

Crypto acceleration hardware is widely available, from companies like Cavium and nCipher, and it is greatly beneficial in accelerating XML Signature and XML Encryption. Such hardware is actually *more* useful for XML content-level security than for SSL, because with XML Encryption and XML Signature, you are usually doing assymetric operations for each message, whereas with SSL, you are only doing it at the initial handshake stage (WS-SX hasn't taken off sufficiently to change this yet).

So, it makes sense for XML appliances (like Vordel's) to contain crypto acceleration hardware. Also, as Intel point out, you can get really good XML processing performance by using highly-optimized code running on the latest multi-core processors. Those are the best of both worlds.

Take a step back and think about crypto accelerators: how do they do their acceleration? Is it "just fast because it's on hardware?". No, it is fast because it allows many operations (for SSL handshaking to multiple clients) to be done in a parallel fashion, not pushed one-at-a-time through the main CPU. If you apply the same thinking to an XML appliance, then you can run the XML structural and syntactic validation in highly-optimized code on the main CPU at the same time as the XML Signature checking on the crypto accelerator board. Then, you benefit from concurrency. You also are getting the best of both worlds: crypto processing on the crypto card and XML processing using highly-optimized code on the core CPU. XML per-message latency goes way down, using this method. Why do I mention this example in reference to Steve Cragg's comment about patents? Because it's something Vordel has patented: "Method and system for the simultaneous processing of document structure and electronic signature for electronic documents" .

I'd predict that despite the "software only" crowd (presently Intel would be in that category) or the "hardware only" crowd (e.g. IBM), there will still be a place for vendors like Vordel who provide both software and hardware XML appliances.

Dublin in September

As anyone who grew up in Ireland can tell you, September brings the best weather. It is hard to avoid the conclusion that the Irish summer is timed to coincide with back-to-school time.

This September in Dublin I'll be at the Vordel conference in Dublin. This is the fourth Vordel conference. Speakers are lined up this year from TIBCO, Dell, and Washington Mutual.

On a personal note, it's striking to note that the starting day of the conference, 24 September, is exactly ten years after the date when a security hole I discovered was first published, in 1998. I can remember the coverage in the Irish Independent and Evening Herald newspapers, and the frantic calls from online booksellers who were affected. Some details are still online here:

The conference URL is: