What "anonymous" said (below). I had permission to forward this, but I figured it might attract more interest if it were "anonymous" to people who can't read headers. Almost two months after Peter and Frank demonstrated that it was untrue, and one month and five days after Microsoft "significantly improved" Windows 95 by providing a patch for the exact same algorithm, Microsoft this very second still says that the .PWL algorithm as used in Windows for Workgroups is secure. http://www.microsoft.com/kb/peropsys/windows/q90271.htm This article will also be included on thousands of copies of the February TechNet CD-ROM. Other Knowledge Base articles have been corrected in less than a day. Yusuf's statement that my January 16th email is the first that he had heard of the .PWL problem is both patently ridiculous and directly contradicted by private email from anonymous sources on this list whom T. C. May has killfiled. In other news, the international versions of the SMB and C$ bug fixes exploited by Samba and Paul Brainard were finally posted today (as usual, they're dated yesterday). So the non-US public shares listed on, for example, www.winserve.com no longer have to be completely open to everyone on the Internet. Yusuf Mehdi, the Windows 95 Product Manager, had told me on November 9th that these internationalized patches would be posted "within two weeks." No excuse for this two-month delay has been offered. Yusuf also, well, lied on November 9th when he said that Microsoft had "sent mail to the newsgroups" retracting their statement that the SMB bug was caused by Samba sending "illegal network commands," and clarifying that the patches dated October 20th only work on US/English versions of Windows 95. The original Microsoft announcement as released to the media and WinNews is at: gopher://quixote.stanford.edu/0R593020-600291-/win95netbugs The current version, which contrary to Yusuf's statements on November 9th does not indicate that there has been any change, is at: http://www.microsoft.com/windows/software/w95fpup.htm By the way, MSN is going to allow access via TCP/IP soon. Let's make sure they do it securely. -rich ---------- Forwarded message ---------- Newsgroups: comp.security.misc,comp.os.ms-windows.nt.admin.networking,alt.security,comp.os.ms-windows.networking.windows,comp.os.ms-windows.programmer.networks Path: nntp.Stanford.EDU!news.Stanford.EDU!nntp-hub2.barrnet.net!newsfeed.internetmci.com!nuclear.microserve.net!luzskru.cpcnet.com!not-for-mail From: anonymous@alpha.c2.org Subject: Code demonstrating Microsoft Windows insecurity on networks Sender: rich@infinity.c2.org Message-ID: <4dnmcu$pt4@infinity.c2.org> Date: 19 Jan 1996 00:57:02 -0800 Organization: http://www.c2.org/hackmsoft/ Summary: Cypherpunks share code Lines: 210 Just a little something to hurry this liar up: Received: from tide10.microsoft.com (firewall-user@tide10.microsoft.com [131.107.3.20]) by infinity.c2.org (8.7.1/8.6.9) with SMTP id JAA14902 for <hackmsoft@c2.org>; Tue, 16 Jan 1996 09:07:26 -0800 (PST) Community ConneXion: Privacy & Community: <URL:http://www.c2.org> Received: by tide10.microsoft.com; id JAA00999; Tue, 16 Jan 1996 09:28:16 -0800 Received: from unknown(157.54.17.74) by tide10.microsoft.com via smap (g3.0.3) id xma000913; Tue, 16 Jan 96 09:27:48 -0800 Received: from xnet2 (xnet2.microsoft.com [157.54.17.205]) by imail2.microsoft.com (8.7.1/8.7.1) with SMTP id JAA02991 for <hackmsoft@c2.org>; Tue, 16 Jan 1996 09:15:28 -0800 (PST) X-Received: from xmtp4 by xnet2 with receive; Tue, 16 Jan 1996 09:12:22 -0800 X-Received: from RED-02-IMC by xmtp4 with recvsmtp; Tue, 16 Jan 1996 09:08:41 -0800 Received: by red-02-imc.itg.microsoft.com with Microsoft Exchange (IMC 4.22.611) id <01BAE3F2.39A25280@red-02-imc.itg.microsoft.com>; Tue, 16 Jan 1996 09:08:39 -0800 Message-ID: <c=US%a=_%p=msft%l=RED-72-MSG-960116170828Z-11006@red-02-imc.itg.microsoft.com> From: Yusuf Mehdi <yusufm@microsoft.com> To: Rich Graves <llurch@networking.stanford.edu>, Yves Michali <yvesm@msg.microsoft.com> Cc: "pgut01@cs.auckland.ac.nz" <pgut01@cs.auckland.ac.nz>, "hackmsoft@c2.org" <hackmsoft@c2.org>, Robert Bennett <rbennett@msg.microsoft.com>, Michael Ahern <mikeah@msg.microsoft.com>, Russell Stockdale <rust@msg.microsoft.com> Subject: RE: Need confirmation of Win95 password encryption back door (fwd) Date: Tue, 16 Jan 1996 09:08:30 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.22.611 Encoding: 204 TEXT X-MsXMTID: xmtp4960116170841RECVSMTP[01.52.00]000000fb-49231 Rich, Thanks for your email. This is the first I've seen of your email. I'm forwarding to Mike Ahearn who will handle any issues. If we have outdated information in the knowledge base, I apologize and we will certainly correct asap. Mike will investigate and let you know the outcome. As always we appreciate your feedback. Yusuf ---------- From: Rich Graves[SMTP:llurch@networking.stanford.edu] Sent: Tuesday, January 16, 1996 5:06 AM To: Yusuf Mehdi; Yves Michali Cc: pgut01@cs.auckland.ac.nz; hackmsoft@c2.org Subject: Re: Need confirmation of Win95 password encryption back door (fwd) [A reply to a cypherpunks post] Peter, I'm forwarding this to the Windows 95 Product Manager, who does not seem to be taking this at all seriously, and Bcc'ing it to the technically knowledgeable reporters I mentioned in my other message and to four Microsoft engineers who have sent me mail, two of them on condition of anonymity (at least one of whom fears management reprisals). I don't see any particular reason to tell Microsoft everyone I am talking to, especially since they have been less than completely honest with me. Yusuf, please ask the Windows for Workgroups group to at least acknowledge the .PWL encryption bugs they have known about since at least November 29th, correct the Knowledge Base articles that explain how secure .PWL files are, and let the public know whether they have any plans to fix these bugs and fundamental architectural weaknesses. To put this more succinctly, the below, from Q90271, is complete bullshit, and you know it. The password list file is encrypted with an algorithm that meets the U.S. government Data Encryption Standard (DES). This encryption technology is the highest security allowed in software exported from the United States. The odds of breaking the encryption algorithm are less than those for random guesses of what the password might be. If you don't spread the word, we will. All it takes is a couple of free hours on CompuServe, America Online, Prodigy, Delphi, and the Microsoft Network, not to mention the Internet itself. Right now, my mailing list has 600 serious network managers in 20 countries, and my Web site gets about 1,000 hits per day (that's the main site; there are also mirrors in Russia, the UK, and Australia). -rich ---------- Forwarded message ---------- Date: Wed, 17 Jan 1996 01:15:20 +1300 (NZDT) From: pgut01@cs.auckland.ac.nz To: llurch@networking.stanford.edu Subject: Re: Need confirmation of Win95 password encryption back door
A Major Media Outlet requires confirmation that Windows 95, to facilitate its automatic reconnect feature for sleeping laptops and temporary network outages, caches all network passwords (NetWare, NT, UNIX running Samba, SLIP/PPP dialup) in unprotected memory in clear text, whether you've disabled persistent "password caching" to disk and applied the December 14th 128-bit RC4 .PWL patch, or not. There seems to be no way to turn this off.
Would you like me to confirm it for WfW? Actually you can problably do it for Win95 by removing the password file after the initial connect. If Win95 can reconnect with the password file missing, then the passwords are still in memory. You'll have to be careful though to make sure they're not being read from the Windows disk cache, loading Word in between killing the connection and trying to reconnect should clear the password file from the cache.
So, anyone have Win95 and some time to kill, or can anyone recommend a good DOS/Windows RAM grepper?
from a user process. In any case a VxD should be able to grep all of memory in
Given that the descriptor tables are apparently unprotected in Win95 (which is pretty incredible), it shouldn't be too hard to get access to all of memory the background without the user even being aware of it.
We know that this vulnerability exists in Windows for Workgroups, and Peter wrote a little demo (on hackmsoft page below, without source), but the APIs appear to have changed in Win95.
Sorry about the delay in getting this to you, as I mentioned before it was on a machine a fair way away, stuck behind a firewall. I haven't included all the SMTP stuff and whatnot because there's quite a bit of it and it's boring, the routines which do all the work are the following... This is the function called by WNetEnumCachedPasswords() to enumerate each password: [*CODE DELETED*] /* Record the password information */ [*CODE DELETED*] /* Signify that we want to move to the next entry */ [*CODE DELETED*] This is the function which actually does the enumeration. The for() loop defines what resources you want to get passwords for. [*CODE DELETED*] /* Get the proc. address of the password manipulation function */ [*CODE DELETED*] /* Enumerate the passwords */ [*CODE DELETED*] To find out (for example) what disk drive resources you're using: /* Check each drive to see if it's a network resource */ for( driveNo = 2; driveNo < 26; driveNo++ ) if( GetDriveType( driveNo ) == DRIVE_REMOTE ) { char password[ 100 ], resource[ 100 ]; char *driveName = "x:"; WORD passwordLength = 100, resourceLength = 100; BYTE resourceNo; int i; /* Find the name of the network resource for this drive number */ *driveName = 'A' + driveNo; WNetGetConnection( driveName, resource, &resourceLength ); } This code should be modifiable by anyone to get any password for any resource. I'll leave it to you to decide how much to publish, the worry is that if you publish all of it people will whine about it helping hackers. Might I suggest something like: /* Get the proc. address of the password manipulation function */ WNetEnumCachedPasswords = ( LPWNETENUMCACHEDPASSWORDS ) \ GetProcAddress( WNetGetCaps( 0xFFFF ), \ MAKEINTRESOURCE( ORD_WNETENUMCACHEDPASSWORDS ) ); if( WNetEnumCachedPasswords == NULL ) exit( EXIT_FAILURE ); /* Enumerate the passwords for the resources we want. This only gets the first password, in practice we'd keep calling WNetEnumCachedPasswords() until the enumPasswordProc() tells us (via the returned status) to stop, then move on to the next resource */ for( resourceNo = START_RESOURCE; resourceNo <= END_RESOURCE; resourceNo++ ) status = ( *WNetEnumCachedPasswords )( "", 0, ( BYTE ) resourceNo, \ enumPasswordProc ); This shows how simple it is, but doesn't give people something they can just cut and paste into their own code to get something which will give them all passwords. You may want to include the "find drive resources" code fragment as well as an example of how to do this, although it's not really necessary. Feel free to forward this to whoever you think is appropriate, although it's probably best not to give the get-any-password capable version to the masses. Peter.