mailing list archives
Re: Re: Question for the Windows pros
From: Nicolas RUFF <nicolas.ruff () gmail com>
Date: Mon, 23 Jan 2006 15:59:10 +0100
Does the Impersonate a client after authentication privilege grant the
account access to ImpersonateNamedPipeClient?
Everybody can call ImpersonateNamedPipeClient(), and impersonate users
in some cases (see below). Granting this right will allow to impersonate
remote users in *any case*, which can be more sensitive.
"Assigning this privilege to a user allows programs running on behalf of
that user to impersonate a client. Requiring this user right for this
kind of impersonation prevents an unauthorized user from convincing a
client to connect (for example, by remote procedure call (RPC) or named
pipes) to a service that they have created and then impersonating that
client, which can elevate the unauthorized user's permissions to
administrative or system levels."
"In addition, a user can also impersonate an access token if any of the
following conditions exist.
• The access token that is being impersonated is for this user.
• The user, in this logon session, created the access token by logging
on to the network with explicit credentials.
• The requested level is less than Impersonate, such as Anonymous or
See also MSKB Q821546.
It is indeed the case that a process that is impersonating cannot pass on
the impersonated credentials to a child process. However, credentials are
not "embedded" in processes, or in executables; ultimately, they come from
the SAM or AD.
I am not so sure about that.
Indeed your process gains an Impersonation Token, which is more limited
than a Primary Token. However by playing around with DuplicateTokenEx(),
you might be able to convert an Impersonation Token to a Primary Token ...
But let's wait for your paper.
- Nicolas RUFF
Security Researcher @ EADS-CRC
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
Re: Question for the Windows pros Nicolas RUFF (Jan 19)