full-disclosure - Openssl proof of concept code? / Neoteris

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20040115203056.GA23103@SDF.LONESTAR.ORG>
From: petard at freeshell.org (petard)
Subject: 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.