ftp.microsoft.com/2002-07-02_ftp.microsoft.com.zip/developr/drg/CIFS/CIFS-Security-Considerations.txt

Text File | 1997-03-25 | 19KB | 493 lines

                  CIFS Security Considerations Update

                             Paul J. Leach

                               Microsoft

                    Preliminary Draft - do not cite

                           Author's draft: 4

This is a preliminary draft of an update to the security considerations
section of the CIFS specification, corresponding to an update to the
security protocols described in companion documents. It is supplied here
as a standalone document for ease of review; if accepted and
implemented, it will be incorporated into a future release of the CIFS
specification. (This specification may change without notice, and should
not be construed as a product commitment from Microsoft Corporation.)


1  Security Considerations

There are four authentication mechanisms, each with their own strengths
and weaknesses, as well as attacks that are independent of the
authentication protocol.

If the CIFS authentication protocol is correctly implemented, then for
all the attacks and weaknesses listed, there are client or server
configurations or other countermeasures to defend against them. At the
highest configurable security setting, with well-chosen passwords, the
best known attack is as hard as attacking DES with chosen plaintext.

This section is for the guidance of implementers, to help them avoid
implementation pitfalls, and for system administrators, to help them
choose a security configuration that meets their installation's security
requirements.


1.1 Security models

There are two security models - share level security and user level
security. Even though the models are different, each model involves
users demonstrating knowledge of a password to gain access, and the
authentication protocols that prove knowledge of the password are the
same for both models.


1.1.1     Share level security

When using share level security, there are no per-user passwords;
instead, knowledge of the read or write password is what gives read or
write access to a share. A session is established by connecting to a
share using the SMB_TREE_CONNECT request, using one of the session
authentication mechanisms described below.

Since the same passwords must be disclosed to many people to be used,
and hence known by many people, while the authentication protocols are


Paul J. Leach, Microsoft  [Page 1]                  03/25/97


Preliminary     CIFS Security ConsiderationsMay change without notice


as strong as for user-level protection, share level security is much
weaker that user level security in practice. This scheme may be
appropriate for small workgroups of trusted/cooperative users, and where
the overhead of managing user accounts is deemed to be too high. The
fewer the number of people who know any given password, the better; this
is especially true for administrative passwords.

Share level protection is at the discretion of the server, and does not
compromise the ability of any other client or server to use stronger
security amongst themselves.


1.1.2     User level security

When using user level security, users authenticate themselves by proving
that they know a password which is known only to that user. A session is
established by connecting to a server using the SMB_SESSION_SETUP_ANDX
request, using one of the session authentication mechanisms described
below. Thereafter, the identity of the user determines the access
allowed to the resources on the server, not knowledge of the password.

As discussed above, user level security is usually preferable to  share
level security. In addition, it can allow access control at a per-
resource granularity, instead of at the granularity of the whole share.


1.2 Attacks on session authentication with plaintext passwords

This authentication protocol sends the client's password in the clear.
It is thus completely open to an eavesdropping attack. If eavesdropping
is not possible, clients can have their passwords stolen by counterfeit
servers. Password guessing attacks are possible, with success dependant
on how well-chosen the passwords are.

Passwords sent to such servers should never be the same as passwords
used for more secure servers.

It should be used only when absolutely needed for backwards
compatibility, and only where the risks of eavesdropping is deemed
acceptable, such as relatively isolated networks or on networks with
secure (encrypted and/or authenticated) link layers.

In general, unless there are very special and well considered reasons,
this protocol should not be used.


1.3 Attacks on session authentication using LM session key

This authentication protocol is more secure than plaintext password
authentication, because passwords are never seen in the clear on the
network.

The following sections analyze the vulnerability of this protocol to
attack using the following techniques:

Paul J. Leach, Microsoft  [Page 2]                  03/25/97


Preliminary     CIFS Security ConsiderationsMay change without notice


o Eavesdropping/ brute force attacks

o Chosen plaintext attack

o Dictionary attacks

These attacks, if successful, compromise the client's password, and
allow the attacker access to the client's files even after the client's
session has ended. Because the same protocol using the NT session key is
stronger, its use is recommended except where backwards compatibility is
required.


     1.3.1     Eavesdropping/ brute force attacks

With the session authentication protocol , an eavesdropper can acquire
challenge/response pairs. It can then test a password by using it to
generate a key, encrypting the challenge, and comparing it to the
corresponding response; by exhaustively trying all possible passwords,
the correct one will eventually be found. This is as hard as finding a
DES key given a known plaintext/cryptext pair.


     1.3.2     Chosen plaintext attacks

With the session authentication protocol, a "man-in-the-middle" or a
counterfeit server can choose the challenge which the client will then
encrypt using a key derived from the client's password. The ability to
choose the plaintext to be encrypted is known to make breaking many
ciphers much easier, and it is possible that it also may help break
cipher-based one-way functions such as the one used to compute the LM
session key.

However, no way to break the DES one-way function used in the session
authentication protocol using chosen plaintext is currently known.


     1.3.3     Dictionary attacks


      1.3.3.1  Online dictionary attacks

