ppt
DESCRIPTION
TRANSCRIPT
Copyright © The OWASP FoundationPermission 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 ChenHacktics [email protected]
14/09/08
2OWASP
Agenda
Introduction to penetration testsAdvantages & disadvantages of
modern client server penetration testing techniques.
Runtime protocol analysis (RPA) – a new testing technique!
Live Demo
3OWASP
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:
4OWASP
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.
5OWASP
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?
6OWASP
When will the proxy fail to work?
Applications without proxy support that use protocols that contain binary values.
Applications that use compacted protocols (zipped).
7OWASP
Advanced Testing Techniques
Sniffing, Editing and Re-transmitting requests (Replay)
Memory Debugging and Messaging
De-complication and Recompilation of code
8OWASP
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.
9OWASP
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.
10OWASP
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).
11OWASP
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.
12OWASP
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.
13OWASP
DJ Java De-compiler In Action
14OWASP
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.
15OWASP
Run-time Protocol Analysis
16OWASP
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.
17OWASP
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.
18OWASP
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.
19OWASP
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.
20OWASP
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.
21OWASP
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.
22OWASP
Sniffed Serialized Objects (Http)
23OWASP
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.
24OWASP
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.
25OWASP
Sniffed Request (Http)
26OWASP
Manipulating the Request Destination
27OWASP
Basic Protocol Analysis Code
28OWASP
Analyze Structure via Casting Errors
29OWASP
Manipulate and Send to the Original Server
30OWASP
Live Demo
31OWASP
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.
32OWASP
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.
33OWASP
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:
34OWASP
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.
