|
|
|
|
| |
| The generic security issue of weak permissions on registry keys under Windows NT 4 has been known for sometime (see Stephen Sutton's Windows NT Security Guidelines) but here's a new reminder of why it is so important to strengthen the permissions on dangerous registry keys. |
| |
Credit:
The information has been provided by David Litchfield.
|
| |
Local privilege escalation can be achieved on Windows NT 4, due to weak default permissions on a registry key that controls the Microsoft Installer Service. When a user double clicks on a .msi file the Microsoft Installer Service (MSIEXEC) is started. As part of the MSIEXEC startup process it reads in the name of the DLL set in the following registry key:
HKLM\Software\Classes\CLSID\{000C103E-0000-0000-C000-000000000046}\InProcServer32
By default, this is set to C:\winnt\system32\msi.dll
Once this DLL has been loaded into the address space of MSIEXEC, the DllGetClassObject() function exported by msi.dll is called. Due to the permissions on this registry key any user that may log on to the system locally, can modify the value - as the Interactive user. By creating their own DLL that exports a function called DllGetClassObject() and pointing this key to their own DLL, rather than msi.dll they can gain complete control over the system. For example, the following code, when compiled into a DLL will give an Interactive command shell with SYSTEM privileges when the user then double clicks on an MSI file.
#include <stdio.h>
__declspec(dllexport)int DllGetClassObject()
{
system("cmd.exe");
return 0;
}
To resolve this issue, and many others like it, ensure that only Administrators may set registry key values under HKLM\Software\Clsid - Interactive only needs the read permission. On web servers that allow publishing, it is crucial to ensure that these issues don't exist as this attack can be launched using ASP.
|
|
|
|
|
|
|
