This exploit is similar to how https://github.com/L3cr0f/DccwBypassUAC works as it abuses the way "WinSxS" is managed by "dccw.exe" by means of a derivative Leo's Davidson "Bypass UAC" method so as to obtain an administrator shell without prompting for consent. Here we abuse that method in Windows Update Standalone Installer(wusa.exe) by its call to comctl32.dll
- Tested on Windows 10 20H2, hopefully will work on Windows 8.1 as well.
- Supports "x86" and "x64" architectures.
I do not take any responsibility if someone uses the exploit provided in this repository to perform illegal activities.
"Windows Update Standalone Installer" or "wusa.exe" is one of the processes which have autoElevate attribute as true in its manifest. This is why it can run as Administrator without UAC Prompts.
This is proven by Sigcheck:
By filtering execution of wusa.exe caught by Procmon, we found that wusa.exe tried to check by IRP_MJ_CREATE if location wusa.exe.Local is available in C:\Windows\System32, whereas in 32bit it will be checked under C:\Windows\SysWOW64\ as shown below:
However, wusa.exe is trying to look for a DLL called comctl32.dll similar to how dccw.exe looks for GdiPlus.dll. Since it doesn't contain the DLL, wusa.exe looks under WinSxS for a folder with the structure:
[arch]_microsoft.windows.common-controls_[sequencial_code]_[windows_version]_none_[sequencial_number]
This can be exploited by a 32bit process when it copies a Malicious DLL to one of these locations and invokes wusa.exe which will launch its target program and children with high integrity.
Since we know that a mode of vulnerability is possible, we can verify it by creating the "wusa.exe.Local" folder and under that the first WinSxS folder wusa.exe loads comctl32.dll from. On doing that and on capturing the execution of wusa.exe in Procmon, we get the following results:
As we expected, wusa.exe throws an error as it cannot find comctl32.dll under any of those folders we created. This proves that the vulnerability exists in wusa.exe.
On developing one, we followed the same steps as Exploit-Development till Interoperability.
Just like dccw.exe, wusa.exe depends on some functions from comctl32.dll that we need to create or forward to the original DLL. Without implementing or forwarding the execution of these functions to the original DLL, wusa.exe will fail to launch with an error that it can't find those functions in the DLL.
Ofcourse we can use the tool ExportsToC++ to port all exports from comctl32.dll to C++ by pragma, this resolves the issue of defining them.
The reason we are using "C:\Windows\System32" is because this path does not change in Windows unlike the WinSxS folders.
All available functions are resolved and saved as a cpp source. However, we only need to forward the functions wusa.exe needs, not all from comctl32.dll. To check which all functions are imported by wusa.exe, we can use the MSVC tool called DUMPBIN which lists out several information about a binary file. We can use the following command to list out the imports from wusa.exe:
dumpbin.exe /IMPORTS C:\Windows\System32\wusa.exeDUMPBIN shows the following imports of wusa.exe from comctl32.dll:
By this, we can figure out that wusa.exe only imports 2 functions from comctl32.dll and that we have to provide exports for those functions only.
However, one of the functions it imports are by ordinal 344 and not by its name. ExportsToC++ only generates exports by names and some with [NONAME].
But this can easily be dealt with, by the following export:#pragma comment (linker, "/export:#344=c:/windows/system32/comctl32.#344,@344,NONAME")This process of copying the malicious DLL, doing other functions leaves a trace to the system and even the user may come upon what we are doing if something goes wrong. For this reason, all the temporary files created during the process are removed after the exploit is successful.
After the exploit is successful, we can execute any malicious code, open programs or whatever written within our malicious DLL as Administrator without UAC Prompts.
To get successful execution of the exploit the targeted machine must comply the following requirements:
- It must be a Windows 8 or 10, no matter what build version.
- The UAC settings must not be set to "Always notify".
- The compromised user must belong to the "Administrators group".
Most of the source in this repo is modified from https://github.com/L3cr0f/DccwBypassUAC as its a similar exploit. However, we provide CMakeLists.txt as we compiled it under CLion.
Following shows executing the compiled exploit with command line in a x64bit Windows VM:
User Access Control (UAC) is a technology introduced with Windows Vista that provides a method of separating standard user privileges and tasks from those that require Administrator access. If a Standard User is using the system and attempts to perform an action for which the user has no authorization, a prompt from Windows appears and asks the Administrator account’s password. If an Administrator is using the system and attempts to do the same task, there is only a warning prompt. That prompt is known as a "Consent Prompt" because the administrator is only asked to agree to the action before proceeding. A weakness that would allow to bypass the "Consent Prompt" is not considered a security vulnerability, since that is not considered a security boundary.
However, Microsoft also states that "User Account Control (UAC) is a fundamental component of Microsoft's overall security vision".
This was just a source on how one could use WinSxS folders to bypass UAC by DLL-hijacking. However, wusa.exe and dccw.exe are not the only programs with such issue. Most of the autoElevated programs are found to have this vulnerability.
- Credits
- About the exploit: WinSxS, UAC 0day all day(FuzzySecurity)
- Referred from: DccwUACBypass(L3cr0f)
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent