Authentication to shared folders using SMB protocol

The use of authentication mechanisms to access shared folders depends on the supported version SMB protocol and supported operating system mechanisms. This is a continuation of the article on File sharing on Windows networks.

Overview of authentication methods for accessing storage using SMB protocol

The choice of possible data sharing technologies in the Windows network environment is very closely related to logging in and the login mechanisms used. If sharing technology is chosen, more precisely the version used sharing, it is necessary to consider which login technologies will be used. Some of these technologies they are no longer safe enough, some of them are critically weak. Table shown here shows which systems supported which login methods. To highlight the weaknesses of these mechanisms, a full development including ancient history is given. It is important to remember that mechanisms dating back nearly half a century cannot stand up today and are a reliable way into the system for attackers.

Assessment of the supported methods against each version of the protocols

As you can see, some methods are relatively old and fortunately started to be abandoned. As a rule security problems and developments in the field of cryptography were the cause. Next will be described the individual algorithms, their own development and features. Algorithms such as SAML, Microsoft Account, Microsoft Hello will be purposely omitted in this article because they cannot be directly used for access to shared folders. As a rule, they are used for other services and access control is mediated by NTLMv2 or Kerberos mechanisms. In general, therefore, on the basis of the available information, it is possible to say about support for authentication mechanisms approximately as follows.

LANMAN mechanism

One of the oldest methods for authenticating users on the network is LANMAN. This method used the encryption algorithm DES, which was among the best algorithms at the time. Unfortunately, it also created one of the great weaknesses that the algorithm has. In the example of this algorithm, it is necessary to distinguish between the LMHash cryptographic mechanism and the authentication method LANMAN. The actual authentication method has gone through a long development and is no longer recommended since Windows NT 4.0. The versions were:

Authentization:
Negotiate (Client –> Server): Send U=Username
Challenge (Server –> Client): Send C=Challenge
Authenticate (Client –> Server): Send Encrypted DES(Key=LMhash, C)

Among the biggest weaknesses of the authentication scheme:

• Too short challenge.
• Missing salt (e.g. user challenge), ensuring that passwords are distinguished between users.
• Not protected against relay attack.
• Not protected against replay attack, only the challenge provided by the server creates partial protection.
• Missing two-way authentication.
• Not protected against MITM attack.
• Not supported by MFA.

The LMhash function itself, which is used in the authentication method, has the following problems:

• The user password is the key for the DES algorithm. Because DES has a 56b rather than a 64b password, the user input is always 7B/56b instead of 8B or 14B/112b instead of 16B. The eighth password byte for DES is always empty (0x00).
• A password longer than 14 characters is not possible, it is not supported by the algorithm.
• The password may contain some special characters, numbers, space and uppercase letters. Lowercase letters are converted to uppercase. This means 26 characters (A-Z), 10 digits (0-9) and 10 special characters. In total, it is possible to achieve a maximum of 78b entropy of the input for a 14 character password. This corresponds to approximately a 10 character password with no specified input range limitations.
• A password shorter than 8 characters can be attacked and the original input counted, or the passwords can be split into pairs of 8B outputs and the password values counted.
• For passwords with a length of 8 or more characters, rainbow tables (Rainbow table) can be used. It is also possible to use them for shorter passwords.
• The algorithm is not unidirectional and allows the user's original password to be counted as well.

Mechanism of NTLMv1

The NTLMv1 algorithm (originally only NTLM) was designed to replace the original and weak LANMAN algorithm for authentication. He had many bugs and the effort was to replace the DES algorithm along with the reversible encrypt with a one-way hash function and remove the biggest drawbacks of this login method. Z for this reason the NTLM algorithm was developed, which unfortunately took over most of the maladies from the original mechanism. A significant advantage was the extension of the password, unfortunately there was still no protection against some types of attacks. The result of the hash function is 128b output, which with an extension of 5 zero bytes becomes 168b block. This can be divided into 3x56b, the size corresponding to the key material for DES. The actual authentication algorithm behaves almost the same and has the same errors as the algorithm LANMAN.

