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\Explor er] "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. 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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:35:37 PDT