Re: java app question

[Rogan Dawes <lists () dawes za net>]

On 2010/04/23 5:56 AM, learn lids wrote:
> hi all,
>
> i am looking to pen test an app which is not a webapp :) . on
> browsing to the url it launches a java application using jnlp.
>
> i used a network traffic sniffer to see the traffic, and it is making
> post requests to several different urls (e.g.
> webapp.com/generatereport etc.), and the response is of type
> x-serialize object.
>
> any suggestions on what could be things to look at for such a
> pentest?
>
> thanks

Here is a list I made up a while ago:

=====snip======

Reviewing a thick client for security problems

secure comms

- SSL & hostname verification

Authentication & Session management

- handle credentials safely

- handle sessions safely

- handle account management functions safely - change password, etc

Access Control

- Check whether client side access control (presentation layer) is being
performed

Validation (request/Response)

- Check that user data is validated before being sent to the server (not
necessarily critical if it is not, IF the server IS validating input).
However, it makes it possible for the server to say with certainty that
any bogus data that reaches the server is definitely an attack.

- Check that data returned from the server is validated before being
presented to the user. Keep in mind that data provided by another user
may end up being used in local DB calls, or cmd injection calls

Data Protection

- Check for client side caching of results, also logging of sensitive
information in local log files, etc

Error Handling

- Do we care if exceptions are shown to the user in detail? Not really,
they could still see that they were occuring with a debugger if they
wanted to.

Intrusion Detection

- Can we rely on a client to do intrusion detection?
- Does a client even have to do logging?

Encryption

- what sensitive data are we handling that we need to encrypt?

Availability

- what long running server-side jobs can we kick off from the client?

- can the client be used to execute a DOS against the server?

Concurrency

- relevant on the client side? Not really.

General

Make sure that running the client is not exposing the user to attack.
i.e. no local services, any local DB is not listening to the network,
etc. Check the standard Runtime.exec calls, etc

=====snip====

There are a couple of approaches you can take. Either inject a BeanShell
into the app, and use it to manipulate the requests before they are
made, or find a proxy that can deserialise the objects and allow you to
modify them in transit.

The first option is probably the best one, as you get much better
control over what is sent, and when, and don't have to worry (as much)
about client-side timeouts while you are looking at the object that was
sent.

The second option is still feasible, however. I believe there was a
recent presentation on doing this exact thing with Burp Suite.

WebScarab or OWASP Proxy should also allow you to achieve the same
thing, with varying levels of programming required. Using WebScarab, I
would make use of the BeanShell to deserialise the object, then pass it
to the Java Object Inspector (JOI) to view and modify.

Using OWASP Proxy would give you the most flexibility, but would also
require the most coding. Again, I'd use JOI to view and modify the
object once it had been deserialised. When you are ready to send it on
to the server (or back to the client), reserialise the object, and
package it up in the HTTP message as you found it.

Hope this helps.

Rogan
P.S. Since you can see the traffic with a sniffer, it is obviously not
SSL, which makes your life easier, but should be your first finding :-)



This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now! 
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------