2

I'm attempting to have a program run with administrative privileges for regular users.(The actual software throws an error about needing the admin account, I can bypass windows through the registry). The security I need is relatively cosmetic (doesn't need to be air-tight).

So for now I'm using a psexec, a desktop shortcut with exposed admin name and password. Is there anyway to lockdown viewing the target for a shortcut? GPO doesn't seem to have it, but is there anything in the registry??

The best I have so far (which is lousy), is disabling the context menu so the user can't right click (could still use Alt+Enter though).

Any thoughts would be great.

1 Answer 1

0

No matter what you do, without using some third-party utilities, there's always going to be a way for your users to easily retrieve the admin password used if you're scripting with PSEXEC like this. This is because PSEXEC needs the password to be passed to it as a command parameter in cleartext, if you're not going to be available to enter it manually every time.

A few example scenarios:

Password is provided in link parameters:

Ridiculously easy to see the password by looking at the link properties.

Password is provided via batch script, and you point the link to the script:

Easy to find the script via the link shortcut, and find the password sitting in the script.

Password is stored as a secure string in a text file, which is read and passed to PSEXEC via a PowerShell script, and you point the link to the PowerShell script:

Password is still visible in the process properties via Task Manager.
(View->Select Columns->Command Line)


That last option above is from the first revision of an answer by Adi Inbar to another question.

The latest revision of the same answer has a better solution, which is not quite so trivially exploitable, but anyone can still get to the password if they know what they're doing. It's definitely not something I'd use for one of my own accounts or systems, but it seems like it may offer acceptable protection by your standards. The solution drops PSEXEC entirely, and does all the work in PowerShell instead. However, I think it still needs some work before it's actually functional for a multi-user implementation. (I don't know exactly how to do it just now. Will update this answer if I figure it out later.) Once successfully implemented, any user with access to the script and its supporting files can still extract and decrypt the password but it's not just a simple matter of reading it as cleartext.


If you're open to using third-party software, there are some tools which allow you to add Limited user accounts to a "sudoers"-type group and restrict their elevated privileges ability to only (directly) launching the applications you choose.


In any case, there's still one important consideration to bear in mind: Whenever you allow a user to launch an application with elevated privileges, you're giving them the ability to use elevated privileges for whatever the application is capable of doing. If this includes browsing the file system (e.g.: via an Open or Save dialog), the user can then use the elevated privileges on other programs/functions that you do not want them having access to.

Example: Say you allow me access to your system, and have my account configured so that the only application I'm allowed to run with elevated privileges is Notepad. From Notepad, I'd...

  1. File->Open
  2. Set the file type to "All files (.)".
  3. Browse wherever I want in the local file system and run/open any files/programs I want as an Administrator.
    • e.g.: Navigate to C:\Windows\System32\, right-click lusrmgr.msc, select "Open", use the MMC to add myself to the real Administrators group.
5
  • Thanks for the suggestion Iszi, I thought about your second option as well. I may look into implementing the third.<br/>I'd also though about using runas with /savecred option, but credentials are lost after reboot
    – clargr1
    Sep 11, 2014 at 15:03
  • @clargr1 (RE: RunAs) And then you're back to storing credentials as cleartext somewhere. Seriously, don't do that. Especially for a domain account.
    – Iszi
    Sep 11, 2014 at 15:25
  • @clargr1 Also, be aware that the exposure mentioned in the third option still exists in the second - you could get the password from the batch script or from Task Manager. Using the PowerShell script with a SecureString object mostly mitigates the "in the script" exposure (brings it down to the level of the last option), but still leaves it open to exposure in Task Manager. The last option mitigates Task Manager exposure entirely, and makes extraction from the script a bit more difficult than if it were in cleartext.
    – Iszi
    Sep 11, 2014 at 15:30
  • Thanks again @Iszi. The system is closed, no access to the internet. The idea here is the appearance of security (for regulations), since all users are known and computer is in limited access area. I'll try and implement #3 with Task Manager locked down/robust GPO in place.
    – clargr1
    Sep 12, 2014 at 14:51
  • @clargr1 You'll need to do some more work on #3 still - same as needs to be done for #4. Also, the same exposure mentioned in #4 will still exist - the password is just one PowerShell one-liner (not a very simple one, but still) from being exposed by anyone with access to the script and its supporting files.
    – Iszi
    Sep 12, 2014 at 15:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .