Date: Wed, 3 Feb 1999 22:41:52 -0000 From: mnemonix To: BUGTRAQ@netspace.org Subject: Inherent weaknesses in NT system policies 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. ----------------------------------------------------------------------------- Date: Fri, 19 Feb 1999 11:25:14 -0700 From: Kurt Seifried To: BUGTRAQ@netspace.org Subject: Re: Inherent weaknesses in NT system policies As any good little MCSE learns: 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. I haven't looked in depth yet but MSIE 5.0 comes with it's own policy restrictions/etc (quite a few actually), I'm not 100% sure how they interact with NT's user policies/etc, but once I get a chance to play with it some more I'll post that up. -seifried, MCSE https://www.seifried.org/ ----------------------------------------------------------------------------- Date: Fri, 19 Feb 1999 13:01:29 -0600 From: Matt Hargett To: BUGTRAQ@netspace.org Subject: Re: Inherent weaknesses in NT system policies On Wed, 3 Feb 1999, mnemonix wrote: > 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. > > This policy can be broken in a matter of minutes: [snip] I concur that policies are not the only thing an admin must set up if he wants to secure his workstation. I have some recent experience myself doing this from when I went to help my college on a similar project in November. Firstly, if you are going to be setting up workstations to be this restrictive... a) the user should have a read-only profile (there's a term for this, I can't remember what NT calls it). This prevents them being able to put anything in the Start Menu. b) registry ACLs should be altered so as not to include anything beyond Query/Enumerate/Read for the World SID. This breaks some applications, and it takes some tuning once you have the registry locked down to get everything completely functional. Corel Wordperfect and Netscape were a real pain in this respect, and have rather insecure dependencies on some regkeys being Full Control for the World SID. c) in the %systemroot% directory, we removed execute permissions for World, and added them back to the bare minimum utilities (which didn not include cmd.exe =]). We also looked for miscellaneous executables in the application installs that were not part of the main application that would not get run during normal use. d) in the TEMP dir (whatever that is defined to be on your system), set the directory permissions to be Create for World, and Read/Write/Delete for Owner (and Full Control for System and Administrator, of course). This hypothetically prevents people from creating file with executable permissions. However, Owners of objects intrinsically have Change Permissions access. I think there is a way to disable this, but I don't remember how we did it. So, if the admin setting up the workstation (I would assume for public use by the needs inferred), policies alone will not do. And even with file and registry permissions, someone clever could still get around it; it's just a little more difficult. ----------------------------------------- Matt Hargett http://www.cityscape.net/~hargett matt@use.net if you see me walkin in the garden, don't ever ask me for an autograph and if you ever catch me in the arcade, don't even stop me for a photograph ----------------------------------------------------------------------------- Date: Fri, 19 Feb 1999 20:48:55 -0600 From: Collin Chaffin To: BUGTRAQ@netspace.org Subject: Re: [NTSEC] Inherent weaknesses in NT System Policies David Litchfield Wrote: >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 can be avoided by selecting a custom start menu location from the network where they do not have write access. This also aids in overall remote desktop management. --------- >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 --------- The "tools" and "view" can be restricted via policies as well. End of that particular scenario. --------- >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. --------- The "view" can be restricted via policies as well. --------- >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. --------- I agree. --------- >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 restrict what >their users can and cannot do. --------- I disagree, a well designed policy can very effectively restrict typical end-users. It will be very difficult to successfully manage Windows2000 without intimate knowledge of system policies. --------- Collin Chaffin ----------------------------------------------------------------------------- Date: Tue, 2 Mar 1999 10:33:17 -0500 From: David LeBlanc To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: Only one reason to obscure the admin account? Wanted to add just a bit - At 09:35 AM 2/27/99 -0800, Dominique Brezinski wrote: >I can't even begin to tell you now many NT boxes I have seen with 139 open, >the Server service enabled, and a renamed admin account. This provides no >added protection, and usually the admins get more lax about controls on the >admin accounts due to the false sense of security. Nobody renames root on >*nix, they just don't allow remote logins as it ;) Something to remember when dealing with Windows NT is that the right to log on from the network doesn't always regulate all the entry points which are provided by the network. For example, consider a machine where 139 is available, and the administrator account is not allowed to log on from the network. Due to the order in which NT processes logon requests, it is possible to determine when you have guessed the admin's password, even if logons are not possible. You can then take that user-password pair and use it to gain entry via services that regulate logons by other than the right to logon from the network. Denying the admin the right to logon from the network is a really good first step, but restricting the NetBIOS ports to access from networks that you at least trust somewhat is essential. IMHO, people who write network services for NT should check that right when authenticating users, but many of them do not. So go through and check ALL your entry points - NetBIOS, DCOM, and any other services which may allow authentication. I second the rest of what Dom said - if 139 is open, I can get the admin user trivially. Note that I can also get the user comment - found one guy where I got a user named 'administrator' where the comment was "bogus account to catch hackers" . David LeBlanc dleblanc@mindspring.com -----------------------------------------------------------------------------