Truth in SOA

This is a two part blog post. In the first part I will try to explain the vulnerability so we can get a better handle on it, and in the second part we'll examine possible countermeasures and mitigation strategies.

There was some big news in the security world on November 4, 2009 when Marsh Ray released details about a newly published SSL/TLS vulnerability. Of course, selling security is all about creating Fear, Uncertainty and Doubt (FUD) and as such a number of websites and blogs also picked up the story. Most notably:

• Renegotiating TLS, Marsh Ray's original research on the subject
  
• Vulnerability in SSL/TLS protocol (from www.h-online.com)
  
• Another Protocol Bites the Dust, by Ben Laurie of Google
  
• MITM attack on delayed TLS-client auth through renegotiation, from Martin Rex of SAP
  
• SSL/TLS Authentication Gap (SSL Gap), from Phonefactor.com
  
• Vulnerability in SSL/TLS protocol, from Linux Today
  

The real question is whether you should be worried or not. I think that in order to answer this question we need to really dig into the details of how the attack works and then analyze the risk and potential mitigation factors from there. This particular attack is called a chosen plaintext attack. A successful attack will allow the attacker to do two things:

(1)   Execute a chosen HTTP transaction on the server. This could be any HTTP request that eventually does something important on the server side. For instance, a bank account transfer comes to mind as well as single message transactions such data insertion, but it could be any server-side action triggered by a specifically chosen HTTP request.

(2)   Gain information regarding the shared symmetric key used in an SSL session. (for a limited time). If the attacker knows a specific HTTP transaction produces a given plaintext, or plaintext sequence, he or she might be able to choose which plaintext blocks to encrypt and obtain the matching results. This may yield some information about the key. In this case, the attacker might accumulate many examples of the plaintext and matching cipher-text. As we will see, a sophisticated
attacker acting as a man-in-the-middle (MITM) will be able to inject plaintext and then have access to the corresponding ciphertext, and if he or she knows any information about the generated response, there may be a stretch of time (before the next renegotiation) where a chosen-plaintext attack is feasible.

In order to understand how this man in the middle attack (MITM) works, we have to first understand what happens inside an SSL handshake. SSL works in two broad phases: First, the handshake phase, and second, the application data phase. The handshake phase is where the shared, symmetric key is computed which is subsequently used in the application data phase of the protocol to encrypt application data traffic. The goal of SSL is to provide secure socket communication between two endpoints. In this respect, SSL is really a layer 4 protocol as it is communicating over standard sockets. I think we take SSL for granted due to its ubiquity, but the handshake is actually performing a cryptographic feat:  a shared symmetric key is securely generated between two parties that have never met before.

The protocol itself requires no initial shared secret information, only a set of trusted certificate-authority (CA) certificates on the client side (at a minimum). We also take these for granted because the certificate-authority vendors have placed "trusted" CA certificates in our browsers. As an exercise you can check your browser to see who you implicitly trust. In Firexfox 3.5.x this is under Tools > Options > Advanced > Encryption tab > View Certificates. In the latest Firefox I count 70 CA certificates (roughly).  Moreover, the protocol supports client authentication as well, which requires CA certificates be provisioned on the server similar to what we see in the browser.

Certificates are important in two respects for SSL. First and foremost they contain the public key used by the client to encrypt the pre-master secret during the handshake, and second, they are used to validate one or both sides of the communication using X.509 certificate path validation. Certificate path validation is the process of validating the trust on a certificate by checking that you trust the issuer of the certificate. This is done by looking at the issuer's issuer and so on, up the chain until you reach an implicitly trust CA certificate, called a root CA.

The limitation that Marsh Ray uncovered has to do with renegotiation of the shared secret, which I will call the renegotiation gap. SSL allows for either side to renegotiate the master secret at any time by sending an appropriate message, either from the client or server. Renegotiation can be done for any number of reasons – to refresh the shared secret, to change the cipher, or to change the mode of the protocol to a different form. It can also be done for no good specific reason, simply by having the client send a new client hello. Usually, however, renegotiation is a move from one-way SSL (server authentication) to two-way SSL (client authentication).The first thing we will do in order to understand the renegotiation gap is dig into the handshake.

