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



--On Wednesday, January 18, 2006 14:01:18 -0600 Frank Knobbe <frank@xxxxxxxxx> 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@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/



Relevant Pages

  • Re: DC Admin question
    ... could with great ease become an admin. ... The use case has bearing on the driver install need. ... You have to be an admin to perform the original driver installation. ... It does not grant the privilege. ...
    (microsoft.public.windows.server.security)
  • Re: DC Admin question
    ... There is actually a middle ground, but the line between it and admin is so ... The use case has bearing on the driver install need. ... You have to be an admin to perform the original driver installation. ... It does not grant the privilege. ...
    (microsoft.public.windows.server.security)
  • Re: Installation error, do not have rights to install update
    ... Do you mean that privilege is only available to Exchange Enterprise Admins? ... Are you logged on as Exchange enterprise admin? ... > The manage auditing and security log rights have Exchange Enterprise ... >>> Am trying to install the latest round of patches. ...
    (microsoft.public.windowsupdate)
  • RE: RunAs
    ... admin and not tested when run via Runas. ... Administrator-equivalent account to install software. ... and secure to just not make the user an Administrator. ... [although Power User is a dangerous privilege to give ...
    (Focus-Microsoft)
  • Re: Deny Interactive Logon but Allow Runas
    ... users may also need to install a fix-pack, ... be an admin to install. ... if your secret app is really so bad ... As our users don't have local admin rights they usually have ...
    (microsoft.public.windowsxp.security_admin)