Download ppt - owasp

Achilles’ Heel – Hacking
Through Java Protocols
OWASP
Shay Chen
Hacktics L.T.D
[email protected]
0546-680680
14/09/08
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
http://www.owasp.org
Agenda
Introduction to penetration tests
Advantages & disadvantages of modern
client server penetration testing
techniques.
Runtime protocol analysis (RPA) – a new
testing technique!
Live Demo
OWASP
2
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:
OWASP
3
Testing Web Applications
 Intercepting Proxies (Achilles, Webscarab, 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.
OWASP
4
Testing Client Server Applications

However, tests on thick browser-add-on
clients (applets, activeX, flash) and clientserver 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?
OWASP
5
When will the proxy fail to work?
 Applications without proxy support
that use protocols that contain binary
values.
 Applications that use compacted
protocols (zipped).
OWASP
6
Advanced Testing Techniques
 Sniffing, Editing and Re-transmitting
requests (Replay)
 Memory Debugging and Messaging
 De-complication and Recompilation
of code
OWASP
7
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, hexaeditor for binary protocols).
 Edited requests can be re-sent
independently to the server using tools
such as Netcat.

OWASP
8
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.
OWASP
9
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).
OWASP
10
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 nonstandard memory structure and lack of
proper support in messaging.
OWASP
11
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.
OWASP
12
DJ Java De-compiler In Action
OWASP
13
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.
OWASP
14
Run-time Protocol
Analysis
OWASP
15
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.
OWASP
16
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.
OWASP
17
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.
OWASP
18
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 decompilation & reflection in order to bypass classlevel security restrictions that may prevent the
tester from altering private/protected fields.
OWASP
19
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.
OWASP
20
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
OWASP
destination.
21
Sniffed Serialized Objects (Http)
OWASP
22
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.

OWASP
23
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.
OWASP
24
Sniffed Request (Http)
OWASP
25
Manipulating the Request Destination
OWASP
26
Basic Protocol Analysis Code
OWASP
27
Analyze Structure via Casting Errors
OWASP
28
Manipulate and Send to the Original Server
OWASP
29
Live Demo
OWASP
30
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.
OWASP
31
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.

OWASP
32
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:


OWASP
33
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.


OWASP
34
Questions?
Thank You!
For additional information:
Email: [email protected]
Web: www.hacktics.com
OWASP
35