Openssl proof of concept code? / Neoteris

["Lachniet, Mark" <mlachniet () sequoianet com>]

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