15.9 Random Notes on Message Authentication Codes

M essage A uthentication C odes (MACs) are used to prevent " pickle -in-the-middle" attacks (more commonly known as " man -in-the-middle" attacks). ^[19] This form of attack is simple to describe, but it can be difficult to pull off in practice (though wireless LAN technology has the potential to make it much easier). Figure 15.7 provides some visuals.

^[19] The latter name though decidedly less Freudian is somewhat gender- biased .

Figure 15.7a. Attempting a man-in-the-middle attack

The evil interloper attempts to interpose itself between the legitimate client and server.

Figure 15.7b. A successful man-in-the-middle attack

If the evil interloper succeeds, the server will not notice that the "real" client is gone. The evil interloper may also try to impersonate the server to the client.

Generally speaking, in the pickle-in-the-middle attack an evil interloper allows the "real" client to authenticate with the server and then assumes ownership of the TCP/IP connection, thus bypassing the whole problem of needing to know the password.

There are a number of ways to hijack the TCP session, but with SMB that step isn't necessary. Instead, the evil interloper can simply impersonate the server to fool the client. For instance, if the evil interloper is on the same IP subnet as both the client and server (a B-mode network) then it can usurp the server's name by responding to broadcast name queries sent by the client faster than the server does. Server identity theft can also be accomplished by " poisoning " the NBNS database (or, possibly, the DNS) that is, by somehow forcing it to swallow false information. A simple way to do that is to register the server's name with the interloper's IP address in the NBNS before the server does (perhaps by registering the name while the server is down for maintenance or something).

In any case, when the client tries to open an SMB session with the server it may wind up talking to the evil interloper instead. The evil interloper will pass the authentication request through to the real server, then pass the challenge back to the client, and then pass the client's response to the server... and that... um... um... um... that looks exactly like pass-through authentication . In fact, the basic difference between pass-through authentication and this type of attack is the ownership of the box that is relaying the authentication. If the crackers control the box, consider it an attack.

This authentication stuff is fun, isn't it?

So, given a situation in which you are concerned about evil interlopers gaining access to your network, you need a mechanism that allows the client and server to prove to one another on an ongoing basis that they are the real client and server. That's what the MACs are supposed to do.

Caveat Emptor Alert

As of this writing, SMB MAC signing is an active area of research for the Samba Team.

The available documentation regarding M essage A uthentication C odes (MACs) disagrees to some extent with empirical results. The information presented in this section is the best currently available, derived from both the documentation and the testing being done by the Samba Team. As such, it is probably (but not necessarily ) very close to reality. Doveryay, no proveryay.

15.9.1 Generating the Session Key

The server and client each generate a special key, known as the Session Key . There are several potential uses for the Session Key, but we will only be looking at its use in MAC signing.

The Session Key is derived from the password hash something that only the client and server should know. There are several hash types available: LM, NTLM, LMv2, and NTLMv2. The hash chosen is probably the most advanced hash that the two systems know they share. So, if the client sent an LM Response but did not send an NTLM Response then the Session Key will be based on the LM Hash. The LM Session Key is calculated as follows :

 char eightnuls[8] = { 0, 0, 0, 0, 0, 0, 0, 0 }; LM_Session_Key = concat( LM_Hash, 8, eightnuls, 8 ); 

That is, take the first eight bytes of the LM Hash and add eight nul bytes to the end for a total of 16 bytes. Note that the resulting Session Key is not the same as the LM Hash itself. As stated earlier, the password hashes can be used to perform all of the authentication functions we have covered so far, so they must be protected as if they were the actual password. Overwriting the last eight bytes of the hash with zeros serves to obfuscate the hash (though this method is rather weak).

A different formula is used if the client did send an NTLM Response. The NTLM Session Key is calculated like so:

 NTLM_Session_Key = MD4( NTLM_Hash ); 

which means that the NTLM Session Key is the MD4 of the MD4 of the Unicode password. The SNIA doc says there's only one MD4, but that would make the NTLM Session Key the same as the NTLM Hash. Andrew Bartlett of the Samba Team says there are two MD4s; the second does a fine job of protecting the password-equivalent NTLM Hash from exposure.

Moving along to LMv2 and NTLMv2, we find that the Session Key recipe is slightly more complex, but it's all stuff we have seen before. We need the following ingredients :

v2hash

The NTLM Version 2 Hash, which we calculated back in Section 15.5.2 on page 279.

hmac

The result of the HMAC_MD5() function using the v2hash as the key and the server challenge plus the blob (or blip) as the input data. The NTLMv2 hmac was calculated in Section 15.5.3 and sent as the first 16 bytes of the response. The LMv2 hmac was calculated in Section 15.5.6.

The LMv2 and NTLMv2 session keys are computed as follows:

 LMv2_Session_Key = HMAC_MD5( v2hash, 16, lmv2_hmac, 16 ); NTLMv2_Session_Key = HMAC_MD5( v2hash, 16, ntlmv2_hmac, 16 ); 

The client is able to generate the Session Key because it knows the password and other required information (because the user entered the required information at the logon prompt). If the server is standalone, it will have the password hash and other required information in its local SAM database, and can generate the Session Key as well. On the other hand, if the server relies upon a Domain Controller for authentication then it won't have the password hash and won't be able to generate the Session Key.

