[9227] in bugtraq
Re: L0pht Security Advisory on NT Password Appraiser (fwd)
daemon@ATHENA.MIT.EDU (Weld Pond)
Tue Jan 26 14:22:07 1999
Date: Mon, 25 Jan 1999 15:04:18 -0500
Reply-To: Weld Pond <weld@L0PHT.COM>
From: Weld Pond <weld@L0PHT.COM>
X-To: David Damerell <djsd100@cam.ac.uk>
To: BUGTRAQ@NETSPACE.ORG
On Fri, 22 Jan 1999, David Damerell wrote:
> I have been in communication with Mr. Quakenbush. He says that only
> the demo version sends passwords in plaintext (I clearly have no
> mechanism to confirm this); bought versions use SSL. He has not yet
> addressed the issue of impersonating the server. He says that the Web
> site will be updated to reflect recent developments.
> It looks like this is better than it looks; presumably the l0pht folks
> only had access to a demo version. The Quakenbush Web site does make
> it clear that the 'full' version uses SSL, but not prominently.
The version (3.0.89) that supports SSL came out a day after the L0pht
Advisory. We commend Mr. Quakenbush for his fast response to our advisory
but to pretend that his product did this before our advisory is
disengenuous. His response to our advisory on his web site even states
that SSL was added in response to our advisory.
The response also states that changes have been made to keep the cleartext
password from every travelling over the internet. A feature added
directly in response to our advisory.
> Assuming that the issue of impersonating the server is addressed,
> Quakenbush seem to be better than first portrayed here - although
> clearly the demo version should be more obviously marked as to how
> extremely dangerous it is.
Yes, better because we made users and the vendor aware of serious security
flaws in the Password Appraiser product. Our advisory had the desired
effect. These changes may never have taken place if our security
analysis of the product had never been done and made public. The product
was in its 3rd major release and the security vulnerability was still
there.
> [There was the usual marketing blurb about how they write tools for
> crackers and we write them for good guys and so our tools must be
> better.]
Har. Har. So because our tool is more powerful and doesn't require sending
your hashes to an untrusted party, ours is for crackers and not for NT
administrators and NT security professionals?
OK, now let me then offer a blurb. Serious architecture flaws such as
sending password hashes and passwords in the clear over the internet shows
a lack of security expertise. Really, this is kindergarten stuff here.
Windows NT has been using a challenge-response mechanism to encrypt the
password hashes as they travel over the netowrk for years. There are still
some vulnerabilities there but the concept of requiring hashes to be
encrypted over a network is surely not new.
I question the notion of sending your hashes to a software tool
vendor at all. There is nothing stopping them from brute forcing the
hashes that they don't have in their dictionary and later adding them to
their dictionary. Now their dictionary becomes extremely valuable to
anyone trying to attack a company or organization that uses their product.
If this was to fall into the wrong hands your organization would be at
increased risk.
-weld
> --
> David Damerell, Computer Officer, Department of Chemistry, Cambridge
> Work: djsd100@cam.ac.uk Personal: damerell@chiark.greenend.org.uk
>
