A.P. Lawrence

NT registry and Security Policy

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From - Fri Feb 19 13:03:38 1999
Return-Path: <owner-bugtraq@netspace.org>
Received: from brimstone.netspace.org by world.std.com (TheWorld/Spike-2.0)
        id AA08133; Fri, 19 Feb 1999 12:44:56 -0500
Received: from netspace.org ([128.148.157.6]:21552 "EHLO netspace.org" ident: "TIMEDOUT2") by brimstone.netspace.org with ESMTP id <79033-1440>; Fri, 19 Feb 1999 12:20:01 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8d) with
          spool id 987969 for BUGTRAQ@NETSPACE.ORG; Fri, 19 Feb 1999 17:07:49
          +0000
Approved-By: aleph1@UNDERGROUND.ORG
Received: from sand2.global.net.uk (sand2.global.net.uk [194.126.80.50]) by
          netspace.org (8.8.7/8.8.7) with ESMTP id RAA28164 for
          <bugtraq@netspace.org>; Thu, 18 Feb 1999 17:47:06 -0500
Received: from pbbs14a06.client.global.net.uk ([195.147.222.188] helo=mercury)
          by sand2.global.net.uk with smtp (Exim 2.05 #1) id 10DcE5-0003Rk-00;
          Thu, 18 Feb 1999 22:47:21 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Message-Id: <000301be4fc6$65e025a0$216610ac@mercury>
Date:   Wed, 3 Feb 1999 22:41:52 -0000
Reply-To: mnemonix <mnemonix@GLOBALNET.CO.UK>
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: mnemonix <mnemonix@GLOBALNET.CO.UK>
Subject:      Inherent weaknesses in NT system policies
X-To:         ntbugtraq@listserv.ntbugtraq.com
X-Cc:         ntsecurity@iss.net
To: BUGTRAQ@NETSPACE.ORG
X-UIDL: 93f7fce6dda046db6cec647b5248f767
Status: U
X-Mozilla-Status: 8001

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.

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

/Bofcusm/7.html copyright 1997-2004 (various authors) All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here