SharePoint Security Software And Research view

What is the audience of the MOSS and WSS v3 SharePoint Security Software?

  • An executive who desires a quick overview of the findings and recommendations of security assessment and audits, as well as proper implementation of SharePoint security
  • A manager tasked with interpreting the findings of the collobration platforms assessment and deciding what action to take based on the recommendations, along with pre-emptive security consideration for a Microsoft Office SharePoint Server and Windows SharePoint Services
  • A technical staff member tasked with understanding the issues presented in a security assessment and implementing specific security recommendations based on presented best practices. This technician (typically the SharePoint administrator), will often time take the SharePoint Security Best Practices and mold them to their specific industry and organizational structure.

What is the purpose of SharePoint Security research, and How Does the Best Practices Guide and SharePoint Security Toolkit help in securing a SharePoint environment?
The purpose of MOSS and WSS v3 security research and software development (such as various pieces of SharePoint Security Software) is to identify any root cause of inappropriate behavior observed in the collobration software and identify whether it represents a possible security vulnerability to the SharePoint platform. Various pieces of SharePoint security software provides mechanisms to deal with arbitrary security concerns and architectural considerations, providing SharePoint administrators and developers the faculities to discover, research, and rememdy various security and custodial issues. If a software vulnerability is confirmed, the following action is to test and document this vulnerability and assist Microsoft in securing the software, thus protecting the customer base from abuse, as well as integrating the concern into the SharePoint Security Best Practices Guide. When a major issue is easily translated into a software requirement (such as issues that don’t generally imply a methology or something that is a complete human-oriented process) the is built into the SharePoint Security Toolkit WinForms Application as a “Security Module”. An example of a security module would be a page validator that consumes a arbitrary SharePoint WebForm, a packet sniffer, or a SharePoint centric log parser. It is atypical for a module in the toolkit to be programmed as a web based module since the access to the toolkit is restricted to the server, since most of the application hooks will rely on being on the machine.
What is the overall purpose of the SharePoint Security Best Practices Guide?
With an ever increasing amount of information in organizations being transmitted and collobrated on within a Microsoft Office Server System environment, it is important that security be considered in every phase of network and application design, as well as in maintenance. Although it is common that much organizational emphasis be placed on such things as physical networking and remote access methods, it is imperative that the core application security infrastructure of SharePoint not be overlooked. The SharePoint Security Best Practices Guide provides the human recommended human oriented tasks (i.e. such as proper configuration of forms based authentication), where as the SharePoint Security Toolkit provides application based mechanisms that allow a person to automate and investigate security based SharePoint issues.

A More Granular Explanation of the SharePoint Security Best Practices Guide

SharePoint quickly becomes the lifeblood of organizations once the user adoption process is realized and absorbed and virtual teams are finally built and solidified. Great care and focus must be taken to properly secure it to ensure that business data is safeguarded and that each aspect of the SharePoint infrastructure is accounted for and maintained.

This security best practices guide takes a look at every aspect that might afflict an organizations security beginning with the first line,the perimeter. Although many think that as long as the perimeter is secure the job is done, perimeter security is only a small piece of overall security.

Security and complexity are often inversely proportional. Every step taken whether it’s vulnerability and risk assessment, security policy and procedure development, deployment of mechanisms or user education should be as straightforward and simple as possible. The more cryptic the instructions and procedures, the more room for misunderstanding and misapplication.

The SharePoint Security Best Practices Guide takes this into consideration by providing easy to use guidelines for every level of SharePoint administrator. SharePoint security best practices provide a recommended method to handle a task, rather than presenting all of the options available. The recommendation might depend on your configuration environment, so the guide and presented tools need to be molded to a particular organization and are presented as independent to industry.

To explain this concept a little further, best practice recommendations can serve as guidelines for organizations, to assist them in providing timely and helpful information while involved with the SharePoint environment. Unlike many best practices, however, these recommendations do not contain all the practices that should be observed, but attempt to build a framework for any organization, in any industry, to build upon and make their own. Information-handling practices and SharePoint technology are changing rapidly, and organizations should continuously review and update their own situation to ensure compliance with the laws and principles of security and collaborative environment protection. It is recognized that specific or unique considerations, including compliance with other laws, may make some of these practices inappropriate for some organizations, and all legal regulations should be observed and taken into the arbitrary scenario. Implementing an effective SharePoint security program is essential for an organization to fulfill its responsibilities towards the individuals who entrust it with their personal and business information.

Why We Are Rethinking SharePoint Security
Perhaps the most compelling reason to rethink the security of SharePoint is to get a collaboration and communications platform with greatly improved security and robustness. Although there are some approaches in dealing with SharePoint security, building an overall security architecture can be extremely important. Typical collaboration security is more resembling of a growing mass of band-aids than a plan.
Our research takes a broad definition of security and robustness. The traditional focus of the security research community has been on protection from unwanted disclosure and corruption of data. We propose to extend this to availability and resilience to attack and failure. Any SharePoint platform should attain the highest possible level of availability, so that it can be used for critical activities, and it can serve in times of crisis.

Some of the actual security problems that plague information workers today are also not in SharePoint environment itself, but in the IW’s computers that attach to the SharePoint server. Therefore it is necessary to address security and deal with issues in the end-nodes as well as the network. Although a serious challenge, an opportunity to reach beyond the traditional network research and engage operating systems and distributed systems design.

The most vexing security problems are not just failures of technology, but result from the interaction between human behavior and technology. For example, demanding better identification of all SharePoint users, it might make tracking attacks and abuse easier, but loss of anonymity and constant surveillance might have a very poor effect on many of the ways that SharePoint is used.

There are specific design challenges in building a secure and robust SharePoint environment:

  • Any set of “well-behaved” hosts should be able to communicate among themselves as they desire, with high reliability and predictability, and malicious or corrupted nodes should not be able to disrupt this communication. Users should expect a level of availability that matches or exceeds the telephone system of today.
  • Security and robustness should be extended across layers. Because security and reliability to an end user depends on the robustness of both the network layer and the distributed applications.
  • There should be a reasoned balance between identity for accountability and deterrence and privacy and freedom from unjustified observation and tracking.

What is the attacker perspective used during security research?
During some of the development of the SharePoint Security Management Studio, various methods of vulnerability research is done starting at the web application level. Any of this exploitive testing of SharePoint software is done blind (black box), i.e. as an unauthenticated, unauthorized user attempting to subvert the platform, and in this case, gaining unauthorized access to the server or working through methods of privilege escalation.

Confirmation of exploitation and further research into the exact methods to exploit the platform is performed as a fully authenticated, administratively authorized user. This access is, however, in no way needed in order to execute various security methods (such as those that would allow unauthorized code to execute on a server, XSS, etc.).

What is the difference between white box and black box security testing?
In the above, there was a mention of black box testing. Within the security community, there are two approaches to penetration and vulnerability testing: “black box” and “white box“. Black box implies that when doing the penetration testing there is no previous knowledge of the environment to be tested other than the name of the company. White box implies significant background knowledge of the environment including the type of network, SharePoint version , application server platform , database platform, load balancers, firewalls, and other MS server systems that are involved.

What is the standard process that is used during SharePoint and WSS Security research?

1) Plan The Security Research and Scope
We mostly use black box approaches, however firstly it is best to determine if it’s a black box or white box approach, realizing that the black box approach is just a matter of minutes away from the white box approach. This helps to validate the security methodologies that we are recommending for perimeter based SharePoint deployments whereby an external user my attempt to gain access. Following, we typically decide what the success criteria are. Plot out whether known exploits will be performed and to what extent. The plan typically includes working with an internal member to monitor the work either via an IDS or manual monitoring so as not to adversely affect operations.

2) Gather Information About The Target, and Weave Information Into Aggregate Plan
The gathering information is often times called reconnaissance against the target. After obtaining IP address information, the next step typically involves scanning the range for listening ports and services, OS fingerprinting, grabbing banner information that might include contact information, running an SNMP sweep looking for public community strings, and gathering any other information that might come in handy when validating recommendations being placed into the SharePoint Security Best Practices Guide, and when building functionality into the SharePoint Security Toolkit.

3) Verify Approaches, Vulnerabilities, and Information
This is typically called analysis and can be accomplished in a number of ways, but all have to do with scanning the target IP range and comparing that information found to a vulnerability database for matches.

4) Perform Security Intrusion and Verify Approaches
The exploit(s) are framed around the vulnerabilities found. This is a pretty straightforward step, however determines whether the security portion should be crafted in to the SharePoint Security Toolkit, or whether it requires documentation into the SharePoint Security Best Practices Guide.

