Unix-savvy folks nowadays are used to having source for their operating systems, especially where there are security concerns, or at least are easily able to implement replacements and enhancements to the weak vendor-supplied stuff. Microsoft not only makes this unavailable and difficult, it relies heavily on internal obscurity and deliberate lack of documentation as part of security architecture. Since Microsoft refuses to help even when asked, the Samba developers have had to go through many contortions and waste a lot of valuable time reverse-engineering things just to support certain features. A reader can *feel* the triumph in those occasional messages to the Samba list when someone works out one of those "undocumented Microsoft" things and submits a patch. Security is often an arms race, which Microsoft is simply escalating and making worse for everyone by producing yet more flimsy obscurity. If it is not there already, NT source code will eventually hit underground circulation as ubiquitously as that of other "proprietary" operating systems. We should expect that numerous exploits of the obscurity will have even the security-concerned sites falling like dominoes.

As we review some of its more blatant failings, the fundamental design of CIFS authentication quickly becomes ridiculous. The draft even describes several potentially serious security problems, but inexplicably makes no attempt to FIX them. Part of the Internet-drafts process is to design and standardize new protocols that move the industry forward, not to mire it in outdated toy protocols that place it at risk! There is no documented way for server-end enforcement of secure authentication methods, and no way to provide for *both* user-level and share-level modes. At least two easy MITM attacks make the challenge-response protocol fall, and it can also be dictionary attacked in separate piecemeal DES blocks. Different users with different privileges can wind up sharing a single TCP connection, which violates one of the more traditional [albeit still insecure] ways of holding users apart. CIFS seems to have no provision for fully encrypted sessions, despite the the fact that client and server already share at least one secret key and a few minor enhancements to SMB could provide real session encryption. It is clear that those behind CIFS are still mentally locked into the single user per client model, since the issues raised by multiuser operating systems were evidently never considered. It is almost criminal that other vendors are being forced by market pressure to waste untold development dollars supporting this mess.

Perhaps Microsoft is nonetheless starting to acknowledge that *something* needs to be done to replace the existing mockery of an authentication system. Apparently there is support for Kerberos 5 authentication on the drawing board for NT, if not in alpha by now. As far as I know Microsoft contributed nothing to the Krb5 development effort themselves, so why Krb5? Ostensibly to support DCE, but more realistically because Microsoft can just swipe the MIT code now that it has been well-tested and officially released. It remains to be seen whether this will be a full implementation, with perhaps an NT-based KDC server?? I can't wait to see how badly *that* gets mangled, especially when handling backward compatibility. Naturally some of the first things to rip into will be random number generation and client storage of tickets. Will we finally see some server-end enforcement of authentication types? Will clients implement preauthenticated TGT requests, or be able to perform mutual authentication to exchange keys for encrypted sessions? Not likely, since CIFS seems to imply that Microsoft is banking on the eventual deployment of IPSEC instead. Here again, they take the easy way out instead of actively helping implement secure protocols. It's just as well, really, since if CIFS is any example they would probably screw it up at the standards level and set everyone else back.

Default settings on even the latest NT server is still laughable, as are most of its responses under attack. Okay, so they turned off the NT4.0 GUEST account by default after significant public humiliation, but why stop there? Creating a new fileshare *still* lays it wide open to the "Everyone" group, unless several obscure menu layers are waded through to reset the ACLs. This still does not prevent the "Everyone" group from *deleting* arbitrary files unless yet another service pack has been applied. There is little enforcement for good passwords. All security auditing is still disabled until the administrator turns it on and makes an effort to prevent it from filling up and becoming useless -- and the logging still has little value in the WAN environment. Already there is talk of potentially egregious weaknesses in various interactions like domain password changing and interdomain trust relationships. Microsoft apparently made the ".." mistake in ALL their OS offerings, from WFWG up to the vaunted NT 3.51. It took a lynch mob to convince them to fix it, and it's *still* popping up here and there in other add-on products. And we won't even talk about some of those add-ons, which already have been shown to fall over when lightly tickled, or allow full read/write file access to completely unauthenticated users.