Negotiate (Client –> Server): Send U=Username
Challenge (Server –> Client): Send CS=Challenge (8B Server challenge)
K1 || 0x00 || K2 || 0x00 || K3 || 0x00, 0x00, 0x00 = NTLM-Hash
RC = DES(K1,SC) || DES(K2,SC) || DES(K3,SC)
Authenticate (Client –> Server): Send RC

Core of the NTLMhash authentization mechanism can be described as:
NTLMhash=MD4(UTF-16-LE(password))

• Too short a challenge.
• Missing salt (e.g. a user challenge), ensuring that passwords are distinguished from each user.
• Does not have protection against relay attack.
• Does not have protection against replay attack, only the challenge provided by the server (PtH - pass the hash) creates partial protection.
• Missing two-way authentication.
• Does not have protection against MITM attack.
• Does not support MFA.

The NTLMv2 mechanism

Only NTLMv2 solved some of the problems with the original mechanisms. Unfortunately, it appeared at the time when the MD5 attacks came on the scene. While the MD5-based HMAC function has not yet been breached, on the other hand, it was clear that this procedure was just a re-usability. Yet to this day, the mechanism is one of the basic authentication schemes, and if no other method authentication is available, the procedure is the only one.

Among the biggest weaknesses of the authentication scheme:

• Too short challenge.
• Has no protection against relay attack.
• Has no protection against replay attack, only provided by the server (PtH - pass the hash)
• No two-way authentication.
• Has no protection against MITM attack.
• Not enough MFA support
  

Negotiate (Client –> Server): Send U=Username
Challenge (Server –> Client): Send CS=Challenge (8B Server challenge)
CC = 8-byte client challenge, random
CT = (version, time, CC, domain name)
NTLMv2hash = HMAC-MD5(NTLMhash, User Name||Domain Name)
LMv2 = HMAC-MD5(NTLMv2hash, SC, CC)
NTv2 = HMAC-MD5(NTLMv2hash, SC, CT)
RC = LMv2 || CC || NTv2 || CT
Authenticate (Client –> Server): Send RC

The actual kernel of the authentication mechanism again relies on the original NTLMhash algorithm, which is modified with an additional layer of protection. This is solved thanks to HMAC-MD5, and to ensure the relationship between the password and the user account, the information is linked. There is also a simple form of replay attack protection with the help of a timestamp.
NTLMv2hash=HMAC-MD5(NTLMhash, user name||domain name)
Long description:
NTLMv2hash=MD5(MD4(UTF-16-LE(password)) ⊕ 0x5c5c..5c,
                  MD5(MD4(UTF-16-LE(password)) ⊕ 0x3636..36,username||domain name))

Arrival of Active Directory and Kerberos mechanism

The history of the Kerberos protocol began in 1983 as an internal MIT authentication project. First three versions were used only internally. Subsequently within the project Athena [7] Version 4 was created. Written by Steve Miller and Clifford Neuman, it was released on January 24, 1989. Due to export restrictions were not It is possible to use the DES algorithm and therefore other versions have been created abroad. One of them was by Eric Young and was created in Australia, the second was created in Sweden (KTH-KRB). The end of the aid was announced in 2006 the DES algorithm and thus the Kerberos v4 support was terminated. In 1993 Kerberos v5 was released, the authors of which were again Clifford Neman and with him John Kohl. Its expansion in 2005 removed support for the DES algorithm, RC4-HMAC-EXP and other vulnerable algorithms, on the other hand, added support for the AES algorithm. Currently the development is overarching consortium Kerberos [8] and MIT Kerberos consortium [9].
Kerberos was a completely new approach to the system authentication problem that was first used in the Active Directory of Windows 2000. More specifically, Microsoft first used it here. It is practically an implementation of Kerberos 5 with some limitations that are given by the supported cryptographic algorithms. In addition to explaining how this protocol works it is important to specify exactly how the Kerberos protocol uses certain settings and specific sets of cryptographic protocols in the Microsoft Windows environment. The basic description is quite simple. As part of the authentication process, the user identifies the authentication service (AS – Authentication Server). Because both the user and the authentication service know the credentials, the server creates a service key (token) for (TGS – Ticket Granting Server), encrypted using the client's secret key (password or password-derived credential). Based on this key, the user can decrypt important data that will allow him to communicate with TGS. This in turn assigns a ticket for authentication between the client and the server and provides information important for the collaboration. For an idea of how this protocol works, it is advisable to go through the different communication steps, the source files of the network communication can be downloaded on the Wireshark website, Kerberos section [10].

