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

[Matthew Zimmerman <mzimmerman () gmail com>]

On Tue, Oct 20, 2009 at 3:45 AM, Chris <"chrisliaw at gmail dot
com"@mta1.scan-associates.net> wrote:
> > 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
Agreed.  As I understand it, that's the difference between PKCS #11
and PKCS #12 :)  That's the point :)  But just because a security
control wasn't broken before, doesn't mean it won't be broken now ;)
(Just to clarify, I had no success here...)
> > 2) Work directly with the browsers to
> > allow more manipulation other than URLs/GETs.
>
> This is more viable option.
Found not really.  The integrated browser plugins weren't flexible
enough for me.
> > 3) Pass the http
> > protocol through another tool that supports safenet 2032 tokens?
> > (Would be very slow setting up each https connection...)
>
> 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.
This worked quite well with WebScarab.  It even talks http(s), so it
had all the parsing and everything intact.  The interface on how to
use it was a little clunky and confusing, but it worked beautifully
once it was setup.  Just remember to run java in debug mode (see my
earlier follow-up post for instructions on how it worked for me)  (I
realize it makes no sense, but it worked...)
> > 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.
> >
Yep.  Where I work we follow NIST guidance.  SP 800-30 says that risk
is comprised of the likelihood something is going to happen and the
impact of the event happening.  In terms of likelihood, no one in the
wild is going to have a software cert.  As previously discussed, we
hand out PKCS #11 tokens.  Given that, there's no way to get the
certificate off.  When I wrote this statement, I hadn't yet figured
out a way to tamper with the parameters the browser was passing when
using the PKCS #11 token.  So the fact that a tool would have to be
written to support that, made the likelihood of the event happening go
way down.  When likelihood goes down, the resulting risk goes down.

Matt

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