evaluating the vulnerability of DLL planting

Every now and then, DLL planting ( also known as binary planting, hijacking, or preloading ) resurfaces, and Microsoft’s response to the report is not always known. The parameters taken into account when triaging DLL planting issues will be attempted to be clarified in this blog post.

It is common knowledge that Windows uses a well-defined set of directories in an order known as DLL search order to try and locate dlls when an application loads one without specifying an entirely qualified path. The SafeDllSearchMode’s default search order is as follows:

the directory where the application was loaded from.
the directory of the system. To find the directory’s path, use the GetSystemDirectory function.
the directory of the 16-bit system. This directory’s path cannot be obtained by any function, but it can be searched.
the directory for Windows. To find the directory’s path, use the GetWindowsDirectory function. function to obtain this directory’s path.
the directory at hand.
the directories that the PATH environment variable lists. The per-application path specified by the App Paths registry key is not included in this, please note. When calculating the DLL search path, the App Paths key is not used.

As mentioned in one of our earlier blog posts,” Load Library Safely,” the default DLL search order can be modified with a number of options.

If an attacker can install the malicious DLL in one of the directories searched in accordance with the search order but the plant is not discovered in any of those previously searched, the application becomes vulnerable to the attack. An application loading foo, for instance. An attacker may have the chance to plant foo if there is a dll missing from the application, system, or windows directories. dll if the current working directory is accessible to him. Due to the fact that the DllMain ( ) is called right away upon loading, DLL planting vulnerabilities are very practical, require little work from an attacker, and allow for very simple code execution. If the application permits the loading of non-signed binaries, attackers need not worry about avoiding any mitigation.

The vulnerability can be broadly divided into one of the following three categories based on where the malicious DLL may be placed in the search order:

DLL planting in the Application Directory ( App Dir ).
Planting a DLL in the current Working Directory ( CWD ).
DLL planting in PATH Directories.

Our response is guided by the aforementioned categories. To see how we triage each of these categories, let’s take a look at them.

DLL planting in the Application Directory ( App Dir )

An application keeps its dependent non-system DLLs in its application directory and ensures their integrity. A directory ACL security control is typically used to protect files found in a program’s installation directory because they are thought to be helpful and reliable. The privileges required to write or overwrite files are probably available to anyone who can replace a binary in the installation directory. The application directory is regarded as a code directory, and it is where the application’s code-related artifacts should be kept. A much bigger problem than replacing or planting a single DLL is if an attacker can successfully overwrite the application directory without being listed in the directoryACL.

Let’s examine a few scenarios involving the planting of application directories and DLLs:

Malicious binary planting in a reliable application directory is the first scenario.

Applications that are properly installed typically use ACLs to protect the application directory; in this case, elevated access (typically admin ) is needed to change the directory’s contents. For instance,” C:Program Files ( x86 ) Microsoft Office root Office16″ is the location of Microsoft Word’s installation. To change anything in this directory, you must have admin access. If a victim has admin rights, they can be deceived or socially engineered to place DLLs somewhere reliable, but if that’s the case, worse things can happen.

Malicious binary is inserted into an unreliable application directory in Scenario2.

Untrusted scenarios include applications installed through XCOPY without the need for an installer, shared, downloaded from the internet, and standalone executable in a non-ACLed directory. An installer, for instance ( including redistributable, setup ). self-extracting archives created by IExpress and exe generated by ClickOnce are both downloaded from the internet and run in the default” Downloads” folder. It’s risky to launch an application from an unreliable location because a victim might be duped or tricked into installing DLLs there.

Application Directory DLL planting is one of these issues that is classified as a Defense-in-Depth issue and will only be taken into consideration for updates in upcoming versions. Due in large part to the social engineering involved in the attack and the bug’s by design nature, we resolve any MSRC cases that fall under this category as vNext consideration. A victim would need to be duped into putting malicious DLL ( malware ) in a location where it could be activated AND carry out an action that was n’t advised ( like installing an installer in the malware’s directory ). Unless the application creates the directory itself, it lacks a reference point for” known good directory/binaries.” In order to stop further DLL planting, the installer should ideally create a temporary directory, extract its binaries, and use that directory to install the application. The core of the attack is social engineering, even though an attacker can use a drive-by download to install malware on the victim’s computer, such as into the” Downloads” folder.

We included a new process mitigation in the Windows 10 Creators Update to address the vulnerabilities in Application Directory DLL planting. The application directory and system32 are switched up in the DLL search order when this new process mitigation, PreferSystem32, is selected. Because of this, placing a malicious system binary in the application directory prevents it from being hijacked. In situations where process creation can be managed, this is possible.

Planting a DLL in the Current Working Directory ( CWD )

Even when an application is launched based on the default file association, it typically sets the directory from which it is invoked as the CWD. Clicking a file from the share” D:tempfile,” for instance. ” D:temp” will be used as the CWD for the application connected to the file type .abc by the abc command.

CWD DLL planting problems are made more vulnerable by the scenario of hosting files in a remote share, particularly if it’swebdav. In this manner, a malicious DLL can be hosted alongside the file by an attacker, who can then social engineer the victim into opening or clicking it in order to load it into the target application.

Malicious binary inserted into the CWD is Scenario3.

The untrusted CWD will check for a DLL that is not present in any of the first three trusted locations when loading an application. If Microsoft Word is unable to locate one of its dependent DLL oarts, the victim must open a.doc file from the location server1share2. It will attempt to load it from the CWD server 1share2 dll in the trusted location. Attacker can easily plant an oart because the share is an unreliable location. dll to the application’s feed.

Trigger =&gt, server1share2openme Program Files ( x86 ) Microsoft Office root Office16 Word, Doc Application =&gt, C. exe App Dir=&gt, _C: Program Files ( x86 ) Microsoft Office root_office16_ CWD__ ,_server1share2_ Malicious DLL_ /dl_OART DLL.

We will release a security patch for any DLL planting issues that fall under this category of CWD. These issues are treated as Important Severity Issues. The advisory 2269637 lists a subset of the DLL planting problem that we have resolved in the past. This raises the question of why any Microsoft application would load DLLs that are n’t listed in the Windows directory, System Directory, or Application Directory. Applications occasionally fail to properly consider or verify various optional components, various OS editions, and multiple architectures that come with various sets of binaries before loading the DLLs.

DLL planting in PATH Directories

The PATH directories, which have been added by various applications to make it easier for users to locate the application and its artifacts, are the last option for finding the DLLs in the search order.

A regular user cannot change the contents of the directories that are always admin ACLed in the PATH environment variable. We treat the issue of a global writable directory exposed via PATH as an important severity issue rather than just one instance of DLL planting. However, because we do n’t anticipate crossing any security lines with this planting vulnerability, the DLL planting issue alone is regarded as a low security issue. As a result, PATH directories ‘ DLL planting issues are treated as wo n’t fix.

Conclusion

This should help to clarify how we handle reported DLL planting issues and what circumstances we deem to be severe enough to warrant a security patch. A brief explanation of what we will and wo n’t fix using a security release ( down level ) is provided below.

What a security update from Microsoft will address

CWD scenarios include a DLL being loaded from an unreliable CDD by an associated application.

When a new product is released, what issues will Microsoft take into account?

Application directory scenarios: Depending on whether a product group is an explicit load or an implicit load, this can be used to fully identify it. The implicit loads ( dependent DLLs ) are strictly by-design because the path cannot be controlled, whereas the explicit load can be adjusted.