0

I gave the standard user "Joe" SeImpersonatePrivilege on Windows Server 2008 R2, the only domain controller on the network. Joe isn't a member of any administrator group; when Joe starts a process it runs at Medium Integrity Level.

When the administrator runs "gpresult /z" on the server I see this partial listing:

    User Rights
    -----------
        GPO: Default Domain Controllers Policy
            Policy:            ImpersonatePrivilege
            Computer Setting:  Administrators
                               Joe
                               LOCAL SERVICE
                               NETWORK SERVICE
                               SERVICE

However when Joe runs a program that uses GetTokenInformation and LookupPrivilegeName to display Joe's privileges it produces these results on the server:

Integrity level : Medium Process

SeShutdownPrivilege
SeChangeNotifyPrivilege
SeUndockPrivilege
SeIncreaseWorkingSetPrivilege
SeTimeZonePrivilege

Press any key to continue

and these on a workstation:

Integrity level : Medium Process

SeChangeNotifyPrivilege
SeIncreaseWorkingSetPrivilege

Press any key to continue

I'd like to know whether it's possible for Joe to have SeImpersontatePrivilege while running a Medium Process and if so, how to accomplish it. My goal is to have Joe impersonate other users at the "Impersonate" level, as opposed to "Identify", whether running on a workstation or server, using Get/AcceptSecurityContext. I'd appreciate any suggestions for background reading on the topic.

Will
  • 93
  • 3
  • 12
  • 1
    Joe is getting a split token, see [this earlier answer from Super User](http://superuser.com/a/610253/96662). Unfortunately the GUI doesn't cope well in this scenario, I'm not aware of any very sensible way for Joe to run the process with impersonation privilege. You could do it programmatically [as described here](http://stackoverflow.com/a/39403260/886887) but you'd need the username and password. – Harry Johnston Nov 12 '16 at 21:20
  • On the other hand, it isn't a very sensible thing to do in the first place; there is a *reason* that the privilege is getting censored. You haven't said much about your scenario, but the correct solution is probably to redesign so that the code that requires impersonation is in a system service. (The service needn't run with administrator privileges to do so; UAC doesn't apply to services.) – Harry Johnston Nov 12 '16 at 21:24
  • (Incidentally, did you get the list of privileges from the server and the list of privileges from the workstation mixed up? Joe should have more privileges on the workstation, not fewer.) – Harry Johnston Nov 12 '16 at 21:25
  • Great link to Super User and an even better one there - thanks. I don't think Joe is getting a split token but I want him too. It looks like he needs to be a member of the right group which std users aren't by default. From here one answer might be a service as you point out; another might be a manifest with "highestAvailable". I'll experiment with that. Accessing the username/password isn't feasible in this application. – Will Nov 13 '16 at 00:40
  • The notion of sensibility in this area seems to have evolved over time. Starting with a process with least privilege, say access to no services, etc, and providing them to clients with sufficient privilege via impersonation was considered a reasonable approach at one time. Now the same (standard user - medium integrity) process can't, without some modification, impersonate so that approach no longer works. Running a service as a standard user and running a process as one from the cmd line seem similar but I'm sure there are subtleties that recommend the service. – Will Nov 13 '16 at 00:47
  • You're right - I incorrectly switched the server and workstation privilege list. Thanks for pointing it out, and for the extremely helpful links. – Will Nov 13 '16 at 00:49
  • If I remember correctly, back before SeImpersonatePrivilege was introduced, there were a fair number of security bulletins that involved a malicious process managing to impersonate a privileged account, one way or another. Restricting impersonation was a defense-in-depth measure to mitigate this class of vulnerability. Only server software needs impersonation anyway, and *usually* server software is most naturally implemented as a service. It would have been nice if UAC handled this sort of edge case more nicely, but I'm guessing MS didn't think it would be worth the effort. – Harry Johnston Nov 13 '16 at 06:24
  • My question concerns server software. I'd have to review the benefit of a service running with the same privileges as a medium integrity process (assuming it has impersonate privilege). They both seem to suffer from the same vulnerability, but I may be missing something. If the argument is against impersonation then that's one thing. I like it though, the idea of giving a server limited capabilities and relying on the client's credentials to accomplish the necessary task. This would apply to service and non-service programs. Here I'm only comparing a service to a non-service wto impersonation. – Will Nov 14 '16 at 01:30
  • *They both seem to suffer from the same vulnerability* - it's simply a lot easier, under most circumstances, for an attacker to get their code to run in an interactive context than in a service context, e.g., via a vulnerability in a web browser. By all means your service should run with minimal privilege, and in fact there are specific mechanisms to allow this - you can limit what a service can do in ways that aren't possible for an application run interactively. See http://stackoverflow.com/a/36613909/886887 if you're interested. – Harry Johnston Nov 14 '16 at 03:22
  • Your comments here and at the link clarify the matter for me; I appreciate it. Would you be able to recommend a text or other resource on programming Windows security for versions after XP (Vista through 10, not necessarily inclusive)? – Will Nov 14 '16 at 05:19
  • Nothing that springs to mind, sorry. – Harry Johnston Nov 14 '16 at 20:26

1 Answers1

0

According to this article Joe is getting a filtered token; the privilege is removed from Joe's token since Joe isn't a member of a group with special privileges. Since you can't add a privilege to a token, I believe the only ways to accomplish this is either to run the program as a service (HT to Harry Johnston) or to add Joe to a group with special privileges.

Community
  • 1
  • 1
Will
  • 93
  • 3
  • 12