The SSL Handshake

To see the problem, you have to put yourself in the mind of the attacker and treat the handshake like an information game with state changes along the way. The goal of the game depends on the mode of the protocol, and for SSL this will either be a shared secret with server-side authentication, or a shared secret with both client and server authentication. In the case of server side authentication, the end goal is to generate a shared secret key where the client knows the identity of the server based on the limitations of PKI technology (certificate validation). In the case of client authentication, the goal of the game is to generate a shared secret where both sides know the identity of each other, again based on the limitations of PKI technology. Once you understand the additional information state at each stage of the handshake, it becomes trivial to see how a man-in-the-middle attack can work, and further, how the renegotiation gap changes the rules of the game.

First, let's lay out the handshake in 13 possible steps as follows. The table below is meant to be read from left to right and the ">" arrow denotes a message flowing from the client to the server. Similarly, the "<" indicator denotes a message from the server to the client. Once the handshake is finished, the game is over with one of two "normal" outcomes: (1) A shared secret was generated and the server was authenticated or (2) The shared secret was generated and both sides were authenticated. A critical point here is that a man in the middle of the SSL handshake changes the rules of the game and the information state.

In the table below note that "*" is used to denote optional messages in the SSL handshake, used in the case of client authentication. This implies that the shortest possible handshake (for server side authentication) is an exchange of 8 messages and the full handshake is 12 messages. It should be noted for completeness that the Server Key Exchange is only used when the certificate doesn't contain a public key, such as in the case of DSA. Also, for completeness, there is a mode for SSL called "anonymous Diffie-Hellman" which requires neither side authenticate, but we won't cover it since it is infrequently used.

Handshake Phase

• Step 1: There is no significant shared information state yet. The client has asked to start a new SSL session with some basic parameters. One important point here is that if the client wishes to resume a session, it must include the session ID.
  
• Step 2: There is still no significant shared state – the server responds with a chosen cipher-suite, but the client still has not authenticated the server
  
• Step 3: The server sends its certificate or certificate chain to the client. It might be tempting to think that at this point the client can authenticate the server, but this is simply not the case. The reason why is because certificates are public by design, so thinking like an attacker here means that the server could (at this point) have any X.509 certificate. The only thing that guarantees authentication in the PKI model is the existence of the private key, which the server doesn't actually prove until it sends its finished message in step 13. In other words, the client can perform certificate path validation on this certificate and achieve a valid result, but has no guarantee that the server owns the private key corresponding to this certificate. One possible (non-cryptographic) way of adding some measure of authentication here is to verify the hostname against any hostname declared in the certificate's common name, but this is a de-facto practice and not part of the actual protocol specification. It also doesn't work if the man in the middle is actively installed below layer 4 in the network infrastructure.
  
• Step 4: We will skip for our purposes here as it pertains to certificates that do not contain a usable public key
  
• Step 5: The server optionally requests the client's certificate. This message contains the acceptable certificate types and Certificate Authority Certificates (CAs), which are trusted, root certificates.
  
• Step 6: The server indicates that it is finished with its side of the handshake. Even if the client verifies the server's certificate, it still does not have any guarantee that the server is who it says it is.
  
• Step 7: Even if we assume the client has sent its certificate, from an information state point of view, the server has no guarantee yet that the client is authenticated, even by validating the certificate. The reason is the same as in step 3 or 6 for the server; the client has not yet demonstrated proof of possession of the private key that matches the certificate.
  
• Step 8: The client generates a 48-byte pre-master secret.  This value is encrypted using the server's public key and sent to the server.  The pre-master secret is a two byte client protocol version and 46 bytes of random data.  The client version helps prevent version roll-back attacks. It should be emphasized that until the server proves it can decrypt the secret there is no evidence that the server is authenticated. So even after step 8, the server has proven nothing to the client from a cryptographic standpoint.
  
