Sunday, November 27, 2011

A handshake_failure on ClientHello and TLS vulnerability

Recently, while integrating web services between two servers, we had a situation with TLS handshake when our server acted as client. In order to establish a TLS session with a server, the client would first send ClientHello message. The server immediately terminated the handshake with the alert handshake_failure. The solution involved a bit of guesswork on our side since there was no support on the server side who could debug on their side and provide some feedback. Following log snippet shows the situation (line #32) with debug enabled (on Tomcat/JBoss).
Studying the debug, we realized that perhaps the cipher suites used (line #21) to start the handshake were not negotiated by the server. In TLS, the handshake_failure alert is only used when no common cipher can be negotiated [5]. The developers of the server sent us a web service client project in SOAPUI to prove that their web services are up and running and could be tested remotely using SOAPUI using transport level security. Enabling the SSL debug in SOAPUI, we found that the cipher suite used was indeed different and was also a superset of the cipher suite our HTTPS client used to start the negotiation. Indeed, cipher suite sent for negotiation is composed with lowest common denominator in mind with with 40 bit encryption as shown below with assumption that negotiation would bring agreement between the client and the server.
However, if the server terminates the handshake with alert handshake_failure, the server might perhaps be looking for different ciphers, compression algorithm or version since this happens in response to ClientHello. There could be a reason for such behavior. Doing a bit of digging, we found that a couple of years back a vulnerability was found in the TLS protocol that could be exploited during the renegotiation phase. When this vulnerability was detected, as a first line of defense, it was suggested to turn off the renegotiation and a solution [4] was proposed to fix the problem in the protocol. Our server used a version of Java with the fix which is listed on JSSE Reference Guide.

Our suspicion was that perhaps the other server was not set up for renegotiation. So, we changed our HTTPS client code to use the cipher suite that incorporated much larger suite as follows.
This cipher suite was accepted by the server. In fact, it was SSL_RSA_WITH_RC4_128_MD5 that was picked up by the server.
  1. JSSE Reference Guide 
  2. Authentication Gap in TLS negotiation
  3. Understanding the TLS Renegotiation Attack
  4. RFC 5746 - TLS Renegotiation Extension 
  5. SSL and TLS Designing and Building Secure Systems, Eric Rescorla

Tuesday, November 22, 2011

Bypassing security on web application by using unlisted HTTP method

Typically web environments allow to configure authentication and access control over a web resource for a list of HTTP methods. For example, a Java Servlet descriptor (web.xml) for a J2EE web application allows to configure security constraints as following : Here, the web application developer would expect that HTTP GET and POST methods invoked on any web resource (/*) of the application would be subject to authentication constraints as defined and it is also expected that the rest of the HTTP methods would not be allowed to be accessed. In other words, any GET or POST requests without proper authentication to the JBossAdmin realm would be blocked and would get a 401 error.

Vulnerability 

The HTTP protocol also supports other methods such as HEAD, PUT, DELETE, etc. Here is the catch. As these methods are not listed in the security constraint shown in above example, the HTTP requests with these methods are still allowed to pass through (by vulnerable web environments) without any authentication or authorization(!). Such requests are typically handled by the default GET handler if no method specific handler is specified. Exactly this vulnerability is exploited by a worm in order to launch a denial of service (DoS) attack. It also seems to have affinity to JBoss's jmx-console :(. It uses HTTP HEAD method on jmx-console to plant seeds of one or more DoS attacks on the infected environment as well as out on the net.


What is (known) to be affected?

According to RedHat/JBoss advisory CVE-2010-0738, this vulnerability is applicable to the following JBoss software.

  • JBoss Application Server (AS) 4.0.x, 5.1.x
  • JBoss Communications Platform 1.2
  • JBoss Enterprise Application Platform (EAP) 4.2, 4.3, 5.0
  • JBoss Enterprise Portal Platform (EPP) 4.3
  • JBoss Enterprise Web Platform (EWP) 5.0
  • JBoss SOA-Platform (SOA-P) 4.2, 4.3, 5.0

The advisory says that the default setup of the out of the box web applications such as jmx-console, web-console, etc. of JBoss products listed above enforces incomplete security constraints to ensure authenticated access to the administration user id, defined within these products. A remote attacker, without having access to usernames and passwords, could misuse this setting to trigger arbitrary actions in the context of the operating system user running the Java process and potentially harm confidentiality integrity and availability.
According to Bypassing Web Authentication and Authorization with HTTP Verb Tampering from Aspect Security, this vulnerability might exist in the following since these are known to silently transfer all HTTP HEAD requests to GET handler.
  • IIS 6.0
  • WebSphere 6.1
  • WebLogic 8.2
  • JBoss 4.2.2
  • Tomcat 6.0
  • Apache 2.2.8

Solution

The best solution for any Java web applications is to either remove all __ from the __ and thus trigger security constraints on all HTTP methods or to list all HTTP methods in the security-constraint as shown in the following example.
Better or