[Fwd: Re: Getting around mutual Certificate authentication using safenet 2032 tokens enforced in a webapp]

[Liaw Man Cheon]

re-sent

-------- Original Message --------
Subject: Re: Getting around mutual Certificate authentication using
safenet 2032 tokens enforced in a webapp
Date: Tue, 20 Oct 2009 15:45:09 +0800
From: Chris <"chrisliaw at gmail dot com">
To: Matthew Zimmerman <mzimmerman@...>
CC: pen-test <pen-test@...>
References:
<da4938c20811190435o46b19d1dp86f663fb30e20f19@...>
<da4938c20811190438t223e676cm87e454f6c290e7dd@...>



Hi Matthew,


Matthew Zimmerman wrote:

> The list rejected my "rich" formatting... resending.
>
> ---------- Forwarded message ----------
> From: Matthew Zimmerman <mzimmerman@...>
> Date: Wed, Nov 19, 2008 at 7:35 AM
> Subject: Getting around mutual Certificate authentication using
> safenet 2032 tokens enforced in a webapp
> To: pen-test <pen-test@...>, webappsec@...
>
>
> So my organization recently switched to requiring client
> authentication as well as server authentication on our web
> applications.  These places are using PKI certificates issued from our
> CA.  The client certificates are contained on safenet 2032 tokens
> (ikey, rainbow token, etc).  This is great for security.
>
> It's not great for security testing however.  Because of this, a proxy
> like Paros / Webscarab / Burp / etc won't work.  The webserver returns
> 4xx errors to us if we don't use the right cert.
>
> So there's two ways around it I think.  1) Get the whole certificate
> off of the token in PKCS#12 (including the private key) so we can
> import it into these tools.  

Usually not possible for token. The security of token lies in the fact
that no private key can be accessible outside of the token. It is no way
it can be get those thing off the token as PKCS #12
> 2) Work directly with the browsers to
> allow more manipulation other than URLs/GETs.  
This is more viable option.

> 3) Pass the http
> protocol through another tool that supports safenet 2032 tokens?
> (Would be very slow setting up each https connection...)
>
> Something that would work for #2 would be a browser addon like Tamper
> Data for Firefox; however, I can't seem to get the 2032 tokens to work
> with firefox correctly (seems to be that the 2032 only implements
> pkcs#11 and firefox is looking for a pkcs#12 device, but I am by no
> means a PKI guy).  Which brings me to addons that are available for
> internet explorer that allow on-the-fly modification; which I found
> none.
>  

Usually token provider will implement PKCS #11, which is the smart token
interfacing standard, which is international standard. I believe you can
integrate to Firefox with little effort. Most of the vendor however,
also distribute the MS CAPI interface, which immediately can be use with
IE.

Although option (2) is more viable, the integration of token to browser
is more SSL handshaking level integration, which means the browser will
look for token to involve in the SSL workflow. You can look at creating
a dummy SSL engine which loads PKCS #11 and the token and perform the
SSL handshaking with it. This approach is more to your option (3) already.
> 3) The last option is to request software certs (already in PKCS#12
> format) for all future tests.  Although with this case, it's pretty
> hard to convince to management to fix their SQL injection issue if you
> need someone on the inside to issue you a software cert instead of the
> 2032...
>  
Can you explain why it is hard to convince to management to fix their
SQL injection issue in soft certs case? I am looking at this is quite
viable.

> Any ideas?
>
> Thanks,
> Matt Z
>
> ------------------------------------------------------------------------
> This list is sponsored by: Cenzic
>
> Security Trends Report from Cenzic
> Stay Ahead of the Hacker Curve!
> Get the latest Q2 2008 Trends Report now
>
> www.cenzic.com/landing/trends-report
> ------------------------------------------------------------------------
>
>
>  

Thanks!

Chris




SCAN CONFIDENTIALITY NOTICE & DISCLAIMER

The contents of this e-mail and its attachment, if any ("message") are intended for the named addressee only and may contain confidential information. If you are not the named addressee, you must not copy this message or disclose it to any other person. If you received this message by error, you should delete this message immediately and notify the sender by return e-mail.

SCAN Associates Berhad, its subsidiaries and/or group companies ("SCAN") disclaim all liability for any error, loss or damage arising from this message being infected by computer virus or other malicious software. The views and other information in this message that do not relate to the official business of SCAN shall not be deemed provided nor endorsed by SCAN


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