• Step 9: The client finally generates proof of possession of the private key. It does this by digitally signing a hash of previous handshake messages. This further implies that in terms of the information game, in the case of two-way SSL, the server is the first to know the true identity of the client.
  
• Steps 10 and 11: The change cipher spec message is sent as a signal that we are about to begin the application data phase. Immediately following this the client sends its finished message, which contains two hashes (MD5 and SHA-1) of the master secret, handshake messages, string identifier and padding. From an information state perspective, the server is still not authenticated.
  
• Steps 11 and 12: The server is finally forced to prove that it can decrypt the encrypted secret sent in step 8. Here the server must be able to compute a signature over the secret and the client must verify that this is the case.
  

With this background, we can now insert the attacker into the flow to see how the attack works. It is easy to think of SSL as an "encrypted" channel safe from an intruder, but if there is a man in the middle actively intercepting packets from the inception of the protocol, he or she can exploit the renegotiation gap.

 The Man-in-the Middle is actively waiting between the client and server under the following preconditions:

• The MITM is waiting from the inception of the handshake phase and assumes that the SSL protocol begins with server-side only authentication
  
• The MITM waits for a client hello that he or she knows will trigger server-side authentication
  
• The MITM goes through the full handshake with the server and because the server is not authenticating the client, the server does not know it is talking to a man-in-the-middle
  
• Eventually, some trigger occurs that causes the server to ask for a client certificate. I will call this the renegotiation trigger message (RTM). This trigger can be a renegotiation of the SSL handshake, triggered by either the client or the server, for any reason. I received a blog comment regarding this point (thanks Steve) and one point made here is that the renegotiation may be triggered simply by sending a new client hello at any time. This is a critical point - the SSL specification allows for a client hello to be sent at any time and doing so will trigger negotiation. This means that the RTM can just be a client hello with no change to the cipher-suite or strenght of the SSL/TLS session
  
• The MITM is not passing through each message as they flow, but collecting and saving up the messages he or she wants
  

 
Let's look at how the man in the middle can intercept messages during the handshake. In the following table I've highlighted certain portions of the handshake important to making the attack to work.

 Handshake Phase with Man-In-The-Middle (MITM)

The MITM – Handshake Explanation

The Man-in-the-Middle (MITM) is present from the inception of the first client hello and acts in such a way as to make both the client and server believe the handshake is legitimate, while at the same time executing a chosen plaintext attack. I have highlighted the important parts of the attack in the previous table.

• Step 1: The client sends its initial client hello and all it eventually sees is a server hello in step 18. The MITM works the attack between Step 1 and Step 18, acting as if he is the client.
  
• Step 14: This is where the MITM must choose an appropriate renegotiation trigger message (RTM). This message must be a legitimate HTTP request that triggers the server side to start a new SSL session. Two ways of doing this are to choose an HTTP request that triggers either a stronger cipher-suite or a client certificate. In the example here, we assume the RTM triggers a renegotiation for a client certificate. In practice this would be done using an HTTP request to a "protected" or "higher security' URL location on the server. It should be noted that the attack can also be made to work if the client triggers a renegotiation, though this isn't shown here.
  
• Step 18: Once the server hello is passed back to the client, the attack is nearly complete. From here on out the server will look to the authenticity of the true client, with the MITM as a silent go-between. The server will retroactively allow the message in Step 14 based on the future authentication state from the true client. It is this specific behavior that results in the compromise.
  
• Steps 23-25: The client sends its valid certificate along with the encrypted master secret and proof of possession of the private key. It should be noted that the MITM cannot snoop on the communication at this point, but will have access to the encrypted response and knows at least part of the matching plaintext, which was part of the message in step 14. This is the second weakness that may result in information that allows the MITM to derive the key, but this is still quite difficult.
  