If the attacker can eavesdrop, but can not execute a chosen plaintext
attack, then it can test any overheard challenge/response pair against a
list of common words. Such a list is usually much smaller than the total
number of possible passwords. The cost of computing the response for
each password on the list is paid once for each challenge.


      1.3.3.2  Stored dictionary attacks

If the attacker can execute a chosen plaintext attack, the attacker can
compute the session key for many common words and use it to precompute
the response to a challenge of its choice, and store a dictionary of

Paul J. Leach, Microsoft  [Page 3]                  03/25/97


Preliminary     CIFS Security ConsiderationsMay change without notice


(response, password) pairs. Such precomputation can often be done in
parallel on many machines. It can then use the chosen plaintext attack
to acquire a response corresponding to that challenge, and just look up
the password in the dictionary. Even if most passwords are not in the
dictionary, some might be. Since the attacker gets to pick the
challenge, the cost of computing the response for each password on the
list can be amortized over many passwords.

The countermeasure against both these types of dictionary attack is to
require users to choose passwords that are not common words. For the
second type of attack, if the key space derived from passwords is large
enough, then it will be infeasible to store the dictionary.


     1.3.4     Small key space resulting from badly chosen passwords

Even when passwords are not allowed to be common words, the combination
of the use of only uppercase characters, the usual user practice of
choosing passwords that have alpha and perhaps numeric characters, plus
the fact that the LM session key construction treats the upper and lower
halves of the 14 bytes key almost identically means that the key space
may be rather small. Enumerating 7 uppercase characters and digits leads
to a key space of 36**7, or 78.3 billion combinations. When this
mechanism was introduced nearly a decade ago, this was probably an
adequately large key space, but with today's much more powerful systems,
it would now be small enough to make a brute force search expensive but
feasible upon a challenge/response pair obtained via an eavesdropping
attack if the attacker had many powerful hosts available or special
purpose hardware.

The countermeasure to this problem is to require users to choose
passwords that lead to more possible combinations. For example, just
requiring one randomly chosen punctuation character in a password
increases the key space by a factor of 13. If all characters of the
password are chosen at random, there are 68**7, or 6.7 trillion,
combinations. If this is still inadequate, then the NT session key
should be used.


    1.4   Attacks on session authentication using NT session keys

The session authentication protocol using NT session keys is the same as
when using LM session keys; only the key construction is different. As a
result, it may be attacked using the same techniques. However, because
it uses MD4 to generate the keying material from the password, and
because it preserves the password's case, the key space of this protocol
is essentially the full 56 bits that single DES allows; this is probably
an acceptable length for most purposes (although future dialects may use
triple-DES for more assurance). It is still subject to the same chosen
plaintext and dictionary attacks as above, and these will be feasible if
passwords are badly chosen. As above, the countermeasure is to make sure
that passwords are well-chosen, and long enough to have at least 56 bits
of randomness.


Paul J. Leach, Microsoft  [Page 4]                  03/25/97


Preliminary     CIFS Security ConsiderationsMay change without notice


Other considerations:

o Transforming the password into Unicode leaves a pattern of
  alternating zeros and characters in the input to MD4.  It is possible
  that this may allow MD4 to be reversed much more easily, although
  there is currently no known way to exploit this.

o MD4 is known to be weak with respect to collisions, compared to MD5
  and SHA.  It is possible that there may be a way to exploit this to
  attack its one-wayness, or to exploit the collision properties to
  limit key search time, although there is currently no known way to do
  so.


1.5 Other attacks


1.5.1     Connection hijacking

Any attacker that can inject packets into the network that appear to the
server to be coming from a particular client, can hijack that client's
connection. Once a connection is set up and the client has
authenticated, if subsequent packets are not authenticated the attacker
can inject requests to read, write, or delete files to which the client
has access.

Doing so requires that the injected packets have the right transport
level sequence numbers. If the attacker can not eavesdrop, this will
have very low probability of success, since the 32 bit initial sequence
numbers may be randomly chosen. Even if it can eavesdrop, then it needs
"gag" the client, otherwise the client will start getting packets with
bad sequence numbers and reset the connection. This requires that the
attacker is on a host on the same LAN segment as the client or server
and has modified the hosts OS to get direct access to its network card,
or has taken over a router between the client and the server. It is
significantly more difficult to hijack a connection than to eavesdrop,
and doing so only permits the attacker to access files as the client for
the duration of the session. (See RFC 1948.)

The countermeasure against connection hijacking is to configure the
client or server to require the use of message authentication.


1.5.2     Downgrade attacks

If a client is not appropriately configured, a "man-in-the-middle" can
remove the bit in the SMB_COM_NEGPROT response that says the server
supports challenge/response, thus fooling a client into thinking that it
should supply a plaintext password.

The countermeasure against downgrade attacks is to configure the client
or server to require either session or message authentication.



Paul J. Leach, Microsoft  [Page 5]                  03/25/97


Preliminary     CIFS Security ConsiderationsMay change without notice


1.5.3     Rogue servers and spoofing by counterfeit servers

