Classifying SharePoint Threats

SharePoint threats come in many forms; however it is most important to remember that SharePoint is merely an ASP.NET application, and thus subject to all if not most of the same core vulnerabilities that affect its baseline components. All of the layers that make SharePoint function as a product such as SQL server and IIS are subject to vulnerabilities. This leads to a fair amount of threats being considered practical against a SharePoint environment because the technology gap is so large. As a result, one of the greatest skills that can be mastered is differentiating between what is a practical threat, what is considered to be a threat, and what should actually be ignored. Before looking at SharePoint through the eyes of someone positioned with an attack in mind, it is helpful to be able to understand that the toolkit being used. While this sounds simple enough, there is thousands of security vulnerabilities released every year, lots are not even used by attackers and fewer are actually used in a matter that can cause harm to an organization. In order to have a relevant security process defined, it is necessary to be able to filter out the information overflow that this leads to. Managing, validating, and acting upon every vulnerability release is simply not practical.

Filtering large queues of threats requires a simple, yet often not implemented method of triaging vulnerabilities as they are made known. Building this process can optionally use measurable units such as the scoring methods such as those that are provided by Common Vulnerability Scoring System (CVSS). The end result of this is to adapt the SharePoint security platform and related security policies in a manner with a clear course of action in the least amount of time.

There is generally a reasonable period of time between when a security vulnerability is released and when the exploit becomes available. Furthermore, knowing how to use a prewritten exploit is much different than knowing how to write an exploit. Most Microsoft vulnerabilities that you will encounter can be remedied before an attack can even be presented. This is known as attack latency, the time period between when a security hole is known, and when those that are looking to take advantage of the vulnerability are still looking to take advantage of the exploit. Similarly to how technology is becoming more complex, the attack latency is getting smaller year by year. Those responsible for the security of the collaboration infrastructure at a company are required to mitigate threats with no warning. As new threats are introduced organizations must evolve the SharePoint and security infrastructure in a way that adapts organically with vulnerability creativity. Most importantly, the procedures that are used to both remediate and back out potentially malicious changes must also evolve in kind. When considering all of the effected factors, the reason why it is not practical to address each and every vulnerability becomes clearer. In essence, it controls rapid, uncontrolled changes, preventing possible overreaction. Adapting this will lessen desensitization to actual urgency required for particular vulnerabilities as they arise.

Before understanding how a vulnerability should be triaged, it is helpful to understand how a vulnerability is constructed, and how they are leveraged. Knowing the tools and approaches that possible attacker is going to take will ensure that the proper corrective actions are taken. To demonstrate this I am going to use an old exploit that was present in past versions of SharePoint which has since been resolved. This exploit will allow an attacker to dup arbitrary files directly on the file system under the system account privileges.

There are several means that developers used in order to take advantage of exploits, but most commonly exploits are written against the Metasploit framework.

To implement proper triage of vulnerabilities, there are a few simple steps that should be used. Firstly, the vulnerability will have to fall into a category of urgency, and this must be applied to all member servers in the SharePoint environment. Meaning, this must happen at the web front ends, all related application servers, as well as the database layer. If there are other Microsoft platforms that use SharePoint services, it is wise to include them in the same process. Determine the level of urgency by asking yourself a simple question, does the vulnerability pose a potential security risk, a likely risk, or an imminent risk to the organization?

If you find that the vulnerability poses either a likely or imminent risk, before taking action ensure several parameters. Firstly, are you running the afflicted version of SharePoint and associated components? If the answer is yes, then it means then an attack has potential to get legs. Therefore, it is necessary to see firstly if there is already a workaround implemented that tackles this issue, the attack likelihood, and potential remediation plan.

At this point, there should be an appropriate predefined response process that is already defined at the organization. This may include many actions, however most commonly involves contacting a representative at the vendor for further information about the threat, whether a workaround is available, and whether an automated patch is being built that will otherwise perform the workaround.


SharePoint 2013 Security: Authentication Types And On-Premise Pass The Hash (PTH) Attacks

Claims-Based Authentication

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

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:

  • Basic
  • Digest
  • Kerberos
  • NTLM

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 Authentication

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

Operation Description
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:

  1. Click Start. SelectAll Programs. Expand Administrative Toolsand select Local Security Settings.