Communication between participants takes place over the UDP/88 and TCP/88 ports. Among the biggest weaknesses of the authentication scheme are:

• Weak, not recommended today algorithms to ensure message integrity - CRC32, MD5, SHA1.
• Weak, not recommended today algorithms to ensure message confidentiality - DES, 3DES, RC2, RC4.
• Export version of algorithms with targeted weakened mechanisms (40b password, cropped outputs of hash functions).
• Possibility of password hash misuse:
  • PtH - pass the hash
  • Oth - Overpass the hash
  • PtT - Pass the Ticket
  • PtC - Pass the Cache)
• No mutual authentication.
• No protection against MITM attack.
• Insufficient MFA support.

Important information:

• AS - Authentication Service is a service that is part of the KDC. In the case of Active Directory is a DC (Domain Controller). This is the first head of Kerber.
• TGS - Ticket Granting Service is a service used for allocating a ticket. Practically the second head of Cerberus.
• AP - Application Server or just a server, offers a service requested by the user. It is the third head of Kerber.
• KDC - Key Distribution Center, contains AS and TGS.
• PAC - Privilege Attribute Certificate ke structure used in almost every ticket and is signed using KDC key.
• TGT - Ticket Granting Ticket is a ticket that is shown to the KDC to obtain information from TGS. TGT is encrypted using KDC key.

• User key (K_C, Key_Client) - in the case of Active Directory is derived from NTLM hash or it is a NTLM hash.
• TGS key (K_TGS, Key_{Ticket Grantig Service}) - also KDC or krbtgt key (account krbtgt), in the case of Active Directory it is derived from the NTLM hash of the account (user or service).
• AP key (K_AP, Key_{APplication server}) - key of service, service account or machine, is derived from the NTLM hash or it is directly a NTLM hash.
• KTS key / session key (K_TS, Key_{Ticket Session}) - is randomly generated by TGS and indicates is like Session Key.
• KSS key / service session key (K_SS, Key_{Service Session}) - is generated based on timestamps. In most documents it is referred to as K_CS or Service Session Key

Breakdown of exchanged messages:

If the default setting is used, i.e. the communication encryption policy is not set, the RC4-HMAC algorithm is used, otherwise also RC4-HMAC-MD5. This is not entirely true, at the beginning the DES algorithms were used. For Kerberos communication this can be seen, for example, in Wireshark when analysing the communication according to the value of etype 23, in case of export to a text form, usually according to the initial string "23/0x17h". Note for the margin, DES used the etype values "1/0x01h" and "3/0x03h". Under this condition, the NTLMhash of the user password is used as the key for encryption. This also poses a problem, mainly due to attacks on RC4, which can now be broken in an interval of around 12sec. Furthermore, since no password generator, salt or nonce is used here, the authentication process thanks to this takes place in an extremely unfortunate way with the possibility of obtaining user passwords.

If the encryption policy is set, but other conditions are not met (i.e. not Forest Level at least at the Active Directory version 2012 level and users are not in the corresponding user security group "Protected Users"), although encryption occurs using the AES algorithm, it is still used as NTLMhash password. In these cases, the ticket identifier "17/0x11h" or "18/0x12h" is used, but it is not possible to distinguish the quality and unpredictability of the key material without further analysis.

