From: Rich Graves <llurch@networking.stanford.edu>
Date: Fri, 19 Jan 96 15:09:33 PST
To: cypherpunks@toad.com
Subject: Code demonstrating Microsoft Windows insecurity on networks (fwd)
Message-ID: <Pine.ULT.3.91.960119142610.468I-100000@Networking.Stanford.EDU>
MIME-Version: 1.0
Content-Type: text/plain


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?
 
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
>from  a user process.  In any case a VxD should be able to grep all of memory 
in
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.