5) Cleanup the SharePoint Server
This is about cleaning up log files and making sure whatever settings or parameters were changed during the test are set back to their original condition. This requires excellent documentation during the test and work with the system and network administrators afterwards to make sure that the situation is satisfactory upon completion and is vital to determining whether the found portion should be integrated into any of the tools found on this site.

6) Report Out, Integrate Findings
The final report must map the findings (vulnerabilities found, exploits performed) to the risk the company might realize if the threats were realized. We also provide a remediation roadmap based on “best practices” and be available to discuss the various technology options and costs. At this point the various findings are integrated into one of the assets on this site, and the information is published.

The 90/10 Rule of Vulnerabilities and SharePoint Security Testing
The old 90 / 10 rule also applies to occurrence of critical vulnerabilities, meaning 90 percent of vulnerability exposure is caused by 10 percent of critical vulnerabilities. This means that ten percent of critical vulnerabilities cause nearly all exposure. This means that targeting initial remediation efforts on critical vulnerabilities with the highest degree of exposure are the most important focus to have when working with SharePoint vulnerabilities.

Share

Architecture of InfoPath Forms Services Browser Interaction

InfoPath Forms Services relies on the InfoPath 2007 client application for forms development, VSTO or VSTA to tap into the InfoPath Object Model exposed from Microsoft.Office.InfoPath, and either a standalone OFS 2007 instance or Microsoft Office SharePoint Server 2007 with Enterprise Features enabled to make use of Form Services. InfoPath Forms Services, although offered as a separate product, is directly integrated into the Office Server 2007 platform and even when OFS is a siloed installation will make use of WSSv3 components which allows Forms Server 2007 to provide powerful benefits. The most important function that InfoPath Forms Services presents is the option to cast an InfoPath form to HTML for users without the InfoPath Smart Client installed. This is accomplished using a basic four-step process. For conceptual purposes steps such as run-time data connection establishment through UDC’s and other small scope activities are left out in order to present the larger operational process.

Fundamental Browser Form Rendering Process

 

Action

 

Description of Resulting Process

 

User Requests Form

 

When a user first requests an InfoPath .XSN (form template or InfoPath Solution File) hosted in a SharePoint Form Library, it will check whether the client InfoPath Smart Client application is installed on the client machine, if it is the client to display the form.

 

User Does Not Have InfoPath Installed

 

If the user does not have InfoPath installed, the InfoPath Forms converter is called and the user is redirected to the FormServer.aspx page by use of the InfoPath Forms Services HTTP Handler (using the xdEnvironment::IsBrowser() global function)

 

User Is Found On Mobile Device

 

