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