full-disclosure - 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <43CF3DC5.9080406@sec-consult.com>
Date: Thu Jan 19 07:21:56 2006
From: research at sec-consult.com (Bernhard Mueller)
Subject: 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@...bbe.us> 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@...allas.edu)
> 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/