Tuesday, September 7, 2010

Re-visiting JAVA De-serialization: It can't get any simpler than this !!


Well it's been a while since I have blogged. Been quite busy with work lately. Also I guess Lava is better at blogging stuff so I'll leave that to him :)

After my talk at BH EU earlier this year, there has been quite a lot of other really cool stuff been published on penetration testing of JAVA Thick/Smart clients. Check out Javasnoop especially. It has some pretty good features you would like to use. Many people that I spoke to recently said to me that modifying objects programatically using the IRB shell in DSer would be difficult and it would require the penetration tester to have indepth knowledge of the application's source code. Well; in the first place, penetration testing is a skill and it does require hard work, so understanding the application's internals is part and parcel of the job. But that being said DSer allows you to play around with JAVA objects using an interactive shell with some helper methods and is completely extensible. It was meant to be a template, to add your own stuff and extend it's capabilities.

In this post I will show you a technique which will alow us to extend DSer and simplify the processing of modifying JAVA Objects. Before we start I would like to thank my colleague Chilik Tamir for introducing me to the XStream library and helping with this idea. XStream is a library to serialize JAVA objects to XML and back. Now getting back to the topic. Let's assume that we have a complex object that we encounter in our request or response packet as follows:

HashMap = { key1 = String[], key2 = HashMap }

I have chosen internally available JAVA objects for simplicity, but they can be any custom objects you like. Now modifying this in via HEX bytes would be a difficult task as we will see later. For demostration purposes, i'll make use of the following app:
Fig. 1: Demo app to generate complex JAVA objects
This application will use the inputs we supply in the 3 text fields and create a HashMap similar to the one showed above when the "Both" button is pressed and send it to the backend server for processing. Once we capture this request in Burp, it would give an output similar to this:
Fig. 2: Request showing raw serialized data captured in Burp
Which will be de-serialized and rendered in the DSer shell as follows:

{ keyTwo = [Ljava.lang.String;@70ac2b, 
  keyOne = { hmKey1=Manish,
             hmKey3=Andlabs,
             hmKey2=Saindane
           }
}

We can see that the HashMap has 2 keys (ie. keyOne and keyTwo) with values as a String Array and a HashMap. Now I have added a few custom functions to DSer that will make use of the XStream library and convert the above mentioned JAVA serialized object to XML, save it as a temp file and open it in any XML editor of your choice for further editing. The resulting XML will look as follows:
Fig. 3: XML generated from the JAVA serialized object
Notice how nicely XStream has rendered the XML from the given JAVA object. We can clearly see the <string-array> and the <map> elements (highlighted above) with the individual entries. We can edit the entries and modify it as we want. Let's modify the XML as follows:
Fig. 4: XML after modification
We have removed the "Andlabs" entry from the String Array and added two extra entries (ie. "Lavakumar" and "Kuppan"). Also the "hmKey3" entry has been removed from the inner HashMap (highlighted above). Now as soon as we save this XML and close the editor, the code in DSer will convert this XML back to a JAVA object which will look similar to this:


{ keyTwo = [Ljava.lang.String;@9568c, 
  keyOne = { hmKey1=Manish,,
             hmKey2=Saindane
           }
}

The custom functions will then take care of serializing this object, editing the "Content-Length" header and preparing a new "message" to be sent to the application server. You can observe the modified data in Burp from the history tab.

Fig. 5: Edited request as shown in the Burp
So using this technique, modification of the JAVA objects becomes trivial and anyone with no prior knowledge of programming can edit the objects (as long as he/she knows  how to edit text or XML ;)). The screenshot shows the modified data being successfully passed to the server and rendered back to the output.
Fig 6: Modified data processed by the application
DSer is not just restricted to JAVA serialized objects, but (almost) any binary protocol that you can think of. So do not restrict your thinking and be creative. In this post I just showed you how you can extend DSer's capabilities and simplify the process of editing JAVA objects. You can do the same with any other protocol. All you need is some basic understanding of how the protocol works.

I'll add the the above mentioned custom methods to DSer and release it soon. Just need to clean up the code and make a few changes here and there. If anyone need's to try it out in the mean time, just ping me and I'll give you the source code. So until next time, Happy hacking !!

13 comments:

  1. Great! Now it is finally simple enough for me to use it :D
    Love the XML representation of Objects,
    makes it really easy to understand the app.

    ReplyDelete
  2. HI,

    Thanks for the post.

    As you point out, your examples are based on java classes present directly in the JDK, i.e. present both on the "victim" side and on the pen tester side.

    I do not know about DSer, but XStream at least is not going to be able to marshall from Java to XML without the ".class" defining the objects sent on the wire, i.e. without the class structure definition.

    Nowever it should be possible to setup a tool that can infer a viable class definition from the object instance (but that is probably hard - and interresting :-> - work, though).

    The pen tester would also need to make sure to use the same JVM version.

    Cheers

    ReplyDelete
  3. Hi Svend,

    Glad you liked the post.

    As far as marshalling / un-marshalling is concerned, you are right, we would require the '.class' files defining the objects. Whenever you test any thick client or applets, the class files for that do exist on your machine.

    The pentester needs to copy all the client jars in DSer's lib folder.

    Please check this video for a short demonstration of DSer: http://andlabs.org/videos.html#attack_js

    ReplyDelete
  4. Check it out Chilk tamir bleach: http://invalid-packet.blogspot.com/
    Its easier and simpler than DSer.

    ReplyDelete
  5. @Anonymous: Chilik is my colleague :) I think you did not read thorough this post completely. I have credited him for helping me out :D

    Also his Burp plugin is named Belch. And definitely try it out, it is good.

    ReplyDelete
  6. Hi,

    I am encountering a problem where the serialized Java Object is a custom object. The tool obviously cannot deserialize it since the custom class file/object structure is not in memory.

    So if i am assessing a Java Applet, and it passes serialized custom Java Object, I can download the Applet, but is there a way I can load it with the DSer tool so the DSer tool can deserialize those custom Java object?

    Thanks,
    Johnny

    ReplyDelete
  7. Hi Johnny,
    By default DSer will load any jar file from the lib folder provided with the tool. You can either load the downloaded app by placing creating a jar with the applet classes within it and placing it in the lib folder or check this link for loading class files http://goo.gl/upJnW

    Anyway if you look at the source code, the first few lines will tell you how to load the custom classes. Hope that helps.

    ReplyDelete
  8. Hi Manish,

    Thanks for your response. I can successfully edit custom java objects now. In addition, I implemented your idea of using xstream to edit serialized java object through a jtextarea each time a java object interception occurs. It sure makes life easier and served me well for my gig.

    Do you plan to release your implementation of the xstream and GUI code? If you don't have time, I can give you my copy and you can check it out or distribute it. I am sure other folks would prefer GUI editing than through the IRB shell.

    Thanks for making and sharing DSer.

    Johnny

    ReplyDelete
  9. Hi Johnny,

    Glad that worked. Yeah I have been lazy not to upload the new version with the XML editing in a GUI. Feel free to distribute your version and add functionalities that would help enhance or simplify this. I'll surely upload my version. My version of the code allows the user to edit the XML with any XML editor of his/her choice. I initially used the jtextarea but ran into some issues (probably some threading issues) so I gave up on that and used an external editor instead.

    ReplyDelete
    Replies
    1. Can't wait for the updated version and thank you very much for all your work!

      Delete
  10. Any news about this XMLified version of DSer? I have run across a situation where the custom Java objects are very complex and any GUI help would be good.

    ReplyDelete
    Replies
    1. You can download a copy here: http://blogs.fishsec.com/wp-content/uploads/2012/05/DSer.zip

      Delete
  11. Hi

    Can't seem to find the updated versions as mentioned above - does anyone have a current link?

    Thanks

    Graham

    ReplyDelete