• Step 30: This is the confirmation of the content of the renegotiation trigger message (RTM) in step 14. The MITM has successfully executed a one-way HTTP transaction using the authenticity of the client. I say this is one-way because they cannot read the actual response.
  

 Another way of seeing how the attack can work is consider the behavior from the client

• Client's Perspective: The client starts an SSL session by making an HTTP request to a web server and is prompted for a client certificate. The client presents their certificate. They notice that the first HTTP response (web server communication) they get back doesn't match their initial request. They shrug it off and send the request again, this time getting a valid result. They may also be surprised to find that they are asked for a client certificate when in the past they weren't, but it doesn't matter as the client would just assume security policies have increased on the server side. The client may notice the handshake took a little longer.
  
• Server's Perspective: The server receives a request for a new SSL session from a particular client IP address. The server processes the handshake normally, authenticating itself. The client subsequently asks for a URL that is protected with a higher level of security. The server caches the HTTP request for this protected URL and renegotiates the SSL session with the client, this time asking for the client to authenticate itself. The client authenticates itself and the server sends the resulting URL location (or response) back to the client.
  

Conclusion

As you can see, there is very little to indicate a compromise on either the client or server side. The key weakness is the SSL renegotiation, which can be triggered by the client or server. Worse, renegotiation is valid at any point during the protocol communication and may be done simply for the purposes of refreshing the key. In principle the weakness can be exploited anywhere the renegotiation occurs assuming the MITM is watching for this state from the inception of the handshake. In the next blog post we will look at the current and proposed mitigation strategies for this attack.

Hello All -

I just wanted to send out a little note that I'll be at Oracle Open World next week at Moscone Center in San Francisco on October 12th, 13th and 14th.

We've got a demonstration setup that uses Oracle(R) SOA Suite 11G and Intel(R) SOA Expressway. The demo shows how you can deploy SOA Expressway as an edge security gateway to offload security processing and provide threat protection for application level attacks. We'll have SOA Expressway and Oracle SOA Suite running side-by-side on some monster laptops running on 64-bit Linux. We also plan to have a demo of Oracle Entitlements Server (OES) to demonstrate how authorization decisions can be pushed to the network edge.

You can visit the Intel software website for more information on Intel(R) SOA Expressway and Oracle's website for more information Oracle(R) SOA Suite.

It looks like everything old is new again with XML Attacks...

I came across this article in the Washington Post. They use the term "XML fuzzing" to describe really just 50% of the XML threat equation - something I have always called coercive parsing, which is the manipulation of the XML document structure.

This, however, is only half of the battle. XML threats can also be semantic meaning the attack is modifying the structure of the XML document to force a down-stream system to execute a particular function. This is the other element of XML threats that is left out of the discussion. Semantic threats cover areas where the XML document is executed in some way, such as SQL injection, embedded JavaScript, or other embedded languages like XPath.

All in all, it is a cat and mouse game where the most important feature is extensibility and the ability to deploy new yet unnamed threats in real-time using a generalized mechanism such as regular expressions. All of these features, protection from structural threats, semantics threats, and threat extensibility can be found in Intel's SOA Expressway.

I've been digging into OAuth lately, which is a protocol for delegated authentication and authorization. It seems to be useful for cases where the end user is authorizing an intermediary (called a consumer) to access a specific resource for one-time access. This means that the end user is the policy decision point, rather than a centralized PDP.

The protocol certainly looks interesting, but I've got a problem with it. My problem is that for browser interactions, the user is not given the equivalent of an SSL "lock" or other indicator that this is truly an OAuth protected interaction. This means that OAuth alone is not enough to reduce phishing attempts as described here. A rogue website can just tell the user to sign in and then claim its only accessing data one time - there is no way for the user to verify this fact. Further, we know from the days of X.509 certificates that users can't possibly understand a basic trust relation, so having them understand a three-legged protocol with a shared secret is a stretch. Worse, the presentation argues that OAuth helps reduce the password anti-pattern, but a username and password is obviously required by the user - most users won't know the difference. Once more people move to OAuth, phishing sites will just make it appear as if they are doing OAuth - it will be a zero-sum game. We need the equivalent of an "OAuth lock" in the browser for this protocol to be used for high-value transactions.