If an encryption policy is set and conditions are met (functional Forest Level at least at the Active Directory version 2012 level and users are in the security group "Protected Users"), encryption occurs using the AES algorithm and the key material is derived from NTLMhash and other information. For generation, the KDF function is used (PBKDF2 according to RFC 3962, section 4), which allows the creation of a pseudo-random and unpredictable key material for token encryption. This ensures higher security. These tokens can have values of "17/0x11h", "18/0x12h", "19/0x13h" or "20/0x14h". Within the key material derivation, the NTLMhash is still used as a passphrase, which allows a temporary key to be derived using PBKDF2. The hash function is used on older systems usually HMAC-SHA1, on newer systems HMAC-SHA2. The number of iterations of the algorithm is set to 32768 iterations, fortunately this value can be changed (increased). The value of keylenght varies according to the use of AES-128 (128b) and AES-256 (256b).

tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
key = DK(tkey, "kerberos")

The last option currently available is to set an encryption policy and meet extended conditions (functional Forest Level at least at Active Directory version 2019 level, users are in the security group "Protected Users" and KDF2 is selected to generate random key material). In this case, encryption occurs using the AES algorithm and the key material is derived from NTLMhash and other information, using the KDF2 [6] function for generation. This allows to create a pseudo-random and unpredictable key material for token encryption with a newer approach, based on the IEEE Std 1363-2000, ANSI X9.42 (KDF1) and ISO 18033-2 (KDF2) standards. These tokens may have values for the encryption sets "17/0x11h", "18/0x12h", "19/0x13h" or "20/0x14h". Derivation of the key material still uses the NTLMhash value, which allows KDF2 to derive a temporary key. HMAC-SHA2 is used as the hash of the function. The number of iterations of the algorithm is set to 32768 iterations, this value can be changed as in the previous case. The value of the keylenght varies according to the use of AES-128 (128b) and AES-256 (256b).

KDF2 Enabling:
Set-AdfsProperties -KdfV2Support enable

KDF2 Function Description:
KDF2=hash(input||I2OSP(1,4))||...||hash(input||I2OSP(k,4))
where
k=[l/output length of the hash function]

I2OSP Function Description
I2OSP is the Integer to Octet String Conversion Primitive (Victor Shoup, I2OSP[6]). In this case a 4B value is selected from the input text (l=4), which is treated as a number and then treated as a number. KDF2 creates a series of values extending the input.

Overview of existing and supported cryptographic algorithms in Active Directory, Kerberos protocol. Support labeled Yes^D (Decomissioned) means that the algorithm is obsolete and unsatisfactory, usually it must be turned on manually. The availability of such a protocol is for compatibility purposes only. The process of changing the settings is very well described e.g. on the Samurai [11].

Note: Yes^D (decomissioned) means to designate a mechanism as a rundown and may need to be separately enabled.

Configuring krb5.conf in Linux

In the case of a kerberos client in networks where the AD controller is not yet on Windows 2019, but is configured accordingly, it is possible to use a configuration supporting at least a weakened implementation using AES. The krb5.conf file can then contain:

[libdefaults]
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
allow_weak_crypto = false

If the AD controller is on Windows 2019+ and is configured accordingly, it is possible to use AES configuration in all forms. The krb5.conf file can then contain:

[libdefaults]
default_tkt_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
default_tgs_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
allow_weak_crypto = false

Finally, if there are no legacy systems in the network other than Windows 11 and Windows 2019, the system has adequately configured security policies, perhaps the most sensible solution is to set up the system to use sufficiently resilient implementations of AES-based encryption sets. The krb5.conf file can then contain:

[libdefaults]
default_tkt_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
default_tgs_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
allow_weak_crypto = false

The krb5.conf file contains encryption sets by default:
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4

Conclusion

There is currently no point in using old authentication mechanisms such as LANMAN and NTLMv1. These mechanisms are not capable of guaranteeing protection and also represent a significant complication for system security efforts. If these mechanisms are used to access shared folders, then these mechanisms are capable of ensuring user authentication only on decades-old protocols.
Current mechanisms such as Kerberos and NTLMv2 (in cases where it is not possible to use Kerberos) can be used to access files if the right settings are in place. Although systems now offer other forms of authentication such as Hello, SAML or Microsoft Account, these cannot be used for local authentication on the network. Always vicariously use the mechanisms already mentioned.

Autor článku:

Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.