For Windows Server 2012:

  1. In the Server Manager menu bar, click Tools to access the contents of the Administrative Tools folder. Select Local Security Settings.
  2. Under Security Settings expand Local Policies.
  3. SelectSecurity Options.
  4. Right-clickNetwork security: LAN Manager Authentication Level. SelectProperties.
  5. 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

Selection Explanation
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 field 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

Step Descriptions
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

Step Action
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.

Basic Authentication

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

Digest Authentication

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
  • Kerberos
  • NTLM
  • Shannel

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
  • Username
  • Time stamp
  • URI
  • 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.

Forms-Based Authentication

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.


Office 365 Security Series Primer

Collaborative technology has a unique way of exposing security flaws owing to the sheer everyday enterprise user consumption and the potential value of sensitive or propriety business information to an attacker. The security strategy that a SharePoint architect implements has to remain fluid, graceful and expressive in order to compensate for continuous technology changes. SharePoint as a distributed system combines various resources, progressively growing by provisioning on-demand solutions for the enterprise. In order to maintain uninterrupted and secure operations, proper security services must be implemented since SharePoint is subject to the same threats as other software that operates in the open Internet and networking environment. To increase the overall enterprise SharePoint security posture it is necessary that better security properties ranging from strong authentication and to adaptive content governance be implemented.

This threat landscape is also shifting as SharePoint offers entry for different types of devices and technology, such as mobile devices. Every environment that becomes SharePoint supported introduces new security needs, requirements, and difficulties.  Collaborative organizations and technologies indeed face numerous challenges in the field of security.

As can be evidenced with the new features added to the most recent version of SharePoint the collaborative technology industry is leaning to an IT concept known as consumerization. More enterprise users are experiencing technology innovations in areas such as social media before the technology, and even its baseline concepts, are available and supported by an enterprise. As a result, technology requirements within an organization are becoming more driven by employees, rather than strategic infrastructure decisions made by characteristic IT stakeholders.

The most evident example of this is enterprise users are increasingly demanding a collaborative infrastructure where both a personal and work life can be managed from one point. Utilizing social networking technology skills gained outside the organization this is considered excellent from an organization perspective, since it leads to better business information sharing, more effectual decision-making, and enriched business relationships. However, with the good comes some bad. While there are well-defined benefits of some of these innovation integrations, several security risks such as unauthorized, unmonitored, and uncontrolled use can increase the IT and business risks in areas such as confidentiality of intellectual property and business information.

Exploring the explosion of enterprise in interest in collaboration and social shared tools provide an attacker different avenues than previously available to harvest valuable business information due to the enhanced social features. There were several social tools built into the 2010 revision of SharePoint, but they have been increasingly refined in the recent release. Even lacking technical ability, often times finding valuable information can simply be time and patience since it might be casually and carelessly distributed. This type of data varies, however can tamper with company operations and expose or steal sensitive information. Collaboration and social sharing tools open up new avenues for an attacker to steal propriety or confidential business information or disrupt business operations. Social messages surfaced in SharePoint can be inadvertently used in order to spread malware more effectively and additionally through more multiple devices. Sensitive business information can be accidently disclosed between businesses connections since due to the tight restrictions generally placed on internal data being loosened in favor of the openness of the social media world. Controlling the security mechanisms that drive social sharing tooling is also an issue. A majority of these services are provisioned outside of an enterprises control, therefore compensation to govern these has to be adapted within the enterprise.

The concept of consumerization has also pushed the boundaries of normal collaboration to a readily increasing concept known as borderless collaboration. SharePoint is especially common in this arena as the mechanisms to quickly stand up externally facing environments that respects various security integration are relatively well-known. While extending collaboration can procure additional benefits, such as something as simple as increasing communication levels with business partners and customers, it also introduces new challenges. Various security tasks exist, ranging from simple tasks like whom should have access to what within SharePoint to how should user business information be kept confidential.  The most important benefit of a borderless collaboration initiative is to solve the challenges of an increasingly mobile, collaborative and virtual workforce.

