Re: java app question

Well as said above by Rogan and Luca, you can try the technique I
recently presented at Black Hat Europe.
Below is the presentation I uploaded on Slideshare, it also contains a
video demonstration of how it works :
http://www.slideshare.net/msaindane/black-hat-eu-2010-attacking-java-serialized-communication

The Burp plug-in template can be found here:
http://www.andlabs.org/tools.html#dser

Also if you are facing problems on passing the data to the
interception proxy; you can use the Sniff-n-split tool
http://www.andlabs.org/tools.html#sns

Let me know if this works for you :)

Rogan: I'm in fact looking forward to the OWASP Proxy project as it
provides a proxy API. So people can use the same technique by
utilizing this proxy from within their code.

Cheers,
Manish S. Saindane
Attack & Defense Labs
manish (-at-) andlabs.org

On Fri, Apr 23, 2010 at 9:45 PM, Rogan Dawes <[email protected]> wrote:
> 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
> --------------------------------------
>
>



-- 
¨˜”°º•C0D3w@lk3r•º°”˜¨

------------------------------------------------------------------------
This list is sponsored by: Information Assurance Certification Review Board

Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT and CEPT certs require a full practical examination in order to become certified. 

http://www.iacertification.org
------------------------------------------------------------------------