Full Disclosure mailing list archives
Openssl proof of concept code? / Neoteris
From: "Lachniet, Mark" <mlachniet () sequoianet com>
Date: Wed, 14 Jan 2004 16:34:53 -0500
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? Mark Lachniet -----Original Message----- From: Joe Fox [mailto:jfox () nsec net] Sent: Wednesday, January 14, 2004 4:00 PM To: full-disclosure () lists netsys com Cc: Michael Iseyemi Subject: Re: [Full-disclosure] Re: Openssl proof of concept code? Michael -- If that's the case, then why even mention anything? Unless there is an openssl exploit that you can disclose. Mark -- Checkout http://www.packetstormsecurity.nl and search for openssl. I believe that you should be able to find some proof of concept code there. Joe On Wed, 2004-01-14 at 14:29, Michael Iseyemi wrote:
Mark, There actually is a succesful demo of this exploit that I am aware of. I'm however not at liberty to divulge this as it is a littlebit convoluted and also includes integration testing and efforts between several components of a PKI. Thanks, Michael -- "Lachniet, Mark" <mlachniet () sequoianet com> wrote: > Please excuse the cross-post, and please forgive meif I am missing something that I should have found through conventional sources. A few months ago, there were issues with the openssl code base, as noted on bugtraq and in the following URLs: http://www.openssl.org/news/secadv_20031104.txt and http://www.openssl.org/news/secadv_20030930.txt. It was stated that these flaws were found using a test suite from NISCC (www.niscc.gov.uk). However, this toolkit is apparently not publicly available (you need to be a SSL developer?), and I find no record of a proof of concept test for this vulnerability. Given that a large number of vendors use this code base in their products it is no surprise that there are a lot of products that needed updates. However, I'm not convinced that every vendor has actually "come clean" about their vulnerability to these problems. Is anyone aware of a reasonable way for an analyst to definitively demonstrate if the vulnerabilities exist in a particular product? Since some of the bugs deal with bad client certificates, some might be as easy as getting a copy of a "bad" client certificate and connecting to the server using a program such as stunnel, but I have yet to see anything about this. Alternately, has anyone written a good program to remotely identify what SSL codebase is in use, other than looking for it in HTTP server headers? Nessus' ssltest.nasl can allegedly distinguish between a openssl and MS CryptoAPI or Novell, but this isn't really enough in my opinion. If conventional tools (i.e. Nessus and other scanners) can't really fingerprint it, how might one go a little further and determine this from a "black box" perspective? I understand that with a good deal of development time and effort, this can probably be done, but this is probably not realistic for most organizations to do on their own. Its been a while now, and responsible vendors should have already issued patches. Also, since there is no proof of concept, that I am aware of anyway, it seems to me that there is still some exposure from these bugs that people may not be aware of. It would be nice to have a test so that people could better gauge their exposure. Can anyone offer a reasonable solution to this problem? Thanks, Mark Lachniet______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
-- Joe Fox, CCSA Network Security Corp http://www.nsec.net 716.692.8183 _______________________________________________ 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)