SharePoint security threats come in many forms. However it is important to remember that SharePoint is merely an ASP.NET application, and thus subject to all if not most of the same core vulnerabilities that affect its baseline components. All of the layers that make SharePoint a functional software product, such as SQL server and IIS are subject to distinct vulnerabilities. This leads to a fair amount of threats being considered practical against a SharePoint environment, the platform technology volume is so large. As a result, one of the greatest skills that can be mastered is differentiating between what is a practical threat, what is considered to be a threat, and what should actually be ignored. Each SharePoint environment is in general unique, and used for a different purposes. Security strategies to secure this data have to be adaptive as well to properly achieve organizational security goals. When considering SharePoint security it is important to not get fastened to strictly considering the technology security. While there are several layers that build up SharePoint security it is equally important to secure the tools and content that interact and run on the SharePoint platform. For example, there are many avenues for a SharePoint architect to surface information in SharePoint, either through WebParts or perhaps third party enterprise application integration components. However simply surfacing this data creates a potential security vulnerability since the information could be confidential data or describe sensitive business functions. Supporting restrictions that grant the only the level and types of content is as important as technology stack vulnerabilities.

Every standard SharePoint web request begins the same way. A user, or subject, issues a request to access a SharePoint system. Before SharePoint provides access, a challenge is issued requesting the user to provide a public declaration of who they are. While there are multiple avenues a user can leverage to make this public declaration, such as manually keying values in to client based digital certificates, every approach translates to a user’s identity. An identity in the context of SharePoint is simply stating an assertion about the user. SharePoint issues the question “Who are you”, the user is responding with “I am this”.

Establishing the identity of the requesting user is only a small portion of the process. Following, the determination of whether the credentials being presented can be verified, or Authentication (AuthN in shorthand notation) occurs. After responding to the “Who are you” question from SharePoint, SharePoint issues the question “OK, prove it?” in order to verify that the requesting user is valid and not a malicious party forging an attack. AuthN can incorporate multiple authenticators such as passwords or certificate private keys. AuthN allows SharePoint to not directly possess the required secret, however the mechanisms to verify it’s authenticity.

Following authentication, Authorization (AuthZ in shorthand notation), controls the resources that the user is allowed to access. Whereas authentication is the verification of the identity assertion, authorization is the verification of permission. Authorization always precedes authentication.

Anonymous authentication means that a user has already authorized but not authenticated, bypassing the authentication step.

A real world example of an authentication and authorization relationship can be found when considering a bank. A bank customer may visit to withdraw funds from an account. Upon the member issuing the withdrawal request, the teller will ask the member for identification in order to verify the member is whom they say they are, such as a driver’s license. Following approval and verification of the identity, the authentication request funnels to the credit accounts that are valid for the member. Importantly, accounts that are not part of the member accounts are kept separate. If a non-member attempts to access the same account, their credentials will not process pass the authentication process since they are not considered authentic.Authorization differs from authentication because it is the determination of whether the login is allowed. Closely coupled to the concept of authentication, both authorization and authentication must return true to create a connection to a system such as SharePoint.

Consider this same situation from the bank teller’s perception. The teller controls and regulates access to the account, allowing users to access the funds in an account by authorizing them. The question that the bank teller answers is “Is this the owner of the account?” The bank teller does not have any proof that the presented identity, in this case a driver’s license, is valid. It would not be possible, as the bank teller was not responsible for issuing the driver’s license. The bank teller however trusts that licensing department that is responsible for issuing the license. The licensing department is considered a recognized, trustworthy source of information. The bank teller could optionally reject the presented license for a multitude of reasons, however not because of a known, trusted source. For example, an expired expiration date or a pictured that appears to be dated on the license may require the bank teller to inform the customer that the identity needs to be updated. Another institution could optionally provide identity in place of the driver’s license, such as a passport. The important factor is whether a trusted institution has issued the identity. Critically in this example, the bank teller doesn’t have to understand the process that the bank customer went through to get their license or how the bank customer came to prove their identity to get their license. The bank teller simply knows that the institution that issued the license is trusted.

Summarizing what has happened under the in the customer/teller interaction:

  • The bank teller does not verify the identity directly, rather uses a trusted institution and its issued documents metadata.
  • The bank teller doesn’t need the identifying document in a particular format, as long as it is trusted. A passport, driver’s license, and several other formats would be acceptable to the bank teller.
  • The bank teller is indifferent to how the identifying document was procured or the process that the customer went through to get the document.

This process exists in many common circumstances such as going to the liquor store or going to a movie theater, both are similar transactions that require presenting authenticating trusted identification from the customer. This process is extremely efficient, which is the reasoning behind SharePoint following a similar pattern when it comes to identity. In essence, the identity layer is decoupled from the application layer.