One of the lesser-used features of Win2K/WinXP/Win2k3's RunAs capability is
to decrease rather than elevate the access of the interactive user when
running a process.
I use this technique as follows with Internet Explorer:
- Create a secondary account to your normal account, and make it a member of
the "Guests" group only (do NOT make it a member of "Users",
"Administrators" or any other group that would elevate its access).
- Using Group Policy, deny network logon to this account (which it inherits
from the Guests group by default.) Grant the account "Log on Locally"
access explicitly.
- Create a new shortcut for IE with the following commandline:
%SystemRoot%\SYSTEM32\runas.exe /u:SecondaryAccountName /SaveCred
"C:\Program Files\Internet Explorer\iexplore.exe"
(Don't use Explorer's native RunAs capability as it won't remember the
password like the commandline version).
- Change the shortcut icon to point at "C:\Program Files\Internet
Explorer\iexplore.exe"
- If you are paranoid, add ACCESS DENIED ACL's to any file, Registry key or
other resource that you do not want the account running IE to access in the
event that you are compromised. In particular, protect any sensitive
locations such as the Startup folders and Run keys.
The first time you run the shortcut, you'll be prompted for the secondary
account's password; thereafter you'll be able to launch IE as easily as you
would under your own account. However since IE is running under a severely
restricted account, you are now significantly less vulnerable in the event
of zone elevation to the Local Computer.
This approach is not without it's shortcomings of course, e.g.
- When IE is embedded in another app or launched via COM it still runs under
your interactive account
- Ditto if IE is started via association (e.g. clicking on a URL)
- Website credentials are cached under a different profile to your own, and
so on...
Microsoft has obviously had some thoughts in this direction
(http://msdn.microsoft.com/security/securecode/columns/default.aspx?pull=/library/en-us/dncode/html/secure11152004.asp),
but their current approach does not strip enough access off the process
security token in my opinion.
IJ
--
NTBugtraq Editor's Note:
Most viruses these days use spoofed email addresses. As such, using an
Anti-Virus product which automatically notifies the perceived sender of a
message it believes is infected may well cause more harm than good. Someone who
did not actually send you a virus may receive the notification and scramble
their support staff to find an infection which never existed in the first
place. Suggest such notifications be disabled by whomever is responsible for
your AV, or at least that the idea is considered.
--
