Clever, very clever (but bad all the same)

I just read on bugtraq about Cesar’s presentation on “Token Kidnapping”. All versions of windows are affected.

While I don’t use this blog for IT security stuff, I do strongly recommend you read both Microsoft’s advisory and especially Cesar’s presentation from his company’s web site. This vulnerability has all the characteristics of mass-exploit fodder, and SharePoint sites may have some susceptibility. Additionally, when ‘patched’, it may be one of those fixes that breaks compatibility with things.

So, here’s the gist of the issue. SharePoint web applications run in the context of whatever user account was chosen when the web application was created. When it accesses the SQL configuration database, it does so using the web service account. After SharePoint authenticates a user, it can take on that user’s identity through impersonation, when it needs to access or check for user permissions to a resource (i.e not the web application account).

Sometimes you impersonate an account that has more privileged access than you. Obviously that is a security risk, so you need to have specific permission to do so. There are four impersonation levels, each of which indicates the degree to which one user can impersonate another – SecurityAnonymous, SecurityIdentification, SecurityImpersonation, and SecurityDelegation. A limited user needs SE_IMPERSONATE_PRIVILEGE enabled in order to impersonate the context of an administrator account.

Back to Cesar. essentially he has discovered a clever technique for gaining privileged access to a server, via a combination of factors. If two windows services are running via the same user account, one can access the threads of the other. What if service A has the SeImpersonatePrivilege level? Though Cesar’s technique, service B now can also gain that privilege.

Ouch!

So if SharePoint is running as the NETWORK SERVICE account (very common on WSS scenarios), it is possible for it to access the threads of, say, the RpcSs service, which has the SeImpersonatePrivilege impersonation level. Therefore, SharePoint running as NETWORK SERVICE may potentially be a vector to gaining privilege escalation on the server.

Nasty…

2 Comments on “Clever, very clever (but bad all the same)

  1. Very interesting and more than slightly alarming. Thanks for the information.

    If I’m reading this correctly, though, if a MOSS farm was built with best practices and using dedictaed “least privileged” service accounts (from an AD domain), that farm should not be in danger, correct? The highjacked service account would not be running more than one service… Right? I could be missing something… Thanks!

  2. Yes right Matt, hence why I suggested this is more a WSS3 issue than it is MOSS 2007. There is no good reason why farm, ssp or web app accounts should need to run sharing the credentials of other windows services.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.