SharePoint 2013 Security: Authentication Types And On-Premise Pass The Hash (PTH) Attacks
Claims based authentication is a more contemporary authentication technique, whereas Windows based classic authentication has been in place in enterprise systems for years. Traditional approaches to authentication are not flawed. However, they tend to be a single solution for what tends to be a multi-headed problem. To tackle this, it is necessary to have a system that promotes interaction with multiple sources of data, rather than limiting an organization to one. Additionally, it tends to be difficult to adapt legacy identity system if there are changes that requiring modification to the overall system. Multiple sources for authentication are common from a SharePoint architecture perspective. An organization might need both standard Active Directory integration for internal users but could potentially require a lookup to PeopleSoft as a secondary data source as well. While they are both sources of identity information and share a lot of similar user attributes, without claims there is no standard in place to0 ambiguously describe this information.
The amount of solutions to the above identity problem developed over time unfortunately often times desensitizes an architect often from making recognizing correct solution. Although the SharePoint architect has it bad in this situation, it is even worse news for SharePoint developers. A constantly changing API in an environment where identity impersonation and elevation of privileges is a status quo means the possibility of having to constantly change and adapt SharePoint source code.
In order to alleviate some of these problems, it is necessary to decouple the authentication layer into its own security tier. The ideal goal is to extend the authentication possibilities for SharePoint with a heterogeneous concept to identity, letting the system absorb identities securely from multiple sources and environment types. This has several benefits for the SharePoint professional. Firstly, it allows people to focus more on what they are good at. If you are a SharePoint developer, you can focus on producing relevant code. Similar to the how the modular composite control environment that Web Parts provide inherently takes care of most design considerations, authentication to your Web Parts can be naturally implied and manipulated. If you are a SharePoint designer, you can focus on producing the relevant master pages and page layouts, things like images can naturally be placed in because the authentication is taken care of. Regardless of the professional position in relation to the SharePoint environment, the security tools provided in SharePoint 2013 can be outsourced.
From a security and identity perspective arguably the most important SharePoint security concept to understand is claims based identity. A majority of SharePoint 2013 deployments will leverage the claims model, and the authentication processing pipeline in SharePoint is clearer when all pieces are examined. The concept of claims provides decoupling for both the SharePoint administrator as well as the SharePoint developer, providing advanced security tooling that uses familiar concepts.
Before diving into the inner workings of the mixed WIF/SharePoint environment and how contemporary claims authentication techniques will supplement a SharePoint environment, it is helpful to look at the evolution of claims and how they more naturally solves the problem of dealing with identity. Following it becomes a lot clearer on how claims based identity can be applied within a SharePoint environment, and how it can be leveraged to tackle several common business security problems.
One of the primary implementation actions when architecting a SharePoint environment is choosing one, or many, authentication schemes and entry points. This has been relatively consistent throughout the life of the product, outside of SharePoint 2001 and 2003 where Windows authentication was the only supported type. Within SharePoint 2013, the user authentication possibilities are extremely vast, ranging from a simple user directory in a text file to a complex multi-domain environment federated with ADFS.
It’s nearly impossible to touch on every type of system that can be integrated into SharePoint and how their individual attributes have to be accommodated for. However, after demonstrating how claims makes the SharePoint security tier adaptable to all sorts of identity systems, the generalized application should be made apparent.
Consider the SharePoint 2013 claims authentication process from a generic point of view. Our SharePoint user, which will be called the subject, requests access to the SharePoint instance through the built in request provisions built into SharePoint. In a simple environment, in identity terminology SharePoint is using it’s built in features of 2013 to act as the relaying party (RP). The SharePoint environment can potentially know of multiple sources of users, using each of them as identity providers (IPs). The identity provider has a lot of moving parts, such as the directory and the users that belong to that directory. SharePoint provides the accepted means of authenticating to the IP. The IP is responsible for providing information about the requesting user, particular to this identity operation. The information that is returned regarding the requesting users is known as claims.
- A user contacts SharePoint using a web browser. The RP (SharePoint) has its own security policy, and this is provided to the user. In this information are the instructions regarding accepted, trusted IPs.
- The user chooses on the IP that SharePoint trusts. The RP will provide data regarding the required IP security protocols and what claim should be requested from the IP. Following, a request is dispatched to the IP.
- The IP replies by providing its security policy that details its required security protocols.
- The IP examines the request.
- If the IP request passes security measures and data expectations, a security token is sent back to the user to sponsor authentication.
- The security token is received by the user, and the token is passed to SharePoint.
- SharePoint examines the security token, verifies it contains required, accepted, and not altered information (by the user is its signed digital certificate). If everything looks good, the user is granted access.
In essence, a claim can be summed up as an assertions made about a subject. In fact, these pieces of data are often referred to as assertions, both because it is an identity provider asserted a piece of data about a user and because it appears in the popular standards associated with claims authentication. The asserted attributes can be varied, a practical example is login however this could be a social security number, birthdate, or address. The claims model is extremely flexible, it allows you to represent pretty much anything you could want about a user. The claim is exclusive from the user data used to populate it because it is uniquely issued by the identity provider based on the transaction, establishing an additional layer of security. SharePoint is aware that it should trust data that is provided by the identity provider.
Claims have represented a significant investment for Microsoft for some time, several Microsoft products you might already be running make use of it. ADFS is based on claims authentication, as well as Azure. In fact, from a programmatic perspective the default identity object will be based on claims. Claims is not simply a progression that is being worked towards, rather it is already established and running several products. Some of these are used by millions every day, such as Facebook.
The claim is received by SharePoint in the form of a security token. A security token is digitally signed, generally composed of XML or a binary fragment. Since the token is digitally signed and unique, the lineage of the token can be derived, supporting the trust relationship required between the RP and IP.
This digital signature is provided by the WS-Security specification providing cryptographic assertion that the token has not been tampered with. Furthermore, the digital signature prevents token forgery, where a malicious user could counterfeit a security token to gain access to SharePoint.
WS-Security is the protocol that is responsible for describing the security token and how one should be treated. Tokens can take on many forms, however the most common is X.509 certificates, SAML tokens, and regular login/challenge combination tokens. The XML one is easy enough to understand, however the binary fragment one can be a confusing. An example is the previously mentioned binary X.509 security token data. This token data will include a public key that related back to IP that issued it. The public key is used to authenticate with the correlating private key that the communication is truly from a trusted identity provider. X.509 certificates are also distinctive that they have a token signing certificate that has a reserved claim space that verifies the ownership of the public key. In order to prevent forgery of security tokens, some tokens are generally signed with a token signing certificate or associated with a private key, certifying that the messages are from the proper owner. It is important to note that this is not the case with every token type, several do not rely on a private signature or key. SAML for example considers ownership based on custody, on the wire protocols are responsible for securing communication.
SecurityTokenHandlers are the heart of how produced and managed in the identity framework in SharePoint. A SecurityTokenHandler provides the interface that defines custom token handling functionality, several of these are shipped by default with SharePoint 2013 including SAML1.1 handler, a SAML2 handler, and a X509 handler.
Since the security requirements required by SharePoint can vary, it is necessary that a descriptive document be provided dictating what is needed to authenticate and authorize. In identity terminology this is referred to as the policy or security policy, and it is provided by the RP. The IP will also provide its own policy stating directions on how to request a security token. The issued token, assuming security protocols and requirements are satisfied, is provided by the Security Token Service (STS). The STS is potentially the heart of claims authentication, some claims technology do not directly leverage one. For example, consider a high level view of Kerberos authentication. In a Kerberos environment a ticket request is issued for a SharePoint authentication ticket, this is also known as a request for a Ticket Granting Ticket (TGT). The encrypted reply is sent back to the client whom uses it to authenticate with the Ticket Granting Service (TGS) to retrieved session based encrypted credentials. There is an architecture that is setup that handles how one gets the ticket. This is also the case when considering X.509 certificates, which will use the certificate authority when providing the relevant credentials to login to SharePoint.
The shipped SharePoint STS is built on the WS-Trust protocol, which defines the specifications for sending and receiving tokens. A user visiting a SharePoint site in a claims environment will inadvertently send a RequestSecurityToken (RST) to the SharePoint STS. The RST describes the several things, including the token type, the request type, and supporting elements for sponsoring fields such as signatures. The STS will verify that this is indeed a valid request and the user is authenticated, and responds with a RequestSecurityTokenResponse (RSTR). In terms of SharePoint environments, you will encounter RSTR’s when building them to communicate with largely custom partner environments. The RSTR usually contains such information as the current context, response, and the token type requested. The security token and any related keys are returned to the user after authentication occurs, SharePoint is relayed the credentials. After which, the user is considered authenticated. Session, viewstate, and security considerations following this completion of this process are discussed later.
Classic Mode User Authentication
Windows authentication pre-supposes an enterprise authentication system using Windows Domains or Active Directory (AD DS). Windows authentication relies on the various authentication protocols found within the Microsoft Windows environment. There are several Windows authentication methods that can be used with SharePoint 2013. They are offered in both classic mode and claims based authentication. The supported authentication types include:
SharePoint 2013 also supports anonymous authentication, where users don’t have to validate their credentials to access SharePoint. It is not considered part of the Windows authentication family. By default anonymous authentication is disabled.
Anonymous authentication is prevalent when publishing SharePoint content that won’t require security, such as a public SharePoint website.
NTLM is a challenge-response type of authentication, part of the security protocols suite offered by Microsoft Window and supported by the NTLM Security Support Provider (NTLMSSP). NTLMSSP essentially specifies a core set of security functionality in order to support authentication, integrity, and confidentiality services of the CIA triad.
Important core operations specified are detailed in Table 1.1 NTLM Core Operations
Table 1.1 NTLM Core Operations
|Authentication||Challenge-response authentication mechanism|
|Signing||Symmetric signature scheme for digital signature support|
|Sealing||Symmetric signature scheme for provides message confidentiality|
It can be used to authenticate SharePoint users and to provide security for sessions when leveraged by specific application protocols. NTLM authentication consists of three messages which support the challenge-response security architecture as detailed in Table 1.1 NTLM Authentication Messages.
Table 1.1 NTLM Authentication Messages
|Step Number||Common Name||Message Purpose||Description|
|1||Type 1||Negotiation||Type 1 message from client to SP WFE.|
|2||Type 2||Challenge||SP WFE Responds with a Type 2 message. Contains The Challenge.|
|2||Type 3||Authentication||Client Responds with Type 3 message. Includes response to challenge.|
In the Step Number 1, the SharePoint client will send a request to the SharePoint WFE. This request will specify the features supported by both the client and the WFE. In Step Number 2, the WFE will respond by sending the a Type 2 message, that specifies the agreed upon features, as well as the challenge. In Step Number 3, the client responds with a Type 2 message that includes information about the client including the challenge response. From a session perspective, there is a shared context that includes a shared session key that is provided between the WFE and client. This key is used to support future signing and sealing operations.
In less technical terms, a challenge is sent to the client through the WFE. To successfully determine if the supplied password is correct, NTLM will validate the challenge response by checking the Active Directory database or workgroup (peer-to-peer) by recovering the LM/NTLM hashes and comparing them to the respective internal table. The password information will be used to compute a response for the challenge that was given, either grant or deny which subsequently controls access to SharePoint resources.
They are several flavors of NTLM, including LM, NTLMv1, NTLM with session security, and NTLMv2. Each of the handshakes increases with security, respectively. The only means to secure those considered insecure, namely, LM, NTLMv2, and NTLM with session security is to leverage a technology called IPSec. IPSec will be discussed in a future section.
To determine the version being used, the following can be used on the SharePoint WFE.
This setting might be controlled by a Group Policy Object the SharePoint domain Default Domain Controllers policy. The same procedures can be used with the Default Domain Control policy by looking at Security Settings in the Windows Settings of Security Settings instead of the local policy.
For Windows Server 2008 R2:
- Click Start. SelectAll Programs. Expand Administrative Toolsand select Local Security Settings.
For Windows Server 2012:
- In the Server Manager menu bar, click Tools to access the contents of the Administrative Tools folder. Select Local Security Settings.
- Under Security Settings expand Local Policies.
- SelectSecurity Options.
- Right-clickNetwork security: LAN Manager Authentication Level. SelectProperties.
- Under theLocal Security Settingtab there is a drop down that specifies the authentication level. The default setting for this policy is set to Send NTLMv2 response only in a customary Windows environment with default GPO’s. Table 1.1 LAN Manager Authentication Level explains the level differences
A common unsupported LM authentication level error is HTTP 401.1 Unauthorized: Access is denied due to invalid credentials, specifically on Windows 7 client machines. To solve this select the Send LM & NTLM – use NTLMv2 session security if negotiated on the client machine or through GPO for all machines.
Table 1.1 LAN Manager Authentication Level
|Send LM and NTLM Responses||Use LM or NTLM1 only|
|Send LM and NTLM—use NTLMv2 session security if negotiated||Use NTLM2 if negotiated authenticates the user, resolving the user information to generate a token, returning it to SharePoint who processes it for authentication.|
|Send NTLM response only||Use NTLM1 only|
|Send NTLMv2 response only||Use NTLM2 only|
|Send NTLMv2 response only/refuse LM||Domain Controller refuses LM Authentication|
|Send NTLMv2 response only/refuse LM and NTLM||Domain Controller only accepts NTLM2 (refuses LM and NTLM)|
The most commonly set value in SharePoint environments is use NTLMv2 session security if negotiated, especially within Windows 7 environments. The session portion of this should be examined since it is important when understanding typical NTLM attack patterns. The session security of NTLMv2 follows a structured process that can be broken down in steps. The activity begins when an 8-byte client cryptographic nonce is generated representing the server challenge. Nonces are cryptographic protection that prevents attacks by varying with time, it is a number or bit string parameter that is used only once. This a 8-byte nonce is subsequently padded to 24 bytes. This result is placed into the LM ﬁeld of the Type 3 responsewhich represents the final step in authentication.
No LM (LAN Manager) result is generated or passed using NTLMv2 Session. From a SharePoint security perspective this is important since LAN Manager passwords are encrypted using a relatively weak encryption algorithm, among other security issues.
A session nonce is subsequently created be concatenating the server nonce with the client nonce. The session nonce is used against the MD5 cryptographic hash function and truncated down to 8 bytes, producing the a session hash. The NTLM hash is used to create 3 DES keys each used to DES-encrypt the nonce. Lastly, the Type 3 response is generated by concatenating the three cipher text values.
Example PTH attack
From a security guidance perspective it is important to understand why NTLMv2 is always recommended over NTLMv1 and LM network authentication for a SharePoint environment. Due to advances in technology, these relatively antiquated protocols are vulnerable to published attacks for obtaining user credentials.
The most common NTLM attacks are known as pass-the-hash (PTH) attack. A PTH exploits the NTLM handshake by authenticating with the underlying NTLM or LM hash. PTH attacks have been relevant in technology for over 15 years, and are not explicit to a version of SharePoint. The only NTLM version that is not subject to a pass-the-hash attack is NTLMv2 with session security.
The same math used for LM and NTLM changes is used MS-CHAPv2. MS-CHAPv2 or a modified variant is used in for example in Cisco’s LEAP wireless security mechanism, EAP-PEAP and PPTP.
This attack is particularly advantageous because the bulky time constraints associated with brute forcing a password are not relevant, rather the unsalted hashes with the static session are used to authenticate to the service. When authenticating to SharePoint, the password that is typed in is never sent in clear text to the WFE. Rather, in accordance with challenge-response architecture it is presented as the unsalted hash.
There are several ways to get a hash to authenticate to a SharePoint instance. The challenge-response mechanisms of NTLM imply that an attacker can’t simply man-in-the-middle (MITM) or phish the hashes; the chosen challenge would have to be substituted as well. From a specific protocol perspective, this approach would not work unless the target was negotiating NTLM without session security, allowing an attacker to leverage pre-computed tables for reversing cryptographic hash functions. This is also known as a Rainbow Table or Halflmchall table which have no use outside of cracking password hashes. Rainbow tables are relevant in this attack since the hashes are not salted, otherwise this approach would be rendered impractical every bit of salt added doubles storage requirements.
Rainbow tables are a model example of space/time tradeoff in computing. Many people using one table pays up for the cost of building that table, similar to factory programming paradigms.
Previously it the NTLMv2 with session security was examined. To demonstrate this particular attack NTLM authentication will be used, which follows a slightly more rudimentary process than NTLM with session security as demonstrated in Table 1.1 NTLM Response Flow.
Table 1.1 NTLM Response Flow
|1||The 16-byte NTLM hash is generated by applying the MD4 message-digest algorithm to the Unicode mixed-case password. This is null-padded to 21 bytes.|
|2||The 21 byte hash is split into three 7-byte thirds. Each third is used to create three DES keys.|
|3||Three 8-byte cipher-text values result from DES encrypting the challenge with these keys.|
|4||The NTLM response is returned by concatenating the values in a 24 byte value.|
From a high-level, this explanatory compromise will skip the pre-chosen challenge and brute force the challenge response to get the NTLM hash as illustrated in Table 1.1 PTH in Motion and Figure 1.1 PTH in Motion. The goal is to reverse the challenge response by brute forcing two 56 bit keys DES iterations and one that only uses 2 bytes of the 56 bit key space.
Figure 1.1 PTH in Motion
Table 1.1 PTH in Motion
|1||Client connects to SharePoint WFE|
|2||Capture a challenge-response pairs using Ettercap|
|3||Attacker returns the LMv1/NTLMv1 Challenge/Response in .lc Format|
|4||Concatenate the challenge into respective assignments.|
|5||Use on premise or SaaS cracking solution|
As of the release of Vista Microsoft has changed the default to NLTMv2, while LM and NTLM are available as options to use. The important takeaway from this attack is the password is not necessarily required in order to authenticate to a service such as SharePoint since the hash can similarly be used.
A portion of the HTTP 1.0 specs includes the specification for the Basic Access Authentication scheme. The Basic Authentication scheme is an industry-standard method for collecting user name and password information. The credential information that is collected from the user is transmitted in unencrypted base64-encoded passwords across the network. Base 64 encoding provides no value in terms of security encryption; it’s simply a way of representing binary data using only printable characters.
The connection should be established either over a dedicated line or by using Secure Sockets Layer (SSL) encryption and Transport Layer Security (TLS). You should use Basic authentication only when you know that the connection between the client and the server is secure.
Basic authentication is very sparsely used with SharePoint deployments because it finds greatest utility when it is unknown whether the client browser will support Windows authentication and or the authentication is passed through a proxy. At the time of this writing, most popular browsers even obscure ones such as Chrome for Android are supported. The proxy benefit is while NTLM can get past a firewall, it is generally stopped by proxies because NTLM is connection-based, and proxies do not necessarily keep connections established.
One of the more abstract reasons that Basic Authentication is found within enterprise SharePoint environments is Cross Origin Resource Sharing (CORS). CORS is the meant to provide the ability to execute asynchronous HTTP requests across domains, and is a browser dependent feature. Example CORS utility is when a peripheral SharePoint site requires to pull business information, such as list data, from a cross-domain SharePoint site.
If both NTLM and Basic authentication are configured for the published SharePoint site the request will attempt to use NTLM first and Basic following.l
Essentially, digest authentication offers the same functions as basic authentication however offers more security than basic authentication. The credentials of the user are encrypted instead of plaintext format. The credentials are sent as an MD5 message so that the username and password can’t be identified. Digest authentication also uses the challenge/response protocol. This means the authentication requester has to provide valid credentials so that the challenge from the server can be responded to. The client must supply the MD5 message digest with a response that is shared in the string for the secret password.
With Windows Server 2003, digest authentication is implanted as a SSP and DDL for supplying the operating system with additional security. The SSP that will be used varies, based upon the abilities of the computer on the other side for the connection. It also varies based on the preferences of the individual application which is being used.
SSPI is the foundation for authentication in Windows Server 2003. Any time that the infrastructure and application require authentication, it will be done by SSPI. The GSSAPI (Generic Security Service API) is implemented by SSPI in Windows Server 2003. RFC 2743 and RFC 2744 in the EITF RFC database offer additional information.
All of the defaults in SSPI for Windows Server 2003 are incorporated in the SSPI ad DLLS. This includes:
- Digest authentication
There is an mechanism offered by SSPI in Windows Server 2003 that carries authentication tokens between communication channels of the server and the client. If there are two parties that must be authenticated in order to communicate, then the requests are routed to the SSPI. The authentication process is completed and it doesn’t matter what the network protocol is that is being used.
The SPPI is able to return large objects that are passed between applications. They can be passed to the SSPI layer on that particular side. With the use of SSPI, it is possible for an application to use different security models within a network. It isn’t necessary to change the interface to match a particular security system.
The implementation occurs through wdigest.dll for Digest SSP. This is one of the authentication protocols used for various applications including HTTP and LDAP. The following are the steps involved with processing for digest authentication:
#1 – The server receives a request from the client to access a resource that is protected.
#2 – The server recognizes the request for information or service, and that authentication is necessary. The server will check if the client has provided the proper information for authentication. It won’t find any the first time that they request so the HTTP www-authenticate header is sent to the client. The header will include:
- Domain for the server to supply the credentials
- Information to determine if authentication is required
- Server side data including URI, HTML tag and time stamp
- Hints about the context of security
- Ciphers that are supported by the server
- The encryption algorithm that will be used by the authentication protocol
A 401 message code is returned that indicates the client has requested access and that there is an unauthorized user error created.
#3 – The client will get a challenge from the server that has the required credentials. This is accomplished by accessing information from credentials already in place or by prompting the user to enter them. The challenge has to mesh with the secret key, and the following parts have to be included:
- Original identification of the users secret key as proof of the users password
- Domain name
- Time stamp
- Confidentiality, integrity, and authentication information
- Algorithms that are used will be specified
#4 – The message is received by the server and there are the following checks in place to verify the authentication process:
- The challenge response is issued by the server and not an outside resource
- The challenge response has been formatted properly to follow the options that are validated by the server
- The number hasn’t been previously used for a challenge response to ensure replay attacks don’t occur
All of the checks have to pass or the server won’t authenticate the request.
When the responses meet the criteria of the server, the domain controller gets a response in order for authentication to be completed. Digest SSP verifies if the digest authentication response has been validated and that there aren’t restrictions such as an expired password that occurred.
Once these checks are completed, the server is notified that the client is authentic from the domain controller. The server of origination will also get a digest authentication session key. This is cached to assist with authentication requests in the future. It will generate an error message if the check fails.
The claims based identify management system provided by Windows Identity Foundation provides robust mechanisms for forms-based authentication. It can be used with credentials that have been stored in any of the following data sources:
- AD DS
- Lightweight Directory Access Protocol (LDAP)
- SQL server database
This type of validation allows users to gain access based on user provided credentials. There is a logon format that is used to collect the credentials, a majority of the time this is a web page. The user has to provide credentials that are verified once the form is submitted. A keyed cookie used to authenticate and identity future requests.
The user account has credentials that are sent in a plain text format. It isn’t recommended to use forms based authentication unless you also have SSL in place to encrypt the traffic for the SharePoint website.