The EncryptedRunAs program sounds very similar to old program called CPAU. It's no longer supported, but still works fine on Windows 7 and it's free. However, both programs have a serious flaw. In order to run the actual command you want with the credentials that are "encrypted," they have to have the encryption key and use it to decrypt the command. In other words, at best you have several layers of obfuscation on top of an encoded password. Awhile back I saw a blog post showing how to retrieve the password hidden in a CPAU file & I'm sure the same thing is possible with EncryptedRunAs.
Ultimately it depends on the threat you're trying to mitigate. If something like this is the only way for you to remove administrator access on users' machines, then it might be worth it. The downside is that a proficient attacker who's compromised the machine and is paying attention might be able to use this configuration to get access to administrator account. The alternative is that they're already on the machine running as administrator. If you do go that route, I'd suggest "encrypting" a local administrator account with a unique password on each machine. It'll be more of a hassle to setup, but you might be able to script it. On Tue, Jun 18, 2013 at 9:04 AM, Tony Turner <[email protected]> wrote: > In the past I used regmon and tokenmon to understand what rights apps need > to run and then made permissions changes on specific registry keys or > protected files to allow privileged access and included that custom config > in default build for that subsection of users requiring elevated access. > Make sure you understand the security implications of any permissions > changes if you take this approach. For enterprise specific browser > addons/ActiveX controls, we created administrator approved controls within > GPO to allow normal users to install approved components. The downside to > this is its essentially a software restriction policy and uses a hash rule > so have to update GPO when the package changes.This was in a Win XP world > so not sure how relevant this would be today. > > -Tony > > On Tue, Jun 18, 2013 at 9:53 AM, Mike Perez <[email protected]> wrote: > >> As luck would have it, I'm in the Windows Security class with Jason >> Fossen. I'll ask him if he has any specific recommendations. >> >> Did you get any feedback from the list yet? If so, please share! >> >> Thanks, >> Mike >> >> >> On Sun, Jun 16, 2013 at 10:25 PM, Michael Salmon >> <[email protected]>wrote: >> >>> Hi guys, >>> Got a question I'd like to get some advice on. I support a Windows 7 >>> environment and we stripped the users of admin rights, however there are >>> some applications that still require admin rights to run. >>> For one user I tried setting him up with a 2nd account w/ admin rights >>> so he could Run As the program with it but he figured out that it works for >>> any software and abused it (yeah, I know.. big surprise). Another option >>> I've looked into is creating a shortcut to the program that uses the runas >>> /savecred for the default admin account to launch the program but then any >>> malicious program (or smart user) can launch most executables by using the >>> runas /savecred without needing to enter the admin password. While I do >>> believe this is still better then always running as admin, it's not the >>> best option. >>> How do others in their environments handle these situations? >>> One option that has been brought up is granting users admin rights and >>> using a white list software to prevent launching any programs that aren't >>> approved. I'm not sure how easy these are to work around or maintain as I >>> haven't tested any whitelisting software yet. >>> >>> Thanks guys! >>> BTW, PDC guys/girls did a great job hosting and presenting at Security-B >>> sides in RI! I had a great time, and a thank you to Mike Perez who provided >>> some great info for security noobs like me :) >>> >>> - Michael Salmon >>> >>> _______________________________________________ >>> Pauldotcom mailing list >>> [email protected] >>> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >>> Main Web Site: http://pauldotcom.com >>> >> >> >> >> -- >> Mike Perez >> Executive Producer, PaulDotCom Security Weekly >> >> PaulDotCom Enterprises >> Web: http://pauldotcom.com >> >> _______________________________________________ >> Pauldotcom mailing list >> [email protected] >> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >> Main Web Site: http://pauldotcom.com >> > > > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com >
_______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
