Nearly 300 Windows 10 executables vulnerable to DLL hijacking

[silversurfer]

Content source

https://www.bleepingcomputer.com/news/security/nearly-300-windows-10-executables-vulnerable-to-dll-hijacking/

A simple VBScript may be enough to allow users to gain administrative privileges and bypass UAC entirely on Windows 10.

In a new report from a PwC UK security researcher Wietze Beukema, we learn that almost 300 Windows 10 executables are vulnerable to DLL hijacking.

“It turns out nearly 300 executables in your System32 folder are vulnerable to relative path DLL Hijacking. Did you know that with a simple VBScript some of these EXEs can be used to elevate such executions, bypassing UAC entirely?” explained Beukema.

The vulnerability referred to here is relative path DLL hijacking, which is when an attacker can cause a legitimate Windows executable to load an arbitrary DLL of the attacker’s choice, most likely with malicious intent.

DLL hijacking attacks can prove useful to a skilled attacker as they grant capabilities such as arbitrary code execution, privilege escalation, and persistence on the target system.

The various techniques of DLL hijacking covered by the Beukema's blog post include DLL replacement, DLL Proxying, DLL search order hijacking, Phantom DLL hijacking, DLL redirection, WinSxS DLL replacement, and relative path DLL Hijacking.

 

[Gandalf_The_Grey]

From that article:

Detection and prevention techniques
Beukema presents a few prevention methods that can be used to deter such attacks, such as looking for activity in the mock windows \ folder, should one be present on your machine. Also, adjusting UAC settings to “always notify” could help prevent attacks like this, should the end-user be savvy enough to understand what is about to be executed.

Another strategy is monitoring instances of DLL creation and loading from unexpected file paths:

“You could hunt for the creation or loading of any of the DLLs mentioned before from unexpected paths, particularly in temp locations such as %appdata%. After all, the name of the (legitimate) application loading the DLLs can be changed, but the filenames of DLLs are always fixed.”

When building applications, Beukema suggests, developers should enforce using absolute and not relative paths for loading DLLs, among several other techniques.

None of these may alone be sufficiently foolproof. However, when appropriately applied in conjunction, preventative measures such as those explained by the researcher can deter DLL hijacking attacks by a long shot.

So set UAC to “always notify” helps security.
Often advised by @harlan4096 and me on Computer Security Configurations.

 

[Arequire]

From that article:

So set UAC to “always notify” helps security.
Often advised by @harlan4096 and me on Computer Security Configurations.

And if they won't listen to you two (which they should), you can always point them to one of Microsoft's senior programmers:

There’s a control panel that lets you specify how often you want to be prompted by UAC. You can set any of four levels:

• Always notify
• Notify only when apps try to change settings, use the secure desktop
• Notify only when apps try to change settings, don’t use the secure desktop
• Never notify

Although it looks like there are four settings, in a theoretical sense, there really are only two settings.

• Always notify
• Meh

The reason why all the other options collapse into Meh is that the Notify only when apps try to change settings option can be subverted by any app simply by injecting a thread into Explorer and doing its dirty work there. Since Explorer is a program that the setting allows to elevate silently, this lets you perform a silent elevation from any thread that has thread injection rights into Explorer (which is pretty much any program running at medium integrity level or higher).

In other words, Notify only when apps try to change settings is really Punch a hole in the airtight hatchway.

There are really only two effectively distinct settings for the UAC slider - The Old New Thing

Off and on.

devblogs.microsoft.com

 

[Andy Ful]

That is not an especially efficient vector of infection because it requires two 0-day malware. The attacker has to use a malicious 0-day DLL dropper and malicious 0-day DLL. This method can bypass default UAC on Admin account (but not "Always notify"). It will not work on SUA. Bypassing UAC by this method requires also to fool the system protection that the folder containing malicious DLL is a trusted system folder - this can be quickly learned by AV ML modules.

Such techniques are often used in multistage attacks, when the infection chain is intentionally inefficient and uses system files to fool Administrators in enterprises. This can also bypass some anti-0-day security modules based on monitoring EXE files (without monitoring DLLs).

 

[silversurfer]

Bypassing Windows 10 UAC with mock folders and DLL hijacking

A new technique uses a simplified process of DLL hijacking and mock directories to bypass Windows 10's UAC security feature and run elevated commands without alerting a user.

www.bleepingcomputer.com

UAC bypass via dll hijacking and mock directories

UAC UAC Bypass dll hijacking mock folders Daniel Gebert SRP Software Restiction Policies dll hijacking Windows 10

daniels-it-blog.blogspot.com

 

[Gandalf_The_Grey]

Just read the same articles and an important quote from the Bleeping Computer article is:

Gebert's straightforward mitigation advice to prevent UAC bypass attacks is setting UAC to "Always Notify."
Doing so will always show the user UAC prompts before high-risk applications are executed.

 

[Andy Ful]

The author in one of the articles wrote:

"What else can an attacker do?
Software Restriction Policies (SRP) Software Restriction Policies can be bypassed. For instance SRPs are used by "Hard Configurator" https://hard-configurator.com to harden the system."

UAC bypass via dll hijacking and mock directories

UAC UAC Bypass dll hijacking mock folders Daniel Gebert SRP Software Restiction Policies dll hijacking Windows 10

daniels-it-blog.blogspot.com

I wrote about DLL hijacking here:

Advice Request - Testing DLL Search Order Hijacking against security features.

The DLL Search Order Hijacking is a well known (but not common) vector of attack. It is often performed via a vulnerable Microsoft EXE file or EXE signed by the well known reputable vendor. A popular way of exploiting this vulnerability is based on loading by the vulnerable EXE, one of the...

malwaretips.com

As the author noticed this method can bypass some security configurations of SRP (also Anti-EXE and some AV modules that protect EXE).
In the case of the H_C Recommended Settings, the bypass is not possible, except when the attack uses a working exploit to get access to the command-line. This is not a case on well updated Windows with well updated software.