We can and should honestly ask, what *are* they thinking out there in Redmond? Besides the usual complaints about unstable bloatware, we are starting to see a steady stream of stupid, naive ten year old security problems, from weak so-called encryption of .PWL files on up. The answers usually consist of denial and refusing to fix the flaws, and only under tremendous pressure does anything get done. Is this the same vendor we are supposed to trust to produce an operating system and network suite as "secure" as is claimed for NT, especially when it is held forth as a *replacement* for Unix? Are we to lay large amounts of tithe at the feet of the Golden Gates for a complex behemoth that we are repeatedly reassured [read: lied to] is robust under fire, but continues to fall for the same old stupid reasons? The Internet security community is now pushing two decades of finding those little headache-producing bonus gifts that come with major vendor-supplied OSes. One would surely think that a relative newcomer in that arena would take the time to learn from all those well-documented mistakes and make some effort to avoid them, but no, here we go 'round again. This stuff is *not* technically ready for prime time in today's internet, but is being brutally pressed into service for the sake of the bottom line. Common sense screams "run away", and we can easily anticipate another decade of nasty holes that will undoubtedly turn up and be promptly swept under the rug by hordes of marketroids whose jobs are *not* particularly dependent on secure, robust computing environments.

No thank you, I'd rather not go *there* today.

It will be interesting to see if the trade press picks up on any of this. If past experience is any indicator they will simply color the whole issue yellow, denounce Samba as a cracker tool while defending poor widdle abused Microsoft, and as usual not help anyone address the real problems.


By now the reader may be thinking twice before replacing all those Unix servers with NT, and considering the significant risks in yielding to all that marketing rah-rah. In general we now see, in what is hoped to be a clearer way than previously, both how and why to check networks for these additional vulnerabilities. Unix may have its own problems, but overall it is still easier to secure and verify for correctness, and is largely free with all sources included. There are many good people out there proactively finding and fixing Unix problems on a daily basis. And as detailed in this document, Unix still has plenty of fight in it to help kick the NT monster in the ass. The question remaining is, has this document helped at all, or is it just another rework of old information? It began to take shape under the distinct feeling that the research involved *must* have been long since done already, given today's ubiquity of SMB environments, and that it would appear about as timely as discussion of Morris worm holes. But as more sources were scanned, many of the relevant points just didn't seem to be there or were buried as vague hints or hearsay in unrelated discussions. Again, the intent is to simply present this information in a cohesive and useful way, warn against some clear and present risks, and plant seeds to foster future work.

References and acknowledgements

This is an independent research effort of Avian Research, and is presented to the Internet community in the hope that it will be educational and useful. Nearly all the information utilized was obtained via groping around on the internet, and is referenced largely in that context.

Early stages of the project were partially funded by Secure Networks, Inc. of Calgary, CA. They have recently released a greatly enhanced NetBIOS security scanner that embodies many of the concepts described here. Also Samba-based, it is now available via FTP at ftp.secnet.com:/pub/tools/nat10.

Possibly the most instructive document is the CIFS spec, which can be found at www.internic.net:/internet-drafts/draft-heizer-cifs-v1-spec-00.txt. The spec for NetBIOS over TCP is in RFC1001 and RFC1002, available at any RFC repository. Another important source is of course the Samba suite, from nimbus.anu.edu.au:/pub/tridge/samba and numerous mirror sites. The "old- versions" subdirectory thereof should contain version 1.9.15p8 of the code.

Microsoft's "knowledge base" contains lots of fairly good, albeit rather sanitized, information via FTP or the web. The NT articles are summarized in ftp.microsoft.com:/bussys/winnt/kb/index.txt, which is possibly the best starting point. The Microsoft resource kits are another reference source that could possibly have answered more questions, but were unavailable at the time and therefore *not* consulted.

Many security practitioners are collecting information about problems in Microsoft products. The "hack Microsoft" page at www.c2.org:/hackmsoft/ is a good example, as is the information that Somarsoft makes available at www.somarsoft.com:/security.htm and related items. Details about problems in the IIS web server and related things are up for grabs at www.omna.com.

