Tag Archives: SharePoint

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.

Share

Error Handling In Office 365 And SharePoint Online

I am sure there is a lot of guidance out there regarding this subject. Personally, as things move more to a client-centric model I believe it is best to surface problems and issues with an application within a user exposable medium, such as a SharePoint list. This is possible to do within a SharePoint app in a relatively generic fashion. It makes it really easy to use. Firstly, consider the two following methods which act as the engines for capturing relevant errors:

[csharp]

public TValue ErrorHandler(Func action)
{
try
{
return action();
}
catch (Exception ex)
{
DumpErrorIntoLog(DateTime.Now.ToString(CultureInfo.InvariantCulture), ex.Message);
return default(TValue);
}
}

public void ErrorHandler(Action action)
{
try
{
action();
}
catch (Exception ex)
{
DumpErrorIntoLog(DateTime.Now.ToString(CultureInfo.InvariantCulture), ex.Message);
}
}

[/csharp]

Using the above, handling the error is pretty easy. All you have to do is use the following method in order to harness an app level list, and dump the error in that. First though, to get the context token, web specs and all that crap I am going to use a context utility class.

[csharp]

public class ContextUtility
{
public ContextUtility(HttpRequest request)
{
ContextDetails = new SpContext {ServerUrl = request.Url.Authority, HostWebUrl = HttpContext.Current.Request[“SPHostUrl”], AppWebUrl = HttpContext.Current.Request[“SPAppWebUrl”], ContextTokenString = TokenHelper.GetContextTokenFromRequest(request)};

if (ContextToken == null)
{
try
{
ContextToken = TokenHelper.ReadAndValidateContextToken(ContextDetails.ContextTokenString, ContextDetails.ServerUrl);
}
catch (Exception)
{
ContextToken = null;
}
}
JavaScriptSerializer serializer = new JavaScriptSerializer();
HttpCookie cookie = new HttpCookie(“SPContext”, serializer.Serialize(ContextDetails));
cookie.Expires = DateTime.Now.AddHours(12);
HttpContext.Current.Response.Cookies.Add(cookie);
}

public ContextUtility(SpContext context)
{
ContextDetails = context;
try
{
ContextToken = TokenHelper.ReadAndValidateContextToken(ContextDetails.ContextTokenString, ContextDetails.ServerUrl);
}
catch (Exception)
{
ContextToken = null;
}
}

public ContextUtility()
{
}

public SharePointContextToken ContextToken { get; set; }
public SpContext ContextDetails { get; set; }

public bool IsValid
{
get { return ContextToken != null; }
}

public static ContextUtility Current
{
get
{
ContextUtility spContext = null;
if (HttpContext.Current.Request.Cookies[“SPContext”] != null)
{
JavaScriptSerializer serializer = new JavaScriptSerializer();
spContext = new ContextUtility((SpContext) serializer.Deserialize(HttpContext.Current.Request.Cookies[“SPContext”].Value, typeof (SpContext)));
}
if (spContext == null || !spContext.IsValid)
{
spContext = new ContextUtility(HttpContext.Current.Request);
}

if (spContext.IsValid)
{
return spContext;
}
HttpContext.Current.Response.Redirect(GetRedirectUrl());
return null;
}
}

private static string GetRedirectUrl()
{
string hostWebUrl = HttpContext.Current.Request[“SPHostUrl”];
return TokenHelper.GetAppContextTokenRequestUrl(hostWebUrl, HttpContext.Current.Server.UrlEncode(HttpContext.Current.Request.Url.ToString()));
}
}

public class SpContext
{
public string HostWebUrl { get; set; }
public string AppWebUrl { get; set; }
public string ContextTokenString { get; set; }
public string ServerUrl { get; set; }
}

[/csharp]

Then the actual SharePoint communication, and that’s it.

[csharp]

public void DumpErrorIntoLog(string time, string message)
{
ContextUtility utility = new ContextUtility(HttpContext.Current.Request);
using (ClientContext context = TokenHelper.GetClientContextWithContextToken(utility.ContextDetails.AppWebUrl, utility.ContextDetails.ContextTokenString, HttpContext.Current.Request.Url.Authority))
{
List list = context.Web.Lists.GetByTitle(“ErrorsAndShit”);
context.Load(list);
context.ExecuteQuery();
if (list == null)
{
return;
}
CamlQuery query = CamlQuery.CreateAllItemsQuery();
ListItemCollection items = list.GetItems(query);
context.Load(items);
context.ExecuteQuery();
ListItem item = items.First();
item[“Errors”] = string.Format(“Time: {0} Message: {1}”, time, message);
item.Update();
context.ExecuteQuery();
}
}

[/csharp]

Share

SharePoint 2013 Setup – SQL Server Has An Unsupported Version

This is actually a fairly common error to run into. The scenario is pretty straightforward, I ran into it when running SharePoint 2013 on Windows 2008 R2 SP1 with all the update goodness installed and SQL Server 2008 R2 SP1 with CU 6 and all the rest of the additional shit required to install. Following, run the SP config wizard, and get to the point where you specify the database server / instance,  and boom you run into:

SQL server at domain\instance has an unsupported version [some version here]

Which is fine, pretty easy error. The part that might not make a ton of sense, or didn’t to me anyways, is I was at 10.50.2817.0 and it was bitching about 10.50.1600.1. Clearly, I am ahead on version increment so I shouldn’t hit that particular problem. But wait, it can get weirder. You can select one instance on the same server, and it will work, if you select a different instance it might fail!

The problem isn’t related to SharePoint, but how SQL server processes cumulative updates. Long story short, whenever you have multiple instances on a SQL box you need to reapply the patches after generating the new instance. For whatever reason it won’t automatically update. Which is a bunch of shit IMHO. So in essence, if you run into this, what I did to fix it was reapply  SP1, CU4 and CU11.

Share