full-disclosure - Re: Question for the Windows pros

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <43D4EF3E.4030402@gmail.com>
Date: Mon Jan 23 15:06:14 2006
From: nicolas.ruff at gmail.com (Nicolas RUFF)
Subject: Re: Question for the Windows pros

> 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.

Quoting
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/fe1fb475-4bc8-484b-9828-a096262b54ca.mspx

Description :

"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."

Note :

"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
Identify."

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.

Regards,
- Nicolas RUFF
Security Researcher @ EADS-CRC