If the user is on a mobile device, the InfoPath Forms converter is called and the user redirects to the MobileFormServer.aspx page by use of the InfoPath Forms Services HTTP Handler. (using the xdEnvironment::IsMobile() global function

 

Form Conversion

 

Using the FormsServices converter component, the XSN file is broke down into its source files. The source files include the manifest.XSF, .XSD schema files, template.xml files, and view XSL files. These files are then used on the server to output the relevant XML, ASPX, and Jscript files required for browser based rendering contained by the XmlFormView control (derived out of the Microsoft.Office.InfoPath.Server.Controls namespace as you will see shortly)

 

The backend data process during submission when using InfoPath Forms Services is drastically different than data process when submitting through the use of the InfoPath Smart Client. When entering and submitting data through the InfoPath Smart Client, the data set that InfoPath pushes is pushed as the complete XML set. Within the browser environment provided by the Forms Services XmlFormView control, there is a constant event log whenever a user is submitting data in order to promote an environment to accomplish activities such as formatting and validation controls through DOM scripting languages such as Jscript. Before data is submitted to its final destination source by a browser based form, the event log that is being captured is verified against the server through the use of AJAX(Asynchronous JavaScript and XML) methods, and lastly the XML submission occurs. Periodically, data is sent back to the server in order to increase the performance of the forms rendering page, otherwise the amount of data being captured on the client machine would become unmanageable and decrease the performance of the browser based forms page heavily.

Share

Trust Levels in Microsoft Office SharePoint Server and WSSv3

Introduction to Microsoft Office SharePoint Server and WSSv3 Trust Levels and Code Access Security

Trust levels are an integral portion of SharePoint security and how your application architecture will interact with users. Trust levels are integrally tied into the concept of Code Access Security (CAS) in SharePoint, and how that code interacts with various security decisions. Typically, when executing code in an application environment, the context of that application will assimilate the identity of the user, regardless of what the arbitrary application may be. This however differs in SharePoint, which leverages the concept of Code Access Security in order to determine what code should be run within the SharePoint environment. CAS, at first glance can appear very confusing, but rather, once the concept and architecture that builds CAS is understood it is a very powerful concept.

Defining Trust Levels Within SharePoint

There are various CAS trust levels that SharePoint can run under, each which has its owns implications and after effects, and deciding which to leverage dictates a through analysis before implementing each within your SharePoint environment. As developers of the previous version of SharePoint can attest to, establishing the trust levels for your custom WebParts that are developed can prove rather problematic. The trust levels that are managed are saying exactly what classes your code can call out of the .NET framework as well as how that code is managed and leveraged within the SharePoint application, and although developing the actual WebPart is straightforward, how to properly implement it within your SharePoint environment tends not to be. These trust levels exist on the actual SharePoint machine as provided by the ASP.NET 2.0 framework, and can be modified or added to with custom policy files as deemed appropriate. It is somewhat common since it is the default for vanilla ASP.NET application to implement full trust, however is incredibly poor code access security practice.

The Various Trust Levels of SharePoint

There are several standard default trust levels that you get with SharePoint; full trust, high trust, medium trust, low trust, and minimum trust. With full trust all code that is implemented is allowed to run in essence, it is allowed to call any class within the .NET framework and can call pretty much any operation on the local machine. This can be a dangerous level to implement, since it will allow SharePoint WebParts to call operations on the machine that although are quite powerful, can prove dangerous to the machine. High trusts, and any subsequent trust levels, are considered partial trust, since they don’t allow full trust as the previously described level does. The next level of trust is high trust. High trust when implemented in SharePoint is simply that your SharePoint WebParts can not call native unmanaged code, which is defiantly a good thing. When defining the level as high, it will significantly reduce the threat to your SharePoint environment and is definitely the first step to implemented proper SharePoint security. Medium trust is the next trust level, and is typically within an implementation where there are multiple SharePoint instances hosted on a singular machine, where it is important to maintain a more granular level of permissions across a shared environment. The largest restriction that gets placed on applications that are running in medium trust is that it inherits the restriction of not being able to call the win32 API’s from the high trust level, and in addition restricts reading and writing to anything outside of the SharePoint instance, i.e. where you provision your SharePoint web application structure. You can easily find this by doing an explore through the IIS MMC which will show you the exact path that the code will be able to write. Low trust is the next trust, and is the most restrictive trust, and is typically if you are not running and code on the web server at all, is a good level of trust. It s a typically trust level implemented by default when implemented COTS software that doesn’t have several .aspx pages that exist on the filesystem. In MOSS and WSSv3, there is a modified level of low trust that is implemented by default, however this can obviously be extended with the trust levels that we have talked about thus far. The last trust level to be discussed is that of minimal trust, and minimal locks down the levels available to the developer to a large extent. When running under minimal trust, it means that all WebParts and custom application hooks into SharePoint will not be able to call classes that could at any point possible cause a security compromise of the SharePoint environment. This is a good practice for sheltered SharePoint environments for one overlying reason. When developing WebParts, you can sign them in order to bind them with a strong name, and then deploy them into the Global Assembly Cache (GAC). Only a user with local administrator privileges within a SharePoint server can install various assemblies to the GAC, and therefore deploying code that could potentially cause undue security problems is locked down to simply an administrative task, whom can firstly examine and analyze the code before deploying it to the production SharePoint server.

Partially Trusted Callers

One of the largest differences that a developer will see within MOSS and WSSv3 is that there is within the assemblyinfo file within there project file in the system.security namespace partially trusted callers. Now that we have seen what a partial trust class is, we can see that when under certain trust levels the code will not be able to call various interops, however in the aseemblyinfo file you can set the partially trusted attribute to true to bypass this restriction in your code when needing to make such actions.

Permission Sets and Code Groups

As discussed previously, the central concept to understand in terms of trust levels is CAS, which is discussed more exhaustively in other articles. In other articles the idea of a permission set was discussed which deserves some examination in this current context since it plays a heavy role in the concept of trust levels with SharePoint. As defined in the CAS article, a permission set is simply a way of lumping code restrictions into a manageable group that can be applied to singular or multiple sets of code that are going to run within your SharePoint environment. This is a very powerful configuration concept since it allows a developer to define new permissions to apply to code when it is necessary, when the standard permission sets the ASP.NET 2.0 doesn’t give by default. Within ASP.NET 2.0, there are a few default permission sets that are defined by default: FullTrust, Nothing, and ASP.Net. Each of these, as well as we will see with custom permission sets, are defined within the < PermissionSet /> node in the web.config file, and within this node, there are several child elements that can be defined that can be used to either extend/change the default permission sets or modify custom created permissions that you leverage against your code. In this, the permission sets have to bound to a specific set of code to be useful, as opposed to something that is applied at a global level. The major concept that binds the permission set to a specific piece of code is code evidence, which defines things such as where the compiled code is located, signatures on the compiled assembly, and other various pieces of information, and once the evidence is there, the evidence can be then used in to place the CAS rules against the running piece of code, called a code group, by using a membership condition. Code groups where discussed on another article on this site, however they are easily defined within the code group elements in the web.config file. The code group in essence will allow a developer to bind to a defined permission set whether it is a default permission set, or a custom defined one, and then will look at the code evidence as presented in the membership conditions for final applicability. Code groups are inherently important to concept of securely running a SharePoint environment, since they build the binding of evidence within WebPart code. Code Groups, as you may have guessed, are related to the concept of permissions sets in that each code group is associated within a defined permission set, as discussed above, so when examining the code group values in the web.config file, you will see that for each the PermissionSetName value will be set to a permission set. Within the code group, there is also a node for the conditionally membership match as discussed above, which is defined in the IMembershipCondition node, which is based on the concept of evidence as provided thus far.

Example of Default Code Groups

Code groups within the web.config a very easy to breakdown and define, they are very self explanatory and the concepts that they birth are easy to see within their XML values. For example, let’s look at the first code group that is defined, which is just the FirstMatchCodeGroup. It looks like the following:

[xml]

< CodeGroup class=FirstMatchCodeGroup

version=1 PermissionSetName=Nothing >

< IMembershipCondition class=AllMembershipCondition version=1

/ >

[/xml]

String Replacement Values and Their Definitions

When examining the code groups, there may be some values that appear confusing, and they are string replacement values. These appear in various places when doing SharePoint development as well as traditional ASP.NET 2.0 development that may hook into SharePoint API’s. This are extremely evident when firstly examining the policy files, but appear in other places as well. The string replacements that you find are $AppDir$, $AppDirUrl$, $CodeGen$, and $OriginHost$. These are placed in these files for a very good reason, because SharePoint in essence is a very dynamic application that allows the placement of relevant files and configuration elements in various locations, the values may at times may need to be replaced at run time. The actual values that are going to be used when the replacement variables run at pretty self-evident, $AppDir$ will give the full file system path, $AppDirUrl$ will give the replacement file system path is fit for consumption that are needed in a certain format, $CodeGen$ shows where the managed code that a developer writing against SharePoint, or in a larger picture, the managed code that ASP.NET 2.0 is using, in essence where the temporary ASP.NET files lie (usually in the framework directly under the Temporary ASP.NET Files directory) and is the code that the developer defines is located, and lastly $OriginHost$ which will give will give the fully qualified URL endpoint of where the code is originating from, so for code running on this site, the OriginHost value would be http://www.sharepointsecurity.com.

Examining the Default Values of SharePoint

To get a better idea of this whole concept, examine the default permissionsets that are given by default: FullTrust, Nothing, and ASP.Net, and then I will show how to create a new permissionset that can be used if you need to create a new one for consumption into SharePoint. As well, lets look at a real world example of using code groups within our SharePoint environment to effectively restrict the permissions that are leveraged against a SharePoint WebPart.

Firstly, here is the permission set for fulltrust, the most lenient of permission sets:

[xml]

< PermissionSet class=NamedPermissionSet version=1

Unrestricted=true Name=FullTrust

Description=Allows full access

/ >

[/xml]

We can see in the above that we are allowing unrestricted access, a very open permission level.

The next permission set is that of nothing, and means that there are null permissions.

[xml]

< PermissionSet class=NamedPermissionSet version=1

Name=Nothing

Description=Denies all resources, including the right to execute

/ >

[/xml]

The ASP.Net permission set allows various meanings that define each of the unique trust levels, and looks like the below:

[xml]

< PermissionSet class=NamedPermissionSet version=1

Name=ASP.Net >

…….

…….

…….

< /PermissionSet >

[/xml]

Outside of the default permission sets that are defined, it is possible to define custom permissions that can be applied in regards to CAS, such as the option for I/O operations for a specific piece of code.

Share