1. Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP http://www.owasp.org Achilles’ Heel – Hacking Through Java Protocols Shay Chen Hacktics L.T.D shay@hacktics.com 0546-680680 14/09/08

2. OWASP 2 Agenda  Introduction to penetration tests  Advantages & disadvantages of modern client server penetration testing techniques.  Runtime protocol analysis (RPA) – a new testing technique!  Live Demo

3. OWASP 3 Introduction to Penetration Tests  Performing Penetration tests requires the tester to be able to manipulate the client’s originating communication, either by constructing independent requests or by altering the structure or values of an existing request.  When the tested application is a web application, such manipulations can be performed in numerous ways, including:

4. OWASP 4 Testing Web Applications  Intercepting Proxies (Achilles, Web- scarab, Paros, Burp Suite...)  Manual request construction (generating independent forms or access URLs according to the information in the HTML)  Browser Add-Ons (Http View, Temper data, Hack-bar...)  Etc.

5. OWASP 5 Testing Client Server Applications  However, tests on thick browser-add-on clients (applets, activeX, flash) and client- server applications are a bit more complicated:  The protocols aren’t always easy to understand and manipulate as clear http.  The client applications does not always support proxy configuration, making request interception very difficult.  In the case of binary protocols, most proxies do not support manipulation of binary values.  So, what should the tester do, in the day the proxy fails?

6. OWASP 6 When will the proxy fail to work?  Applications without proxy support that use protocols that contain binary values.  Applications that use compacted protocols (zipped).

7. OWASP 7 Advanced Testing Techniques  Sniffing, Editing and Re-transmitting requests (Replay)  Memory Debugging and Messaging  De-complication and Recompilation of code

8. OWASP 8 Sniffing, Editing and Re-transmitting  The communication can be “sniffed” using tools such as Wireshark (formally ethereal), allowing the tester to isolate requests.  Requests can be isolated and edited by saving sniffed communication into files as RAW DATA and using an appropriate editor (text editor for clear text protocols, hexa- editor for binary protocols).  Edited requests can be re-sent independently to the server using tools such as Netcat.

9. OWASP 9 Sniffing, Editing and Resending  Advantages:  Enables manipulation of values in textual requests.  Enables limited manipulation of textual values in binary requests.  Enables performing various flow bypassing checks.  Disadvantages:  Does not enable the tester to understand the complete structure of binary protocols.  Does not allow “easy” manipulation of non textual values.  The textual manipulation is usually limited to the size of the original string (depends on the language).  Challenge response and signature mechanisms may pose a problem.

10. OWASP 10 Memory Debugging and Messaging  Memory debuggers (such as OllyDbg) can be used to change values directly in memory.  Windows Messaging Features can be used to alter the values and properties of windows applications (for example, windows enabler).

11. OWASP 11 Memory Debugging and Messaging  Advantages:  Allows the tester to manipulate all the relevant values in the tested client application directly in the memory.  Disadvantages:  The time required to perform such tests is relatively long.  The structure of Java and other virtual environment based technologies makes the process even harder, due to non- standard memory structure and lack of proper support in messaging.

12. OWASP 12 De-compilation and Recompilation  Extremely effective in development technologies that compile to a mid level code, instead of compiling directly to machine code, such as Java and.Net.  Since java applications are not compiled to machine code directly, and are compiled to a middleware interpretation instead (byte-code), it is possible to decompile them to a source code that is almost identical to the original source.  The fact that in java, each class is compiled to a separate class file, allows the tester to re-compile only the classes that he wishes to manipulate, instead of re-compiling the entire application.  The re-complied classes can replace the original ones in the application JAR file.

13. OWASP 13 DJ Java De-compiler In Action

14. OWASP 14 De-compilation and Recompilation  Advantages:  Allows the tester to gain full control over the values and requests sent from the client to the server.  Allows the tester to bypass challenge response, traffic encryption and signature mechanisms.  Disadvantages:  Obfuscated code can make the process extremely difficult.  Detecting the key classes may take time in complex and large client applications.

15. OWASP 15 Run-time Protocol Analysis

16. OWASP 16 Run-time Protocol Analysis  The tester can combine several methods in order to perform an efficient penetration test on java based thick clients and client server application, by sniffing requests, analyzing & re-transmitting them using a custom protocol analyzer. This method will work without resulting in any manipulation limitations, even if there is no proxy support and the protocol is binary.

17. OWASP 17 Run-time Protocol Analysis  Advantages:  A method that is much faster & cost affective when compared to other test methods, such as de-compilation and memory debugging (several minutes per request).  Enables the tester to perform unrestricted manipulations on any java serialized protocol, including binary protocols, encrypted protocols and compacted protocols (gzip).  Enables detailed logical analysis, reveals the logical structure of each request and may allow access to secret in-code features.  Disadvantages:  Requires basic programming skills, since it involves in-code manipulations.

