Re: How to Stop a Service From Impersonating Other Users

From: Roger Abell [MVP] (mvpNoSpam_at_asu.edu)
Date: 11/27/05 

Date: Sat, 26 Nov 2005 16:27:28 -0700

Your case two may actually exist, but the common case two is
a process that is run by the user (hence under the user token)
that then calls something such as what the service provides
which gives the service access to the user token for use.
I do not know the detail of how your AV is architected, but it
is not uncommon for the System context service to then spawn
off something running in that user context, which seems to be
the likely pattern for the AV you have mentioned.

"Will" <DELETE_westes@earthbroadcast.com> wrote in message
news:leydnQpf2sifVxXenZ2dnUVZ_tSdnZ2d@giganews.com...
> 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
    ... The service is set up to run with a user's context. ... take the returned context and run in that context through the impersonate ... infrastructure and that are configured to run under a specific account" ... > find is that when an account logs into the machine, ...
    (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)
  • Clarification: IUSR access to the ASP.NET temp folder
    ... That folder has NTFS Full access for Network Service, ... What are the security implications of giving the IUSR_account NTFS ... granting access rights to the resource to the ASP.NET request identity. ... context) +85 ...
    (microsoft.public.dotnet.framework.aspnet.security)