They will be proven wrong.
Let's see what Microsoft does when the world finds out that their systems are insecure. More details will appear in the coming days. Last updated February 23, 1996. Send your hacks to hackmsoft@c2.org.
To merit an award, an exploit must be made publicly available. Also note that "hack" connotes affirmative effort on your part to investigate and expose encryption and security architectures. Merely finding bugs and common configuration errors is not a "hack," and will not be credited on this page, though you can report such problems to rich@c2.org. We may be supporting an "other security problems" page in the future, but other forums are probably more appropriate.
Note that Microsoft has recently begun making noises about the folly of the United States Government's policies banning the export of strong cryptography. We very much welcome Microsoft's late entry into this debate, but it should be noted that the implementation bugs below have nothing to do with limitations on cryptographic strength, and Microsoft knows it. Anyone who knows anything about cryptography, and most people who don't, can see that Microsoft's claim that the .PWL update is 2^96 times stronger because it uses a larger key size is, well, a crock. Even Netscape's PR spin on their September problems wasn't so transparently dishonest.
The screen-saver passphrase in Windows and Windows for Workgroups 3.x offers a false sense of security. While it is easy to turn the screen-saver off with a simple text editor, the greater risk is in the weak encryption used to store the screen-saver passphrase. For convenience, many people use the same passphrase in a variety of applications. The weak XOR-ing encryption (see http://www.eskimo.com/~joelm for a utility and source code that decrypts the password) used for the screen-saver passphrase presents a significant threat for people that use only a single or several passphrases. Even if they are using a cryptographically strong application such as PGP, if they are using the same passphrase as the Windows screen-saver, they might as well be sending plaintext e-mail messages.
This problem is compounded with other Microsoft applications such as Word and Excel, which use similarly weak encryption to supposedly protect files. The New York Times wrote an article about various other security bugs in Microsoft products. A variety of free and commercial utilities are available that can quickly "crack" encrypted documents.
When a Windows for Workgroups or Windows 95 machine shares any folder, bugs in Microsoft's SMB implementation over all network protocols allow access to the whole drive, with whatever permissions the sharename was given. These resources are advertised on a browse list that is made available to anyone on the local network by default, and to anyone on the Internet who knows the machine's IP address. Any user sharing any folder over TCP/IP without a password is opening the whole disk to the whole Internet (for those that can locate the machine) and those with a password should be aware that Windows has no protection against brute force attacks. SMBCLIENT, an ftp-style browser for any UNIX, plus a complete file system for Linux and a few UNIX versions, are available from the Samba web site. Please note that Samba's exploitation of this fundamental bug in Microsoft file sharing was unintentional, and was immediately reported to Microsoft. It could have happened with any client over any protocol.
An alleged fix for Windows for Workgroups was quietly released in early October, and Microsoft publicly announced a fix for Win95 on October 20th. It has not been rigorously tested, but it appears to fix the problem. The fix for Windows for Workgroups might not be a complete fix, but rather a patch for one way to exploit the problem. (The release version of Win95 prevented cd .. below the shared folder "root," but not cd ../) The patches and Microsoft press releases (which have been corrected at least twice, but which still erroneously identify Samba as shareware, neglect to credit the people who notified Microsoft of the problem, and neglect to mention that this is a fundamental bug in Windows, not a problem specific to TCP/IP or Samba) are available on Microsoft's Windows 95 Updates Page. The patch only works on the US/English version of Windows 95; at this writing, all non-English versions of Windows 95 are still vulnerable.
With Remote Administration and File Sharing for Netware Networks enabled on a Windows 95 machine, once a remote administrator accesses the system, a shared resource pointing to the hard drive is created to which all users on the same network have access. This share remains available even after the administrator logs off the system. The shared drive is not visible by browsing through the Explorer, but may be found by mapping a network drive to \\computername\C$. This gives read-only access to the entire local hard drive of the sharing computer.
By default, Windows 95 and Windows for Workgroups implement a "password caching feature" whereby the passwords for all network services (NetWare, NT, Samba, SLIP/PPP service) are automatically and permanently stored in C:\WINDOWS\<USERNAME>.PWL. Microsoft claims they are encrypted securely.
Peter determined that the Windows PWL encryption algorithm was incredibly insecure. Frank wrote a program to break the .PWL files in Windows. (More details are forthcoming, a draft version is available currently.) Source code and a Windows NT executable for the exploit program are available. In effect, anyone with physical or network access to a Windows machine has access to all network passwords used by all users of that machine.
Late afternoon December 14th, Microsoft released an alleged fix (altenate site here) for the problem, which is supposed to make passwords harder to find, but it has not been reviewed by outside experts, and it doesn't even come with a ReadMe file. Unlike Netscape, Microsoft has not published its encryption algorithm for the customary peer review. Until they do, we recommend disabling password caching and user profiles; see the win95netbugs list archive and FAQ.
Peter
wrote this modest trojan horse demonstration, mail.zip.
Invoke it as mail hackmsoft@c2.org (or whatever address you consider
appropriate) on any Windows for Workgroups machine with a TCP/IP connection
and it will send you (or anyone else) the first password cached on your
machine, unencrypted.
Note that this hack does not contain any decryption
code; it merely uses the WNetGetCachedPassword() call, which is available
to any program. Proper security architectures, such as the corresponding
subsystem in Windows NT, have an internal security perimeter to prevent this
kind of thing. This quick hack doesn't support MX aliasing, so you
might need to point it directly at your SMTP server. Because some network
calls do not seem to be supported in Windows 95, this program currently only
works with WFW (but this is only a minor implementation issue, which could
be fixed).
"Disabling password caching" does not completely address this vulnerability, because passwords are still stored in memory to facilitate the "automatic reconnect" feature, which is designed to maintain connections through laptop "suspend" mode and temporary network problems. Neither is the alleged fix for Windows 95 (above) relevant.
A person less kindly than Peter could easily write a malicious trojan horse or virus, perhaps distributed by any one or more of the means suggested on this page, that could email network passwords through a secure, untraceable chain of remailers to a throwaway trial AOL or CompuServe account. Frank (above) has some "good" ideas that he has decided would be irresponsible to implement. By playing coverup, Microsoft is flirting with real disaster for itself and its customers.
Donald Moore discovered the algorithm used in the Microsoft CD keys. Someone can ue the information on this web page to generate their own key, which the Microsoft sofware wants before you can install things from the distribution CDs. Yes, Donald knows that all zeroes and even blanks are valid for many CDs; please just read his explanation.
We don't want to encourage piracy, but we don't want honest people who lose their "key" to be at a disadvantage while counterfeiters have known about this for months, either.
Peter has posted quite a few articles in CompuServe's Database forums and to the newsgroup comp.databases.ms-access concerning the weakness of Microsoft Access. More details will be forthcoming as we determine what can safely be exposed without seriously undermining the security of every database in use, and as we honor Peter's copyright.
Utilities to break the very poor encryption in Microsoft Word are available on Bokler Software's Crack Web Site. These take advantage of bugs in Microsoft's implementation to open supposedly secure documents in a second; they do not "brute-force" the password.
This wasn't quite what we had in mind, but Schulman's investigation of the "Registration Wizard" is simply a joy to read, and has some good links to relevant sites.
Martin is leading the development of an NT File System for the UNIX-like Linux operating system, which is freely available from lots of places. Essentially, this patch allows you to build a boot floppy that allows access to files on a supposedly secure Windows NT Server.
Microsoft acknowledges, in a footnote to article Q100108 in the Knowledge Base, that it is possible to "boot under MS-DOS, or another operating system, and use a low-level disk editing utility to view data stored on an NTFS volume," but there is of course no reason that the tool needs to be "low-level."
NTFS for Linux is distributed as a gzipped tar file (only 34K) under the terms of the GNU Public License. You may want to browse the ReadMes or read some technical information about NTFS first.
At this early stage in its development, NTFS for Linux allows read-only access. In the spirit of the GNU and Linux projects, please download the code and help Martin make it read/write and more stable. Microsoft, as might be expected, is not eager to help reverse-engineer NTFS.
Please see Martin's NTFS project page for the latest news, and to offer to help.
It seems that the passwords for Windows 95 file and print sharing (Windows 95 acting as a server) are encoded byte for byte with a simple "secret decoder ring" algorithm. Please refer to David's description of his exploit of this problem. Commented C source code is available. A basic understanding of Microsoft's "code" would allow a malicious virus or trojan horse to extract share passwords without the user's knowledge.