What's a server to do?

As we have already pointed out, the MAC protocol is designed to prevent a situation that looks exactly like pass-through authentication, so a pass-through server simply cannot do MAC signing. A NetLogon-capable server, however, has a special relationship with the Domain Controller. The NetLogon protocol is secured, so the Domain Controller can generate the Session Key and send it to the server. That's how an NT Domain member server gets hold of the Session Key without ever knowing the user's password or password hash.

15.9.2 Sequence Numbers

The client and server each maintain an integer counter which they initialize to zero. Both counters are incremented for every SMB message that's once for a request and once for a reply. As a result, requests always have an even sequence number and replies always have an odd.

The zero-eth message is always a SESSION SETUP ANDX message, but it may not be the first SESSION SETUP ANDX of the session. Recall, from near the beginning of the Authentication section, that the client sometimes uses an anonymous or guest logon to access server information. Watch enough packet captures and you will see that MAC signing doesn't really start until after a real user logon occurs.

Also, it appears from testing that the MAC Signature in the zero-eth message is never checked (and that existing clients send a bogus MAC Signature in the zero-eth packet). That's okay, since the authenticity of the zero-eth message can be verified by the fact that it contains a valid response to the server challenge.

Once the MAC signing has been initialized within a session, all messages are numbered using the same counters and signed using the same Session Key. This is true even if additional SESSION SETUP ANDX exchanges occur.

15.9.3 Calculating the MAC

The MAC itself is calculated using the MD5 function. That's the plain MD5, not HMAC-MD5 and not MD4. The input to the MD5 function consists of three concatenated blocks of data:

• the Session Key,

• the response, and

• the SMB message.

We start by combining the Session Key and the response into a single value known as the MAC Key. For LM, NTLM, and LMv2 the MAC Key is created like so:

 MAC_Key = concat( Session_Key, 16, Response, 24 ); 

The thing to note here is that all of the responses, with the exception of the NTLMv2 Response, are 24 bytes long. So, except for NTLMv2, all auth mechanisms produce a MAC Key that is 40 bytes long. (16 + 24 = 40). Unfortunately, the formula for creating the NTLMv2 MAC Key is not yet known. It is probably similar to the above, however. Possibly identical to the calculation of the LMv2 MAC Key, or possibly the concatenation of the Session Key with the first 28 bytes of the blob.

Okay, now you need to pay careful attention. The last few steps of MAC Signature calculation are a bit fiddly.

1. Start by re-acquainting yourself with the structure of the SMB_HEADER.EXTRA field, as described in Section 11.2.1 on page 181. We are particularly interested in the eight bytes labeled Signature .

2. The sequence number is written as a longword into the first four bytes of the SMB_HEADER.EXTRA.Signature field. The remaining four bytes are zeroed.

3. The MAC Signature is calculated as follows:

    data = concat( MAC_Key, MAC_Key_Len, SMB_Msg, SMB_Msg_Len ); hash = MD5( data ); MAC = head( hash, 8 ); 

   In words: the MAC Signature is the first eight bytes of the MD5 of the MAC_Key plus the entire SMB message.

4. The eight bytes worth of MAC Signature are copied into the SMB_HEADER.EXTRA.Signature field, overwriting the sequence number.

...and that, to the best of our knowledge, is how it's done.

15.9.4 Enabling and Requiring MAC Signing

Windows NT systems offer four registry keys to control the use of SMB MAC signing. The first two manage server behavior, and the others represent client settings.

Server: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters

EnableSecuritySignature

The valid values are zero ( ) and one ( 1 ). If zero, then MAC signing is disabled on the server side. If one, then the server will support MAC signing.

RequireSecuritySignature

The valid values are zero ( ) and one ( 1 ). This parameter is ignored unless MAC signing is enabled via the EnableSecuritySignature parameter. If zero, then MAC signing is optional and will only be used if the client also supports it. If one, then MAC signing is required. If the client does not support MAC signing then authentication will fail.

Client: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters

EnableSecuritySignature

The valid values are zero ( ) and one ( 1 ). If zero, then MAC signing is disabled on the client side. If one, then the client will support MAC signing.

RequireSecuritySignature

The valid values are zero ( ) and one ( 1 ). This parameter is ignored unless MAC signing is enabled via the EnableSecuritySignature parameter. If zero, then MAC signing is optional and will only be used if the server also supports it. If one, then MAC signing is required. If the server does not support MAC signing then authentication will fail.

Study those closely and you may detect some small amount of similarity between the client and server parameter settings. (Well, okay, they are mirror images of one another.) Keep in mind that the client and server must have compatible settings or the SESSION SETUP will fail.

These options are also available under Windows 2000, but are managed using security policy settings. ^[20]

^[20] Jean-Baptiste Marchand has done some digging and reports that starting with Windows 2000 the SMB redirector (rdr) has been redesigned, which may impact which registry keys are fiddled. The preferred way to configure SMB MAC signing in Windows 2000 is to use the Local Security Settings/Group Policy Management Console (whatever that is). Basically, this means that Windows 2000 and Windows XP have MAC signing settings comparable to those in Windows NT, but they are handled in a different way.