As NT specifically loomed larger as a problem area during data collection, many NT-specific references came to light. It has been VERY difficult to avoid diving down the thousands of potential ratholes involved with closer investigation of NT. An email exchange with Tom Sheldon, initially concerning a reference to Netcat he wanted to add to his book, got us talking. The book is now out: "Windows NT Security Handbook" 680 pages, 0-07-882240-8, $34.99US. Helpful tidbits of information came from this, along with many more from Tom's very informational site at www.ntresearch.com. Several papers, articles, and checklists are available there. Another site that is also beginning to make several NT *tools* [notably NTFSDOS] available is www.ntinternals.com, run by Mark Russinovich and Bryce Cogswell.

The archive of the NT-security mailing list is overwhelmingly HUGE by now, and lives at ftp.iss.net:/pub/lists/ntsecurity-digest.archive/. Nevertheless, the bulk of it was pulled down and at least searched for relevant items if not read outright. ISS also maintains some vulnerability databases and security checklists. The mailing list appears to be useful, and frequently points to other sources on NT security. Here are some of them. They do not all appear to have titles or authors; some are just random web pages that may have more than one maintainer.

An Overview of Windows NT Security, by Jim Frost, May 4, 1995 world.std.com:/~jimf/nt-security.html

A comprehensive collection of pointers to other NT security resources is taking shape at www.it.kth.se/~rom/ntsec.html.

Bill Stout posted a paper comparing NT vs. Unix network security, last seen at www.hidata.com:/guest/whitepapers/NTsec.htm. It may have moved since.

Bruce Schneier should of course be mentioned, whose "Applied Cryptography" presents a very clear picture of using crypto properly. Laurent Joncheray presented his interesting paper on the "desync" TCP attack at the 1995 Usenix Security conference. Random items have been plucked out of various mailing lists like NTSEC and Firewalls along the way, specific references to which were never saved. Those wonderful wackos who maintain www.L0pht.com have been extremely supportive of the ongoing research, and are also starting to make some interesting tools and examples available. Dominique Brezinski at cybersafe.com was helpful in some private mail, and John Hood sent several last-minute edits.

Thanks go out in general to those folks in the Internet security community with that no-bullshit approach, who do not hold back with getting problems out where everyone can help examine and solve them on a timely basis.

Appendix A: Crypto

There are two algorithms used to cryptographically secure the authentication data between a user and a server. The earlier LANMAN-compatible algorithm uppercases the password, truncates or pads to 14 characters as needed, and derives therefrom a pair of odd-parity DES keys to ECB-encrypt a fixed 8-byte quantity described in CIFS as "available from Microsoft upon request" but already well-known to be the decryption of 0xAAD3B435B51404EE with a key of all zeros. The second method is currently supported by NT and Samba, which preserves the case of the password up to 128 bytes, converts it to unicode, and runs the result through MD4. Each algorithm outputs 16 bytes of cryptographic hash that securely represents the user's password. These 16 bytes are called "OWF passwords" from the associated one-way function, and are stored in registries and Samba's alternate "smbpasswd" file. Smbencrypt.c in conjunction with the "libdes" routines handle most of this.

For challenge response, five more nulls are appended to either hash type and the 21 total bytes used as a key triple to DES encrypt the 8-byte challenge into three separate output blocks. The final 24-byte output of this process is sent in the SMB in place of the plaintext password. The password length normally sits at parameter word smb_vwv7 as Samba builds the block, and the buffer area farther along contains the response bytes. Under NT LM dialect there are two password fields -- one for the all-uppercase LANMAN-compatible password or hash thereof and one for the case-sensitive NT-style equivalent. The lengths sit at smb_vwv7 and smb_vwv8 respectively, and the corresponding data buffers are consecutive. NT clients by default fill both buffers with the two types of encrypted 24-byte responses. If told to use plaintext passwords, the NT client only sends a LANMAN password in smb_vwv7 but in *mixed* case.

This is open to more than one easy man-in-the-middle attack. One is even documented in CIFS as the "downgrade attack", wherein a fake server response tells a client to use observable cleartext passwords. Since the fake response packet only needs one changed payload bit and different checksums, this attack is undetectable since a later real response is simply discarded by the TCP transport. A more interesting attack involves taking the cryptkey from one session and network-spoofing it into a victim's later one; the victim's resulting 24-byte response is used to authenticate the first session instead. Here, CIFS makes the cryptographically naive error of letting the client user "sign" the arbitrary data in the cryptkey instead of a hash that includes it.

