nt.system.policies.txt

`Date: Wed, 3 Feb 1999 22:41:52 -0000  
From: mnemonix <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
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  
[email protected]  
  
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 <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
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" <g>.  
  
  
David LeBlanc  
[email protected]  
  
-----------------------------------------------------------------------------  
`