Full Disclosure mailing list archives
RE: Openssl proof of concept code? / Neoteris
From: "Lachniet, Mark" <mlachniet () sequoianet com>
Date: Thu, 15 Jan 2004 17:32:15 -0500
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 () freeshell org] Sent: Thursday, January 15, 2004 3:31 PM To: Lachniet, Mark Cc: jfox () nsec net; full-disclosure () lists 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. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Openssl proof of concept code? / Neoteris Lachniet, Mark (Jan 14)
- Re: Openssl proof of concept code? / Neoteris petard (Jan 15)
- <Possible follow-ups>
- RE: Openssl proof of concept code? / Neoteris Lachniet, Mark (Jan 15)