The application user interfaces in general encourage the historically bad practice for all users to choose the same password across many different machines, even across different NT domains. This is held forth as a single- sign-on model, but standard elements of a real SSO system such as time-limited session credentials never enter the picture at all. The implementation also is in many ways too restrictive for most real-world environments. How does one go about the sounder practice of having separate accounts for separate machines or groups thereof? Some utilities will ask for another password and try again if the cached login password isn't correct for a different server, but this doesn't work everywhere. Example: The NT "net" utility accepts a "/USER:othername" switch when doing a "net use", but not when doing a "net view". Remote registry editing and related tools first try to use the credentials from the console login, and if that doesn't work either ask for an alternate password or simply fail. Sometimes a way to specify a completely alternate login is necessary, but NT's designers seems to have ignored this and not even provided a global "net logon" facility like under WFWG. Often one is forced to create new local accounts and passwords, or use some other band-aid workaround, just to authenticate some underdesigned application to a remote system.

The OWF hashes do not directly reveal a user's plaintext password but if somehow obtained, can be directly used for authentication as well as input to an offline dictionary attack. Directly storing them therefore reduces the security to about the level of burying plaintext passwords inside scripts and thinking "well, the script is hidden, so the password is safe." Microsoft tries to crock around this recognized decades-old problem by re-encrypting the hashes under some *other* key that is often stored in some obscure but nonetheless findable place. Authentication information is also cached in various places such as .PWL files and registry entries, to support the "automatic drive reconnect" stuff. NT apparently also stores information about the last ten domain-level user logons in the registry, for use in cases when the PDC is unreachable.

Since there is no salting in the OWF transform, even the generic old Unix crypt() algorithm is stronger than this scheme. An entire dictionary's worth of passwords and permutations thereof can be *precomputed* and stored, which reduces an OWF dictionary attack to a big database lookup. The block-mode ECB encryption scheme further implies that only the first 8 bytes of the OWF hash really need to be saved; a successful 8-byte match not only brackets a greatly reduced dictionary segment, it directly reveals the first seven characters of a LANMAN-style password. Related to this is that the challenge-response protocol also uses simple ECB of a known plaintext with no chaining or feedback. Response keys derived from the OWF are invariant and can be similarly precomputed. The first stage of an attack on a recorded session setup only requires the cryptkey and the first 8 bytes from both the precomputed response dictionary and the 24-byte response, and DES encryption of a single block determines whether to bother with the remaining two. Again, cracking just the first block can index down to a much smaller chunk of the dictionary. Under NT LM dialect, NT clients usually send *both* response types in the SetupAndX, which again defeats the whole purpose of the NT style password since cracking the plaintext of the reduced keyspace LANMAN password can serve as a template for cracking the user's "real" NT password.

Normally the SAM registry section on an NT server is protected against reading. An adminstrator can nonetheless take ownership of the whole SAM hive, and dump out various subkeys under Domains\Account\Users\{hex-values}. It is fairly clear from diffing ASCII hive dumps that the 32 bytes at the end of the respective "V" binary blocks correspond to OWF password storage. We can observe corresponding changes to at least the same-length fields in the Samba "smbpasswd" file. The 32 bytes represent the LANMAN and NT OWF hashes, but on NT are re-encrypted under some other set of keys. Attempts to find these meta-keys by trying likely-looking DES-size blocks elsewhere around the registry have thus far failed, but the answer may be discoverable with a little more effort. Anyone who already knows the true magic here is of course encouraged to speak up, even if anonymously.

Inter-domain trust relationships are another NT-specific issue and were not studied here, but surely need to be investigated more closely. Various documentation mentions that a "secure channel" is established between domain controllers using the special DOMAIN$ accounts and a some kind of "secret object" which apparently is often derived from a human-chosen password. The channel is apparently an RPC session, but is it truly encrypted, and if so, how? Would this imply that some mechanism for encrypted SMB does exist after all, but for some reason is not made available to the end users? What about backup domain-controller replication, which implies that one machine can suck down the entire SAM database of another? How about an analysis of encryption across PPTP VPNs? Someone else may be able to answer these questions too.

(prev page - top - next page)

Log in or register to write something here or to contact authors.