L0pht Security Advisory Advisory released Jan. 21, 1999 Application: Quakenbush Windows NT Password Appraiser Severity: Users of the tool Password Appraiser are unwittingly publishing NT user passwords to the internet (even if your company is behind a firewall). Author: mudge@l0pht.com http://www.l0pht.com/advisories.html --------- Overview : --------- During an internal analysis of a tool which claimed to audit NT passwords we noticed said tool sends users password hashes to a remote system on the internet via HTTP. In addition to this, should the password be known to the remote server, the plaintext equivalent is sent back across the internet to the querying machine. What this means, in a nutshell, is that if you are in any sort of organization connected to the internet - behind a firewall or not* - and you run this program: You send all of your users passwords out through the internet. (* as long as you are permitting {users,employees} to surf the web) This of course, makes the fact that you are trusting a third party with your password information in the first place, a smaller concern by comparison. Quakenbush is aware of this problem - yet there have been no statements that this will ever be fixed or addressed from them. ----------- Disclaimer : ----------- This is a touchy situation as the product in question can be viewed as a competitor to the L0pht's own L0phtCrack 2.51 tool. As such, we are going to do our best not to place any comparison on the two tools functionality, performace specs, etc. in this advisory as this is not a marketing blurb - but instead our regular service to the security community. In all good consciousness we could not keep it a secret that anyone who has run Password Appraiser has unwittingly exposed their private passwords. We hope that various government agencies that are connected to the network and run large NT installations were not bitten by this problem. ------------ Description : ------------ Password Appraiser is a tool that allows administrators to "Find accounts with weak passwords" [1] on NT systems. In actuality what it does is compare only the weaker LANMAN hash against a set of precomputed LANMAN hashes for a table lookup to see if the password is "weak". The Demo version *only* allows one to run the program via quering across the Internet. Other versions allow querying across the internet and/or a local dictionary containing a smaller subset of words/hashes. We were checking the program out locally in our labs and at the same time had taken a copy on an auditing gig of a large corporation ( >300,000 systems with huge NT domains and PDC's). We were interested in how this tool compared to L0phtcrack in real world situations. To see how the tool works we hooked up some network sniffers and ran the demo version on one of our test machines in our local labs. Much to our surprise we watched the LANMAN hashes being sent IN THE CLEAR to pw.quakenbush.com. For the passwords that the server had in its dictionary a plaintext response was sent back. Our jaws dropped on the floor. A quick call to the l0pht member at the large corporation caught him just in time to prevent the running of the program on the corporations main PDC. A few seconds later and all >4000 users hashes (and any plaintext responses) would have been sent out, through the firewall, and across the internet. We know in the above situation that many of the users NT passwords were also the passwords that they chose for various remote access methods. This information could have been used to completely bypass the corporate firewall. So people realize that it is not just the plaintext responses that we are so concerned about - we captured some of the hashes that Password Appraiser could not crack and ran them through publicly available tools in brute force mode to recover the passwords. It is important to mention that user names are not sent across the wire. However, without the usernames the above threat is still quite real. The problem lies the known quantities: the location/site that sent the passwords, and the actual passwords. It is a trivial step to gather the usernames from this point forward. [ Case examples: had the user accounts on our test machine been the actual 7 members of the l0pht it would have been trivial to find our e-mail names and try the passwords. With the large company, many of the passwords were the same and though they would not have been "cracked" by Password Appraiser, they were vulnerable to other tools performing NT password analysis. Determining valid usernames to try with the recovered passwords is easily accomplished through enumeration on sites such as www.four11.com, and whois databases to name a few resources.] -------- Details : -------- Sniffing traffic to port 80 of pw.quakenbush.com shows the following information being exchanged: local client machine == [A] remote dictionary server [pw.quakenbush.com] == [B] [ Example 1 - demonstrating vulnerability on Password Appraiser sending LANMAN hash and plaintext equivalent from "weak" password ] [A] -> [B] GET /default.asp?cid=[*]&v=3086&pw=D85774CF671A9947AAD3B435B51404EE HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* User-Agent: Microsoft URL Control - 6.00.8169 Host: pw.quakenbush.com [*] Note - the cid is the verification mechanism so the server can austensibly check that the client is indeed paid for. The number that was removed was the evaluation number that was automatically sent upon downloading the software. Its value is unimportant for this advisory. [B] -> [A] HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Date: Wed, 20 Jan 1999 23:51:14 GMT Content-Type: text/html Cache-control: private Transfer-Encoding: chunked 12 ::PW::FOOBAR::PW:: 0 From this, one can see that password appraiser only works on the deprecated LANMAN hash which is, in this case : D85774CF671A9947AAD3B435B51404EE The response shows that the password being checked was FOOBAR (case sensitivity is unknown as the program does not look at the NTLM hash). The above can be witnessed during any stage in transit to the quakenbush server. The attacker now has the password. [ Example 2 - demonstrating vulnerability on Password Appraiser sending LANMAN hash of a "strong" password ] [A] -> [B] GET /default.asp?cid=[*]&v=3086&pw=8F4272A6Fc6FDFDFAAD3B435B51404EE HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* User-Agent: Microsoft URL Control - 6.00.8169 Host: pw.quakenbush.com [B] -> [A] HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Date: Thu, 21 Jan 1999 00:09:03 GMT Content-Type: text/html Cache-control: private Transfer-Encoding: chunked 19 ::PW::::PW:: 0 Here, the LANMAN hash is : 8F4272A6FC6FDFDFAAD3B435B51404EE. We see from the response from Password Appraiser that it believes this password to be secure. Unfortunately, people sniffing the network who plug this hash into other tools take advantage of the weak design behind LANMAN [2] and retrieve the password of 'BOGUS!!' in under 1 minute. ----------- Conclusion : ----------- There are several good aspects to the Password Appraiser tool. Unfortunately they appear to be in the non-security critical components. The notion of sending such priveleged information [internal user passwords and hashes] across the public networks is problematic. If there is no attempt at encryption then the attack is kindergarden level. If there is some sort of encrypted sleeve (ie an SSL session) then the attack is elevated a level but still possible as anyone can spoof as the server and harvest password hashes. Certificates would raise the bar even further but the problem of end-node security comes into play. One has to trust that the pw.quakenbush.com server is more secure than their corporate firewall or other protective measures. While in many cases this might be true - there are undoubtedly cases where it is not. In these cases, since one has handed critical security information about internal systems, the overal security is lowered due to the weakest link. The only way we saw to avoid this problem was to enable the end user to be completely self contained and not reliant upon external sources for cracking passwords. The moniker "Who has the keys to your business [3]" takes on an entire new light given the vulnerabilities in this advisory. mudge@l0pht.com --------------- For more L0pht (that's L - zero - P - H - T) advisories check out: http://www.l0pht.com/advisories.html --------------- References: -- [1] quoted from Quakenbush web page at http://www.quakenbush.com/default.htm [2] information on some LANMAN hash weaknesses and other tools can be found at http://www.l0pht.com [3] "Who has the keys to your business" - Main slogan on http://www.quakenbush.com -------------------------------------------------------------------------- Date: Mon, 25 Jan 1999 15:04:18 -0500 From: Weld Pond To: BUGTRAQ@netspace.org Subject: Re: L0pht Security Advisory on NT Password Appraiser (fwd) 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 >