Given that users must trust the website they are interacting with in the end, the simpler approach is to have websites publish a privacy and security policy that clearly says that access to service provider websites will be done with user credentials, but that the credentials will only be used once and not saved. Doesn't this achieve the same result with less code to write and less complexity? Is it more prudent for me to trust the website I am at or trust that the website has successfully implemented a complex, multi-hop security protocol?

JavaOne is this week at Moscone center in San Francisco and I've been putting together a live demo of Intel(R) SOA Expressway. The plan is to show some perimeter defense, delegated authentication and message throttling functions. The scenario has three threads running, good requests, bad requests (auth faults) and bad requests (XML attacks). This set up is perfect for getting all of the pretty colors to show on the Intel(R) SOA Expressway dashboard!

I've got SOA Expressway running on an old IBM t43p (single core) laptop on 32-bit Red Hat AS4. This is really for convenience since the laptop is small and easy to lug around. What's interesting is that even on this ancient machine Intel(R) SOA Expressway is extremely reliable - I had it going all weekend and it converged to about 8000 messages per hour, which actually limited by the client I'm using, which is SOAP UI.

If anyone is around this week, please come by come check out the demo.

Blake

My mantra for the day is simply this: Paradigms are seldom total.

Instead, the real world makes things complex, and this is a boon to the service oriented view of the world, whether it is under the moniker of "SOA" or "services."

The cloud craze, aside from infecting every blog out there is really a new requirement for service mediation between on-premise Enterprise applications and off-premise services. Will the cloud paradigm become total? Maybe for the consumer, but I think we have a long way to go for the Enterprise.

With its combination of security functions, virtualization support and mediation capabilities, Intel(R) SOA Expressway is in the right place a the right time to take advantage of hybrid cloud architectures.

A colleague forwarded me this link which highlights what appears to be a severe memory limitation with the IBM DataPower XI50. It appears that the device is having trouble applying an XML digital signature to a 100MB XML file.

This brings back the issue of using knowledge of the complexities involved in XML digital signatures to execute a Denial of Service (DoS) attack. Using this information an attacker could search for a DataPower device currently performing XML signatures on much smaller documents and take down the box with a single large document. I guess you might say this post highlights not one, but two problems with IBM DataPower: (a) The fact that it can't handle digital signatures on large XML, and (b) The fact that this fact results in a potential DoS vulernability.

I was recently on a business trip last week and somehow I picked up a copy of "USA Today." This newspaper tends to find me rather than the other way around. Normally I try to avoid it, but am always drawn to it even if its just to see what the average American is supposed to care about.

I was looking through the business section and I was shocked to see a story on the front page on SQL Injection attacks!

I was surprised for a number of reasons. First off, SQL injection, or the attempt to insert SQL queries to return database information or spoof a login, is a very specific type of attack, but the USA Today story makes it seem like the average user should be "worried" about this type of attack, which is a little funny. It also claims that SQL injection turns your computer into a bot I think that attacks like cross-site request forgery or cross-site scripting have a much higher impact on the average Joe. XSS and CSRF can affect casual browsing if a user simply browses the wrong section of a website (such as the 'forums') where someone has managed to inject a <script&rt; tag.

Upon careful dissection, this article seems instead to be a sort of advertising placement for IBM:

"For the first five months of 2008 IBM ISS helped large corporations block about 5,000 SQL attacks a day. By mid-June, daily attacks spiked to 25,000;"

