The OWASP Foundation

indexadjustmentInternet et le développement Web

13 nov. 2013 (il y a 4 années et 7 mois)

104 vue(s)

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

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



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:


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.



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?




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).





OWASP

7

Advanced Testing Techniques


Sniffing, Editing and Re
-
transmitting
requests (Replay)


Memory Debugging and Messaging


De
-
complication and Recompilation
of code




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.



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.




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).



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.



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.




OWASP

13

DJ Java De
-
compiler In Action

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.


OWASP

15

Run
-
time Protocol
Analysis

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.




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.

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.


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.


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.




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.




OWASP

22

Sniffed Serialized Objects (Http)

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.




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.


OWASP

25

Sniffed Request (Http)

OWASP

26

Manipulating the Request Destination

OWASP

27

Basic Protocol Analysis Code

OWASP

28

Analyze Structure via Casting Errors

OWASP

29

Manipulate and Send to the Original Server

OWASP

30

Live Demo

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.




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.




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:





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.






OWASP

35

Questions?

Thank You!

For additional information:

Email:
shay@hacktics.com

Web:
www.hacktics.com