COMMAND
Inherent weaknesses in NT System Policies
SYSTEMS AFFECTED
Win NT 4.0
PROBLEM
Mnemonix found following. There are certain key vulnerabilities
in NT's System Policies that allow most restrictions to be
by-passed. For instance, although Registry Editing tools can be
disabled this restriction can be avoided with ease, but more on
that later. Consider a restrictive user System Policy where the
user's shell is Explorer.exe and it only allows the Microsoft Word
application (winword.exe) to be run. It is launched from an icon
on the desktop. This is the only icon present. So the user can
perform their work, write documents and save them, they are give
write NTFS permissions only to their profile directory. The
Registry editing tools have been disabled. This policy can be
broken in a matter of minutes.
On running MS Word a user clicks on File on the Menu Bar, and goes
down to Open. They are shown a list of directories and files.
The user could try to right click on a folder and go down to
Explore but the right-click menu has been disabled; so instead
they drag a folder to the Start Button on the Taskbar and release.
This will place a shortcut to that folder on the Start Menu. This
shortcut will be stored in their profile directory. On clicking
on it, Explorer is opened up, which not normally have direct (ie
non-shell) access to. The default WINNT directory has been hidden
from view by the system policy - however, by clicking on Tools
on the Explorer Menu Bar they choose Go To and enter the path to
the WINNT directory. On pressing enter the WINNT directory
appears as if from no-where. The user then changes to the
SYSTEM32 directory where most of the applications are stored.
Because, however, winword.exe is the only approved application
there would be little point in attempting to run any of them.
Instead the user highlights the NT Command Prompt executable
(cmd.exe) and copies it, by using the Copy option found under Edit
on the Menu Bar. He then pastes it to his profile directory and
then renames it to winword.exe. Once it has been renamed the user
can run it. Once cmd.exe is running as winword.exe any
application can be run from here without restriction save for the
Registry Editing tools. This happens because the policy
restrictions only apply to the user's shell and not to any other
running application. The app is started from cmd.exe (masqueading
as winword) and not Explorer neatly by-passing the allowable
applications restriction.
What is interesting to note, however, is that if only the file
name is supplied eg file.txt notepad will not be launched and an
Access Denied message will be returned. This is because cmd.exe
must reference Explorer, which is the user shell with all the
restrictions, to see what application is associated with the .txt
extention. Consequently Notepad would be launched from Explorer,
in this case, and not the Command Prompt, even though it initated
the process.
What about the Registry? How can restrictions placed on this be
by-passed. This is done with the use of .reg files. .reg files
are text files that contain entries that are used to change
registry settings. Below is a sample .reg file:
NORUN.REG
---------------------------------
REGEDIT4
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoRun"=dword:0
---------------------------------
By default the .reg file extention is associated with Regedit.exe
with a default action of Merge, in other words update the
Registry. So when a .reg file is double clicked the registry will
be updated providing the user has the necessary permissions to the
Registry Key specified in the file. Even if Registry editing
tools have been disabled with a System Policy, when a .reg file is
clicked on, the Registry Key(s) and Values will still be modified.
This blows away the whole point of having this restriction. Even
if .reg has be dis-associated from Regedit.exe, by default a
normal user has the relevant permissions to re-associate it. This
is done from the Folder Options option found under View on the
Explorer Menu Bar. All a user then needs do is make a copy of
regedit.exe, rename it to winword.exe and then associate the .reg
extention with the path to the regedit winword.exe. They can then
create their own .reg file using the real winword and save it to
their profile directory. Needless to say the user must know the
exact Registry Key path they wish to modify and the value the wish
to tweak.
SOLUTION
To stop this from happening the Administrator should only give
Admins access to regedit.exe and regedt32.exe using NTFS file
permissions and deny access to everyone else. Some may go as far
as wanting to delete them completely, but this could lead to
support issues if they were needed at some point by Helpdesk
staff. As can be seen, even a restrictive but at least useable
System Policy can thus be broken. It is not simply enough to
create a policy. A lot more work needs to go into this if Admins
wish to limit and restict what their users can and cannot do.
Give the full pathname to the programs you want to allow them to
run. This makes it a lot safer. There are ways around even this
of course. NT is not secure against a determined user, just boot
from a floppy and replace the registry if you really want to.