We all insist, as far as we can, that our end-users are not administrators. Or at least I really hope we do. There are a number of pieces of research that show how the cost of administration rises dramatically when users are given administrative rights as they are then able to wreak havoc over the once nicely locked down, and functioning, system.
However, what about those of us who are administrators because we do indeed trust ourselves? We all naturally run anti-virus products and possibly a few other products too that will offer some protection such as personal firewalls and VPN clients. But what do we actually need to protect ourselves from? There will always be the silly/accidental/idiotic file or folder deletion, which is why we have confirmation dialogs and backups, but what is there to stop us from running potentially malicious, trojaned, code, particularly if it manifests itself as something legitimate such as an executable called notepad.exe with the right icon and other trimmings? Not all malware unfortunately is classed as such by anti-virus vendors and there is always a window of opportunity between malware being released into the wild and anti-virus signatures being available that blocks them.
Enter the AppSense Application Manager product and its “Self-Authorization” feature. As you may know, Application Manager has a powerful feature called “Trusted Ownership Checking” which allows an out of the box configuration to instantly protect against malware threats without the tedium of white lists, black lists or (frequent) signature updates. It achieves this by looking at the owner of any executable file, and any file that is not owned by a Trusted User or Group, as in an account that we expect to own the executables we wish to execute, such as “Administrators” or “System”, is prevented from running.
Whilst administrators generally do not subject themselves to the full protection of Application Manager by making themselves “restricted” users, as they feel it may make their job harder, there is a “half way house” between being a “restricted” and “unrestricted” user – This is the “Self-Authorizing” user. Any attempts to execute files, which includes scripts and dll’s as well as .exe’s, will produce a pop-up warning that the file is not owned by a “Trusted Owner” and asking if the file should be allowed to execute or not.
You must still however, when presented with the pop-up message, make the decision as to whether you trust the file you are about to execute or install. For example, a non-administrative, restricted user downloads a (seemingly legitimate) file/installer and asks you as a (Self Authorizing) Administrator to install the application for them as they are prevented from doing so by Trusted Ownership Checking. You will of course expect to see the pop-up message as you attempt to execute the file, but you must now ask yourself if you really do trust this user, and that they have not accidentally downloaded malware.
Secondly, if you are running a standard tool on your Windows build and an Application Manager Self-Authorization dialogue is unexpectedly seen, then this should set alarm bells ringing and the reason for the dialogue should be investigated before the file is run, just in case it is malware and has a nasty payload.
In the example above, I was in a command prompt window as a local administrator (actually started via a “Run As” since I was logged on interactively as a non-administrator, naturally) and I needed to run regedit, as you do. Little did I know, in this ever so slightly contrived scenario, that there was already a regedit.exe executable in that folder. Obviously the dialogue tells me where the executable resides so I know immediately that I am not running what I thought I was. On a Terminal Server/XenApp server or a shared workstation, this could easily happen, either accidentally or deliberately. You could of course set the global SafeDllSearchMode registry value (http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx) to stop this particular threat but this is just one example of a number of ways that you could unwittingly run programs that you didn’t actually want to.
Similarly, also watch out for PATH environment variables that have potentially untrustworthy folders in them, particularly when they precede key folders such as %systemroot% and %systemroot%\system32. Or just use Application Manager with the self-authorization feature for your administrative users.
AppSense 