How Microsoft Triages the DLL Planting Vulnerabilities

🔊 Listen to Post

On April 21, 2020, the researchers at Cymulate, a SAS-based Breach and Attack Simulation (BAS) platform provider, announced that “it has discovered a method for attackers to run malicious code via Microsoft’s Remote Desktop Protocol (RDP) using a technique called DLL Side-Loading. The executed code would bypass security controls.” Security Week covered this topic in an article titled Microsoft Will Not Patch Security Bypass Flaw Abusing MSTSC.

All this sounds pretty alarming, but is it? As dramatic as it sounds, I am not so sure if I would characterize it as “a new hidden malware defense evasion technique.”, which Cymulate is claiming. If this were such a serious issue, Microsoft would have been all over it. I am also not convinced that this “lets attackers bypass the security controls.”

According to Security Week, “The company told Security Week that, depending on the malicious code being executed, an attacker could potentially exploit the flaw to elevate privileges. For that they would need to convince a user to execute the mstsc.exe file from the attacker’s folder with elevated privileges.” In my opinion, if the attacker has that much control over the user, the attacker practically owns the user’s computer anyway.

Microsoft’s response to this “discovery” is that this isn’t really a DLL side-loading vulnerability which requires a security patch. According to Cymulate’s announcement, “Cymulate has notified Microsoft about the vulnerability who has declined to patch it as they state System32 requires admin privileges and is therefore not a perceived threat.”

Let me explain in more detail why Microsoft does not consider this as a serious security threat. Microsoft already has a process in place for addressing these types of DLL planting vulnerability issues, as explained below.

Triaging DLL Planting Vulnerabilities

Microsoft has publicly announced how it addresses the DLL planting vulnerabilities. The details are posted on Microsoft Security Response Center. Depending on where the the malicious DLL has been planted in the DLL search order, the vulnerability typically falls into one of the following categories:

1. Application Directory (App Dir) DLL planting.
2. Current Working Directory (CWD) DLL planting.
3. PATH Directories DLL planting.

App Dir DLL Planting

Microsoft will issue a security patch for any App Dir DLL planting issue, because Microsoft considers this to be a “Defense-in-Depth issue.” It’s interesting to note that in Windows 10 Microsoft added a new process mitigation called PreferSystem32, which toggles the order of application directory and system32 in the DLL search order. This blocks the ability to hijack a system binary (e.g. mstscax.dll) and planting it in the application directory.

CWD DLL Planting

Microsoft will also issue a security patch for a CWD DLL planting issue because it considers this as an “Important security issue.” In fact, if you look at the DLL plating issues fixed by Microsoft in the past, you will notice that most of them fall into this category.

PATH Directories DLL Planting

In addition to the App Dir and CWD, the PATH directories are the last resort in the DLL search order. These are added by different applications so the user can easily locate the applications and its DLLs. Microsoft has announced that it won’t address a DLL planting issue related to the PATH Directory because it’s not a vulnerability that can be exploited.

The directories that are in the PATH environment variable in Windows are always protected by Access Control Lists (ACLs) associated with the Administrator account. In other words, standard users cannot modify the content of these directories. If for some reason, an attacker is able to write to a directory in the PATH environment variable as a non-administrator then that will be considered an “Important security issue” and Microsoft will issue a security patch for that. However, just the single instance of PATH Directories DLL planting is considered a “Low security issue” because an attacker can’t cross security boundaries.

The bottom line: Microsoft’s argument is that because there can’t be a non-admin directory in the PATH, the PATH Directories DLL planting can’t be exploited. That’s why Microsoft doesn’t feel this to be a crucial security issue that needs an immediate attention and a security patch.

It’s probably easier for an attacker to use social engineering/phishing attack to gain administrative access to a user’s computer, rather than convincing a user to run the mstsc.exe file with administrative privilege from the attacker’s folder.

Copyright © 2020 SeattlePro Enterprises, LLC. All rights reserved.