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: <88FAB09D4B4C0A80874E16A4@utd59514.utdallas.edu>
Date: Wed Jan 18 22:16:14 2006
From: pauls at utdallas.edu (Paul Schmehl)
Subject: Question for the Windows pros

--On Wednesday, January 18, 2006 14:01:18 -0600 Frank Knobbe 
<frank@...bbe.us> wrote:
>
> What are you granting them su for? Perhaps for a mail migration utility
> that runs as administrator, but assumes the security context of a user
> to read email from his mailbox (yeah, admin can do that, this is just an
> example). Or for running a script remotely against a user workstation
> that sets certain things in the Registry in the user context (to gain
> access to the Secure Storage or such).
>
I think I finally figured out what's going on.

We just got ePO this year.  I set it up to install the agents throughout 
the enterprise and it succeeded on about 20% of our machines.  After 
testing, I determined that the user had to be local admin for the agent to 
install.  So, I looked for an alternative, because most of our users aren't 
local admins and never will be.

McAfee offers a custom installer (which you have to create using a wizard) 
within which you can embed credentials.  The embedded credentials are for 
an account that has local admin access.  I created the installer, began 
testing and discovered that, when the logged on user was a User, the 
install failed.  Back to the drawing board.  Called McAfee support.  They 
said, "User must have the Impersonate client after authentication" 
privilege.  I tested it.  It worked.

Before I ask for a GPO change, I wanted to know what exposure I have.  This 
is how I understand the process:

1) Joe, who is a User, launches the custom installer (through a login 
script)
2) The install process begins running under Joe's credentials (User)
3) At some point in the install process, elevated privileges are required 
to continue
4) Joe doesn't have them, but he has the Impersonate privilege.
5) Joe's process requests the credentials embedded in the custom installer
6) Joe's process uses those credentials to complete the install, then 
relinquishes them

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

>From a hacker standpoint, this means that you would already need elevated 
privileges in order to take advantage of the user's right to impersonate. 
This is a fairly low risk.

So, why did M$ decide to remove this right from the user?  Because it 
prevents them from installing software on the box.

OK, shoot holes in my theory.

Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/ir/security/