A counterfeit server is one that spoofs the DNS name resolution process
so that the client gets the counterfeit's IP address instead of the
genuine server's IP address, thus fooling the client into connecting to
the counterfeit while believing it is connecting to the genuine server.

A rogue server is a server that entices a client into accessing it, and
uses some aspect of the interaction to try to mount an attack.

Counterfeit and rogue servers are not detectable by the session
authentication mechanism, which only authenticates clients to servers.

If a client is not appropriately configured, a rogue or counterfeit
server can use the downgrade attack above to obtain a client's password.
A counterfeit server can also execute a denial of service attack by
ignoring the client's requests or returning bogus results.

A rogue or counterfeit server can authenticate to a real server as any
client that attempts to log in to it, by getting the client to respond
to the challenge from the real server.

The countermeasure against rogue or counterfeit servers is to require
use of the message authentication protocol., which provides mutual
authentication. Also, such attacks can be mitigated by deployment of
DNSSEC.


1.5.4     Active message modification attacks

If a client or server not appropriately configured, a router or a host
on a LAN segment between the client and server may be able mount an
"active message modification attack": it may be able to modify messages
sent between the client and server.

The countermeasure to such attacks is to use the message authentication
protocol. Active message modification attacks are prevented, because
unless the MAC key is known, tampering with the message will cause the
MAC to fail to validate.


1.5.5     MAC key attacks

The best attack on the MAC key is to attack the session authentication
protocol using one of the techniques above to obtain the password, and
then just compute the MAC key per the specification - which reduces to
brute force search of the key space. (Message authentication is intended
to provide mutual authentication on each message, not increased password
strength.)

The next best attack is a brute force search of the 128 bit key space.
The message authentication protocol does not send the complete output of
the keyed-MD5 hash; only half of it. As a result, it does not expose a
full (plaintext, cryptext) pair to an attacker. This will make discovery

Paul J. Leach, Microsoft  [Page 6]                  03/25/97


Preliminary     CIFS Security ConsiderationsMay change without notice


of the MAC key more difficult, since there should be many potential MAC
keys K' with the property that  it produces the same first 8 bytes of
the hash as the actual key K.  However, if an attacker sees a second
authenticated message, then the chances that K' produces the MACs on
both of them correctly will be 1 in 2**128, so K' is then quite likely
the actual key.

Since the key is formed from both the session key (which is per-user and
long-lived) and the response (which is per-session), large quantities of
data are not hashed using a long-lived key, which might subject it to
attack.

See RFC 1828 for an example of keyed MD5 applied to IP security. If not
used properly, keyed MD5 may have weaknesses as a MAC. Iterative hashes
such as MD5 may be subject to message extension attacks and to
cryptanalysis [Kal 95].  The CIFS MAC construction is not subject to the
problems identified in [Kal 95], because the text contains an explicit
length, which prevents message extension attacks; and because there are
always two iterations of the compression function, and only 64 bits of
the hash are output, which prevents known cryptanalysis techniques.


1.5.6     Replay attacks

An attacker who can eavesdrop and send packets can attempt a replay
attack: resend a request or response previously overheard.

The countermeasure against replay attacks is to use the message
authentication protocol. Replay is prevented, because each request and
response has a unique, strictly increasing sequence number which is
incorporated into the computation of the MAC. (Multi-message requests
and responses all have the same request or response sequence number, but
contain a unique fragment sequence number which prevents replay.)


1.6 Other considerations


1.6.1     Privacy

This version of the CIFS protocol does not support privacy protection.
In order to obtain it, one may use a privacy protecting network layer
protocol (such as IPSec, PPTP, or L2F) or a privacy protecting transport
layer protocol (such as SSL or TLS) to transport CIFS protocol messages.


1.6.2     Performance

The use of message authentication causes the complete contents of each
message to be hashed using MD5, which can decrease performance. Very
high speed implementations of MD5 are available (20 megabytes/sec on a
166 mhz Pentium) that can minimize the impact.



Paul J. Leach, Microsoft  [Page 7]                  03/25/97


Preliminary     CIFS Security ConsiderationsMay change without notice


1.7 Storing Passwords Securely

The passwords used in any of the authentication mechanisms used by this
protocol have to be protected from access from over the network and from
physical access. If the server does not support access control at the
individual file level, but only at the file tree level, then password
files can not be placed in a file tree that is accessible from the
network, as all files in such a tree have to be at least equally
readable.


References

[FIPS 81] DES, FIPS PUB xxx

[RFC 1320] RFC 1320, R. Rivest, The MD4 Message-Digest Algorithm

[RFC 1321] RFC 1321, R. Rivest, The MD5 Message-Digest Algorithm

[RFC 1828] RFC 1828, P. Metzger, W. Simpson, "IP Authentication using
Keyed MD5", August 1995

{Kal 95] B. Kaliski, M.Robshaw,  "Message Authentication with MD5",
CryptoBytes, Sping 1995, RSA Inc,
(http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm)






























Paul J. Leach, Microsoft  [Page 8]                  03/25/97