Re: Running applications that require admin rights in Windows?

[Michael Dickey <lonervamp () gmail com>]

I'm not going to help a ton since I'm a few years removed from being useful
on the desktop, but where I work, we either don't allow that software or we
make exceptions based on roles.

For software that just needs admin rights, we do whatever we can to say no
to having it in our network. If we absolutely must, we do entertain the
idea of hosting it on a virtual Windows desktop system and granting
as-needed access to it or something. Thankfully this doesn't come up all
that much and we have a robust virtual environment and we've successfully
said no to software over the years for various reasons including being
incompatible with our security posture. We also often get slightly involved
in looking up better alternatives or...guiding...decisions away from
problem tools.

But there are roles that simply require it, the most notorious being
software developers, particularly all the coding and compiling tools like
Visual Studio. In that case, we inventory what they have, make sure we have
a computer use policy in place that they sign, and allow them to be local
admins. I also personally keep them in mind for being a bit more strict in
auditing or watching their logs for weirdness, and we do have other defense
in depth anyway (web filter, local ips, network ips, outbound fw denies,
etc).

Allowing local admin does compound problems with supporting those users.
They install junk, screw things up easily, and so on. We make sure our
developers know this, and in turn they actually do quite a bit of the
management of their systems as opposed to relying entirely on our
centralized deployment tools (e.g. altiris, vdi, sscm...) to install their
stuff. Sort of the trade-off to make sure people can still do their jobs.

Getting fancy very quickly leads into support problems. No one will ever
anticipate what was built or how it was done, from the software vendor,
related software, or support persons down the road. Sometimes being crazy
and special and custom yields admirably tight security, but at a tradeoff
of inefficient support down the road. I like things simple. :)




On Sun, Jun 16, 2013 at 9:25 PM, Michael Salmon <lonestarr13 () gmail com>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
> Pauldotcom () mail pauldotcom com
> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
> Main Web Site: http://pauldotcom.com



On Sun, Jun 16, 2013 at 9:25 PM, Michael Salmon <lonestarr13 () gmail com>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
> Pauldotcom () mail pauldotcom com
> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
> Main Web Site: http://pauldotcom.com



On Sun, Jun 16, 2013 at 9:25 PM, Michael Salmon <lonestarr13 () gmail com>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
> Pauldotcom () mail pauldotcom com
> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
> Main Web Site: http://pauldotcom.com
_______________________________________________
Pauldotcom mailing list
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com