Microsoft Windows arbitrary code execution (and UAC bypass) via RegEdit.exe

Hi @ll,

part 31 (see <http://seclists.org/fulldisclosure/2015/Mar/92>)
showed how to execute arbitrary (rogue) executables planted as
- %SystemRoot%System32Write.exe,
- %SystemRoot%System32WinHelp.exe,
- %SystemRoot%System32RegEdit.exe,
- %SystemRoot%System32Explorer.exe
etc. instead of
- %SystemRoot%Write.exe,
- %SystemRoot%WinHelp.exe,
- %SystemRoot%RegEdit.exe,
- %SystemRoot%Explorer.exe
etc., including the possibility to bypass the UAC via RegEdit.exe

This works since Microsoft (mis)places these executables (for
historical "reasons") in %windir% alias %SystemRoot% (the path
returned from the GetWindowsDirectory() function), although the
hard-coded search order looks up %SystemRoot%System32 (the path
returned from the GetSystemDirectory() function) before %windir%
alias %SystemRoot%

JFTR: not all executables (mis)placed in %SystemRoot% are there
      for historical "reasons"; some of them were but not present
      in Windows 3.x:
      - %SystemRoot%BFSvc.exe
      - %SystemRoot%FVEUpdate.exe
      - %SystemRoot%HelpPane.exe
      - %SystemRoot%HH.exe
      - %SystemRoot%SplWoW64.exe
      - %SystemRoot%TWUnk_16.exe
      - %SystemRoot%TWUnk_32.exe
      - %SystemRoot%WinHlp32.exe

JFTR: in x64 versions of Windows these historical "reasons" are but
      abandoned completely for 32-bit executables: the 32-bit
      counterparts of all 64-bit executables located in %SystemRoot%
      have been moved to %SystemRoot%SysWoW64.
      This is backwards compatible since %SystemRoot%System32 is
      redirected to %SystemRoot%SysWoW64 for 32-bit executables and
      due to the hard-coded search order, plus
      <https://msdn.microsoft.com/en-us/library/aa384187.aspx>:

      | Access to %windir%regedit.exe is redirected to
      | %windir%SysWOW64regedit.exe. 

(Un)fortunately there is no redirection from %SystemRoot%RegEdit.exe
to %SystemRoot%System32RegEdit.exe for 64-bit executables and in
x86 versions of Windows.

RegEdit.exes load various DLLs; since the hard-coded search order
(see <https://msdn.microsoft.com/en-us/library/ms682586.aspx>) looks
up the application directory first it is possible to have RegEdit.exe
load arbitrary (rogue) DLLs planted into %SystemRoot% instead of
the system DLLs installed in %SystemRoot%System32 (except for the
"known DLLs", see <https://support.microsoft.com/en-us/kb/164501>).

Of course any other executable (mis)placed in %SystemRoot% might be
(ab)used too!

JFTR: it's your turn to fix your poor installation, Realtek et. al.!


Proof of concept (for Windows 2000 to Windows 10; use your own "sentinel"
~~~~~~~~~~~~~~~~  instead of mine for Windows NT4):

1. get <http://home.arcor.de/skanthak/download/SENTINEL.DLL> (this is a
   32-bit executable [*]; 64-bit executables are available on request);

2. copy SENTINEL.DLL as %SystemRoot%ACLUI.DLL (use the method shown
   in <http://seclists.org/fulldisclosure/2015/Mar/92> to bypass UAC);

3. execute %SystemRoot%RegEdit.exe


Mitigation(s):
~~~~~~~~~~~~~~

1. Create "copies" of the executables installed in %SystemRoot% only
   in %SystemRoot%System32 too:

   For %! In (%SystemRoot%*.exe
              %SystemRoot%*.dll) Do If Not Exist %SystemRoot%System32%~nx! MkLink /H %SystemRoot%System32%~nx! %!

   This but only helps if RegEdit.exe etc. are called without their
   fully qualified pathname %SystemRoot%RegEdit.exe etc.

2. Define ACLUI.DLL as "known DLL":

   [HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession ManagerKnownDLLs]
   "aclui"="ACLUI.DLL"

3. Prevent elevation of RegEdit.exe per UAC in "protected administrator"
   accounts:

   [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionAppCompatFlagsLayers]
   "C:WindowsRegEdit.Exe"="RUNASINVOKER"

   [HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionAppCompatFlagsLayers]
   "C:WindowsRegEdit.Exe"="RUNASINVOKER"

4. Demote your "protected administrator" account created during Windows
   setup to a standard user account.

   See <http://windows.microsoft.com/en-us/windows/user-accounts-faq>
   and <http://windows.microsoft.com/en-us/windows/change-users-account-type>:

   | When you set up Windows, you were required to create a user account.
   | This account is an administrator account that allows you to set up
   | your computer and install any programs that you'd like to use. Once
   | you finish setting up your computer, we recommend that you create a
   | standard account and use it for your everyday computing. If you create
   | new user accounts, you should also make them standard accounts. Using
   | standard accounts will help keep your computer more secure.


stay tuned
Stefan Kanthak

[*] see <http://home.arcor.de/skanthak/sentinel.html>

PS: more than 22 years after introduction of Windows NT Microsoft STILL
    continues their VERY BAD and REALLY NASTY habit to give the user
    account(s) created during Windows setup administrative rights!

    No, UAC is NOT a security boundary, but just a convenience feature:
    see <https://support.microsoft.com/en-us/kb/2526083>,
    <https://blogs.msdn.com/b/e7/archive/2009/02/05/update-on-uac.aspx>,
    <https://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx>,
    <https://technet.microsoft.com/en-us/magazine/2007.09.securitywatch.aspx>,
    <https://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx>, ...

    Jane and Joe Average will happily give consent to almost any program
    (like RegEdit.exe) which asks for elevated privileges, DESPITE most
    warnings!

Copyright ©2024 Exploitalert.