From: mlachniet at sequoianet.com (Lachniet, Mark)
Subject: Openssl proof of concept code? / Neoteris

Good idea..  I will look at that approach.  

This is, BTW, more or less what the Nessus ssltest.nasl does - it has
its own built-in cert and offers it up without solicitation.  If the
server takes it (don't know about parsing it) it will flag it as
vulnerable.  If it doesn't take it, it calls it good.  That doesn't
actually address the "what if" of what happens if you actually *do* need
a valid client cert to hit the page - in this event, you get a false
positive hit because it will take the client cert anyway.

One thing I did (perhaps naively) try was to use openssl to generate a
PEM with funky data (a lot of !@#$ type stuff in all the fields).  I
then took that PEM and manually replaced chunks of valid cert info with
random data with VI to make the certificate even LESS likely to work.  I
then used that cert with STUNNEL and connected to the target device with
netcat, and manually issued some HTTP GET commands.  Strangely, it
worked like a charm, and even established a valid SSL session with my
very broken cert.  Granted, thats not exactly broken ASN.1 encoding, but
its awfully broken as far as certs go.  I'm amazed it could set up an
SSL connection with the server with a corrupt cert like that.

Thank you very much for taking the time to write out that verbose
description.  The example server-side messages will be helpful.  

Mark Lachniet



-----Original Message-----
From: petard [mailto:petard@...eshell.org]
Sent: Thursday, January 15, 2004 3:31 PM
To: Lachniet, Mark
Cc: jfox@...c.net; full-disclosure@...ts.netsys.com; Michael Iseyemi
Subject: Re: [Full-Disclosure] Openssl proof of concept code? / Neoteris


On Wed, Jan 14, 2004 at 04:34:53PM -0500, Lachniet, Mark wrote:
> I did search packetstorm (as always) prior to posting, but came up
short.  I also spent a lot of time googling the usual suspects.  There
was some older gobbles openssl code but nothing that seemed to be
appropriate to the most recent issues.  Its possible I missed something,
but I would think someone would have pointed out my error by now if that
were the case. 
> 
> FWIW, since posting I have not received a single positive lead on an
OpenSSL PoC at all.  There are plenty of folks who have one, but they
aren't talkin'   Hence, I think there are still some products out there
that are vulnerable, vendors who aren't fixing it, and a small subset of
individuals with the ability to exploit it.  Not exactly a great recipe
for risk management IMO. 
> 
> One device that I'm particularly interested in getting more
information on is the Neoteris SSL VPN appliance.  It fingerprints as
Apache 1.3.26 or thereabouts, and has SSL support, so I am guessing that
it is running the OpenSSL code base.  Yet, I don't see them listed in
any of the advisories.  It could be a "silent patch" but it could still
be vulnerable.  Anyone know?
> 

This isn't as good as ./ready-to-run PoC code, but it may help you just
the same... I've caught out a few products this way myself.

First, modify a copy of openssl such that it sends a client certificate
regardless of whether the server requests one. This is a one-line
modification and should be trivial if you understand the client-server
SSL handshake. Then configure your server such that it does not request 
client certificates. Generate a throw-away self-signed client
certificate and key, and drop them into a PEM file. Using a standalone
openssl application built against your modified openssl tree, connect to
the server in question. For example:

openssl s_client -connect host:443 -cert throwawayclientcert.pem

Carefully observe the error that results from this connection. Also look
in the server logs for messages similar to:

depth=0 /CN=tiny-client/C=US/O=throwaway-pki
verify error:num=20:unable to get local issuer certificate
verify return:1

which indicate an attempt to parse a client certificate... the server
should not try to parse certificates it doesn't request. This is the
reason the ASN.1 parser bugs affect so many servers.

Here's an example of my modified client running against a vulnerable
(0.9.7b) server:
$ apps/openssl s_client -connect localhost:4433 -cert client.pem
CONNECTED(00000003)
depth=0 /CN=tiny/C=US/O=throwaway-pki
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /CN=tiny/C=US/O=throwaway-pki
verify error:num=27:certificate not trusted
verify return:1
depth=0 /CN=tiny/C=US/O=throwaway-pki
verify error:num=21:unable to verify the first certificate
verify return:1
!!! s3_clnt.c [326] Sending a client cert even though the server didn't
ask for one!
2312:error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected
message: s3_pkt.c:1052:SSL alert number 10
2312:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:226:
$

By contrast, here it is running against a patched (0.9.7c) server:
$ apps/openssl.exe s_client -connect localhost:4433 -cert client.pem
CONNECTED(00000003)
depth=0 /CN=tiny/C=US/O=throwaway-pki
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /CN=tiny/C=US/O=throwaway-pki
verify error:num=27:certificate not trusted
verify return:1
depth=0 /CN=tiny/C=US/O=throwaway-pki
verify error:num=21:unable to verify the first certificate
verify return:1
!!! s3_clnt.c [326] Sending a client cert even though the server didn't
ask for
one!
write:errno=104
$

What happened here is that the patched server shut the connection down
in an orderly fashion without parsing the client certificate, while the
unpatched one parsed the cert and reacted badly. 

Hope this helps,

petard

--
If your message really might be confidential, download my PGP key here:
http://petard.freeshell.org/petard.asc
and encrypt it. Otherwise, save bandwidth and lose the disclaimer.

Powered by blists - more mailing lists