This is a bit ironic compared to the news that came out earlier in the year regarding the DoS attack against IBM DataPower or the problems the device has with persistent connections. I sure hope IBM ISS isn't recommending the DataPower device as an application firewall to protect against SQL injection!

As for content threats themselves, this is a very interesting area that I am sure will experience more growth in both the types of threats devised as well as the protection mechanisms. What is needed is a high-performance content processor that can at a minimum scan for different types of attacks within the application payload but also must be extensible as attacks are always changing and evolving.

What worries me the most here are cases of an attack that rely on an application firewall to keep state between HTTP requests. That is, rather than the attack being defined as a single SQL injection, or script injection it may be defined across a set of messages. In other words, the attack can't be detected by looking at a single message, but by a pattern of messages.

A hot issue in the context of SOA is how does one effectively mediate between services that may reside in different domains across an organization, and further, how does one accomplish data sharing amongst services without breaking the bank.

Traditionally, organizations have deployed hardware appliances to solve this problem, but Intel has a new solution called SOA Expressway, which is essentially an optimized software runtime that accomplishes the same mediation as a hardware appliance but with higher performance that is more closely aligned with cost-reduction trends in the datacenter such as virtualization and liquid computing.

Recently I gave a joint webinar with Burton on the software service mediation solution. Most surprising is how much faster the software is compared to a purpose-built XML appliance. In fact, the testing shows that for real-world (non-synthetic tests) scenarios, software on Intel(R) Multi-Core is at least 2 and at most 8 times faster than the ASIC for XML processing - quite suprising, oh and its cheaper too.

Sys-Con has just put up a link to Joshua Painter's presentation on Enterprise SOA and governance that was given at SOA World 2008.

The video is interesting in that it highlights Intel's SOA Expressway product in terms of the Enterprise Service Router concept, which tries to consolidate islands of integration with scalable software rather than a plethora of non-interoperable ESBs and custom built hardware appliances. The software scales on Intel Multi-Core such as the new i7 platform and uses standard servers rather than custom chips for XML message acceleration.

A friend of mine forwarded me this DoS attack against the IBM DataPower XS40 SOA Security Appliance using only the standard OpenSSL command line client. Apparently you can cause the box to reboot by sending a random string over an SSL-enabled socket connection.

I got in touch with a friend with access to an IBM DataPower XI50 and they were unable to reproduce the issue on the integration device, but that doesn't mean similar issues like this one aren't going to crop up, especially in a closed-off hardended device like this. I also wonder if this attack was an accident or if it was the result of a concentrated security analysis on the device itself.

I think this is where it makes sense to reexamine closed-off products in light of well known design principles like security through obscurity and ask if it makes sense to protect enterprise and SaaS applications with this type of device as contrasted with a software solution that runs on an open-source with a known risk profile.

It looks like a new binding for SAML v2.0 is soon to be ratified, the HTTP POST "SimpleSign" Binding . The "SimpleSign" binding was originally crafted by Jeff Hodges and Scott Cantor relaxes the XML Signature requirements on the SAML Protocol, making it easier for scripting environments to send signed SAML requests and verify signed SAML responses. The main problem with XML Signature is performance - very few people know that the cryptography involved in XML Signature is often dwarfed many times over by the extensive XML processing requirements including parsing, transformation and XML canonicalization (e.g. c14n).

The situation only gets worse as the size of the XML document increases or the number of references to be signed increases. This profile takes a less sophisticated approach and interprets the XML content of the SAML request or response as an octet stream and then represents the signature as a base-64 encoded blob. While I think that this type of profile will do wonders to help scripting environments support signed SAML requests, this specification does not replace the signature on the actual SAML assertion - it just applies to the and messages.

This means that for persistent message level security on SAML assertions, XML Signature is still required. Other solutions to this problem are to decouple the XML signature processing from the scripting environment and moves it to the network with a SOA software appliance. This approach uses the original XML Signature as specified in the original spec (you will likely have to use it anyway if you want signed SAML assertions) and avoids having to implement and test a new profile.