Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: Question for the Windows pros
From: Bernhard Mueller <research () sec-consult com>
Date: Thu, 19 Jan 2006 08:20:37 +0100


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



Paul Schmehl wrote:
--On Wednesday, January 18, 2006 17:07:23 -0600 Frank Knobbe
<frank () knobbe 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
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

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 () utdallas edu)
Adjunct Information Security Officer
University of Texas at Dallas
AVIEN Founding Member
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/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]