Re: [Full-disclosure] Question for the Windows pros



Hello,

The ImpersonateClient API does not require that credentials are embedded
into the program. A call to ImpersonateClient allow a server to
"impersonate" the client when it receives a local connection, e.g. via a
named pipe. It is mostly used by servers to DROP their privileges to
that of the connecting user if they are running with administrative
privileges.
A security issue with ImpersonateClient arises if there's no error
checking on the ImpersonateClient call and the process runs without
realizing that it is still SYSTEM.
Another issue would be an unprivileged client with the ImpersonateClient
privilege, if an attacker manages to make a process with admin rights
connect to that client. This is why normal users do not have this right
by default.

Regards,

Bernhard

Paul Schmehl wrote:
> --On Wednesday, January 18, 2006 17:07:23 -0600 Frank Knobbe
> <frank@xxxxxxxxx> wrote:
>
>> On Wed, 2006-01-18 at 16:16 -0600, Paul Schmehl wrote:
>>
>>> This means that the exposure, when granting the privilege, is as
>>> follows:
>>> 1) If you can launch a process on the local machine AND
>>> 2) The process has embedded credentials that are different from the user
>>> launching the process THEN
>>> 3) The user gains those credentials' privileges ***for the length of
>>> that process***
>>
>>
>> Yup. So if your use has that right, any spyware the user downloads via
>> IE can use that user right to elevate credentials **for the length of
>> the malware installation**. Does that sound right? And does that sound
>> like something you'd want to happen?
>>
> The spyware has to bring the credentials with it. The user doesn't
> *have* the credentials. It *gets* them from the process in question.
> That's a bit different. The user has the right to impersonate within
> the context of a process. The process must already have the credentials
> to elevate, or the user gets nothing (if I'm understanding impersonation
> correctly.)
>
>>
>> If you give that right, or admin privs, why don't you limit that only to
>> the duration of the software install? It sounded like you were planning
>> on granting that user right and leaving it in place. If you only grant
>> it temporarily, the exposure is not great, imho. (Remember, I've been
>> liberated from Windows for a couple years now ;)
>>
> Do you know a way to programmatically grant rights, on the fly, and then
> take them away? I know you can do this with RunAs, but that would
> require having an admin password, in the clear, and readable by
> Authenticated Users. That ain't gonna happen.
>
> As far as granting the privilege goes, *if* we do it, it will only be in
> place long enough to distribute the agents. Then it will be removed.
> But I'm reluctant to even do *that* until I'm certain I fully understand
> the ramifications.
>
> Paul Schmehl (pauls@xxxxxxxxxxxx)
> Adjunct Information Security Officer
> University of Texas at Dallas
> AVIEN Founding Member
> http://www.utdallas.edu/ir/security/
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/



Relevant Pages

  • Re: LocalService account and callback
    ... works great when I set-up Everyone has Access Permission. ... "Alexander Nickolov" wrote: ... > client is itself a COM server, ... >> and call ImpersonateClient? ...
    (microsoft.public.vc.atl)
  • Re: [Full-disclosure] Question for the Windows pros
    ... The ImpersonateClient API does not require that credentials are embedded ... A call to ImpersonateClient allow a server to ... It is mostly used by servers to DROP their privileges to ... Another issue would be an unprivileged client with the ImpersonateClient ...
    (Full-Disclosure)
  • Re: LocalService account and callback
    ... Your client has to call CoInitializeSecurity and allow access ... > and call ImpersonateClient? ...
    (microsoft.public.vc.atl)