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.
Conclusions
===========
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)