18. OWASP 18 The Scope of RPA Tests  RPA can be used in java based protocols in any of the following test cases:  In the case of transmissions that contain serialized objects (binary data), sent over HTTP from an applet (java browser plug-in) or a thin client application to a J2EE application server. The analyzer should be implemented as a JSP page or a servlet in a local application server.  In the case of transmissions that contain serialized objects that are used within a proprietary TCP/UDP protocol. The analyzer should be implemented as a TCP/UDP server socket that attempts to extract objects from streams it receives.  In the case of compacted protocols (gzip), which are sent through HTTP or through a proprietary protocol. The server should be implemented in a similar technology, including extraction code.

19. OWASP 19 The Scope of RPA Tests, Cont.  Advanced usage of RPA can be performed in the following test cases:  In the case of transmissions that are sent through encrypted protocols (such as SSL), RPA can only be used if the tester can gain the decryption key, has control over a local DNS configuration interface, and has the ability to customize various code fragments in the listener code (custom listener).  In the case of transmissions that contain inconsistent types of data (not only classes but custom bytes as well), the protocol analyzer can attempt to extract classes from each byte, and skip bytes in the case of exceptions.  The protocol analyzer can be used alongside de- compilation & reflection in order to bypass class- level security restrictions that may prevent the tester from altering private/protected fields.

20. OWASP 20 How Does It Work?  Java serialized objects are transmitted alongside most of their properties, including class names, structure, variable values, object hierarchy and so on.  In order to analyze a sniffed transmission, we will simply retransmit it to the analyzer, and extract the serialized objects from the stream, one by one.

21. OWASP 21 How Does It Work? (Cont.)  The protocol analyzer can rely on exceptions that will result from improper casting & analysis of the java serialization structure; the structure of the request will be analyzed based on casting exceptions!  After the request is analyzed, the object values can be altered in the analyzer code, and then retransmitted to the original destination.

22. OWASP 22 Sniffed Serialized Objects (Http)

23. OWASP 23 Creating A Protocol Analyzer  Implement a server application that will analyze requests (interactively) that are sent to it.  The server application should be written in the same technology as the original server application (e.g sockets for proprietary protocols, servlets or jsp pages for HTTP/GZip over HTTP communication, etc).  Sniff legitimate requests, and send them to the protocol analyzer for detailed analysis, value manipulation and re-transmission to the original destination.

24. OWASP 24 Run-time Protocol Analysis Steps  Step by Step Java Protocol Analysis:  “Sniff” a valid request and save the raw data to file.  In the case of HTTP wrapped requests, Edit the destination of the request using an hexa editor, and replace it with the URL of the protocol analyzer.  Include the tested application client side code (jar/ class) in the analyzer class-path.  Resend the “sniffed” request to the local analysis jsp/servlet/socket.  Use casting exceptions to analyze the protocol structure.  Insert manipulation code into the analyzer.  Resend the manipulated request from the analyzer to the original destination.

25. OWASP 25 Sniffed Request (Http)

26. OWASP 26 Manipulating the Request Destination

27. OWASP 27 Basic Protocol Analysis Code

28. OWASP 28 Analyze Structure via Casting Errors

29. OWASP 29 Manipulate and Send to the Original Server

30. OWASP 30 Live Demo

31. OWASP 31 The Account Viewer Demo Application  A sample application that allows users to view their account information.  A Thick client that is implemented as a java applet – java code that is dynamically downloaded and executed in the client side through a browser, which uses the embedded applet as an independent and separate part of the HTML page, that runs in the context of the JVM.  Since the applet does not support a proxy, and sends binary classes over HTTP, we cannot use simple pen-testing methods, and thus, we will use a custom analyzer instead.

32. OWASP 32 The Protocol Analyzer Demo  The current sample protocol analyzer resides on tomcat, and is written as a JSP file.  Attempts to “cast” objects from request streams sent to it into a general Object, in order to intentionally cause casting exception that will reveal the name of the actual objects transmitted.  Casting exceptions will be presented on tomcat’s console, allowing the tester to alter the analyzer code to handle additional objects and manipulate their content.

33. OWASP 33 The Phases of the Test  access the application  download the client side application jar/s, and place them in the analyzer class-path ([path]/WEB-INF/lib/).  sniff a valid request, Follow the TCP stream and save the request data as RAW data.  edit the request with a hexa editor, isolate one request by deleting the others and change the destination URL to that of the analyzer (currently found in: /StreamAnalyzer/StreamAnalyzer.jsp)  Run the test server & base analyzer  transmit the request using Netcat  analyze the request:

34. OWASP 34 Detailed Request analysis  watch the analyzer console for exceptions.  import any needed packages from the tested client application code to the analyzer (the java import command).  alter the analyzer code to retrieve additional classes from the request and repeat the previous processes.  manipulate the values in the classes retrieved.  resend the manipulated information from the analyzer, back to the original destination.

35. OWASP 35 Questions? Thank You! For additional information: Email: shay@hacktics.com Web: www.hacktics.com