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.