Re: How to Stop a Service From Impersonating Other Users

From: Will (DELETE_westes_at_earthbroadcast.com)
Date: 11/26/05 

Date: Sat, 26 Nov 2005 12:48:00 -0800

First, thanks for your posts and explanations about impersonation. I'm
starting to read in more detail about how this works. Some issues are still
very unclear to me:

1) I still don't hear a clear answer to the question of whether a service
needs a *password* for a given userid in order to be able to grab that
user's security context. Two cases are clear to me:

a) The service is set up to run with a user's context. In this case the
userid and password are supplied to the service control manager (SCM) and
the service you are starting never sees the password. It is simply handed
the context by the SCM and runs in that context.

b) The service runs as a server and by some means the user supplies a userid
and password that in turn allows the service to authenticate that user, then
take the returned context and run in that context through the impersonate
APIs. An example of such a service might be a mail server that runs POP3
and lets users authenticate using their normal domain accounts.

The case that is not clear to me is the one I have now. I never gave
McAfee's Managed VirusScan service any user's passwords. I am very
concerned about how it was able to just grab a context that it was never
handed. Are you suggesting that McAfee has installed some kind of hook
that runs whenever a user logs in and then tries to start up a process in
that user's context and use it communicate back to the main service that
runs as SYSTEM? In that example, could a user's security context be
handed over to the application running as SYSTEM so that it could
impersonate that user later after he has logged out?

If it is this easy for any application on an end user machine to simply
impersonate that user later, even after the user has logged out, I feel
incredible jeopardy in using Microsoft software. This opens up a huge
range of possible intrusions by Trojan Horses that it looks to me would be
almost impossible to defend against by software configuration alone.

2) Once a service that runs as SYSTEM has a user's context would the context
then expire when the kerberos ticket expires? That might argue for
making the Kerberos expirations more frequent?

3) Can any application that run as SYSTEM automatically use impersonation
*IF* the Group Policy entry for impersonation user rights has been set to no
entries? I'm inferring that any application that runs as SYSTEM can by
definition "Act as part of operating system" even when the Act as part of OS
user right is set to empty. If the answer to that is yes, it would appear
there is absolutely no way to protect against this if the user has the
ability to install applications on a computer.

4) The Microsoft Knowledge Base article 821546 talks about the "Impersonate
a Client After Authenication" user right. Normally this user right has two
members: SERVICE and Administrators. The KB article has the following
statement that makes the issue unclear to me:

    "The following components *ALSO* have this user right:

        * Services that are started by the Service Control Manager
        * Component Object Model (COM) servers that are started by the COM
infrastructure and that are configured to run under a specific account"

The use of the word 'also' in the above makes it sound like even if we set
the "Impersonate a Client After Authentication" user right to null, that all
services *still* have the right to impersonate, and even worse all COM
objects will have that right. This perplexes me. What is the point of
having SERVICE as a member of the Impersonate privilege if the OS is going
to secretly give that right to the service anyway!? 

-- 
Will
"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:e7Gvi5d8FHA.3636@TK2MSFTNGP09.phx.gbl...
> Getting back to the intent of the initial posting . . .
> I find this also to be a rude behavior.
> Let's assume that the application must run with System rights in order
> to do its work (on access scanning for all accounts, for example).
> Is it then appropriate for that code to assume that, since it can, it is
> just fine and dandy for it to use the creds of an arbitrary account in
> order to go off-box for updates?
> In my book no, that is not a well-designed application, at least not
> an administrator friendly one.  Recognizing the need to be updated,
> I would expect the ability to configure this updating behavior, that
> would include, does it happen, on what schedule, using what creds,
> etc..
> If you were to look at how the software operates, what you may
> find is that when an account logs into the machine, a separate service
> gets started, as that user, and this lives beyond the login sessions,
> and this handles the updating functionality.
>
>
> "Will" <DELETE_westes@earthbroadcast.com> wrote in message
> news:X7mdnXQL0_c_XhnenZ2dnUVZ_t-dnZ2d@giganews.com...
> >I got a rude surprise after installing McAfee's Managed VirusScan
software
> > on our network.   The McAfee service - without every asking any
permission
> > or exposing any configuration setting to the admin - simply impersonates
> > any
> > user who logs into the console of a machine on which it resides, in
order
> > to
> > be able to get Internet access and do downloads of updates.    While the
> > goal is straightforward and McAfee is a name to trust, it is appalling
to
> > me
> > that they think it is okay to login to a machine at 3am in the morning
as
> > the Enterprise Administrator and not even get permission to do that!!
> >
> > How can I stop any service that runs as SYSTEM from being able to
> > impersonate any user who logs into a console?   And what is really
strange
> > to me is how can McAfee do this unless they are monitoring the keyboard
> > and
> > stealing passwords?   You can't impersonate a user without the full SID
> > and
> > password even if you have the privilieges to do so can you?
> >
> > I need an education on how impersonation works and how its behavior can
be
> > modified through Group Policy.
> >
> > -- 
> > Will
> >
> >
>
>

Relevant Pages

  • Re: How to Stop a Service From Impersonating Other Users
    ... off something running in that user context, ... > take the returned context and run in that context through the impersonate ... > and lets users authenticate using their normal domain accounts. ... > infrastructure and that are configured to run under a specific account" ...
    (microsoft.public.windows.server.security)
  • Re: Security Challenge: Runtime impersonation without calling LogonUse
    ... Dim context as windowsimpersonationcontext ... I'd> like to impersonate the person making the request at RUNTIME instead of> specifying impersonate="true" in the web.config. ... > Does anyone know how I can get the requesting user's userToken to pass to> the Impersonate method of the ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Impersonation problem in Sharepoint 2007
    ... tested a lot of things to impersonate our current user but nothing ... Impersonate method with RevertToSelf: ... WindowsIdentity impersonatedUserIdentity = ... the WindowsIdendity associated to the context ...
    (microsoft.public.sharepoint.portalserver.development)
  • Re: Impersonation
    ... That sentence 'If you impersonate on the main ... around with trying to impersonate the logged-on user from your windows ... > change the process security context once a process is started. ... >> Richard. ...
    (microsoft.public.dotnet.framework)
  • Re: Sql Reporting Serviced - > ASP.NET ACCESS DENIED!
    ... The account you are logging in to when on the server doesn't have the ... do you have <Impersonate> set to True? ... > Exception Details: System.UnauthorizedAccessException: Access to the path ...
    (microsoft.public.dotnet.framework.aspnet.security)