Analyzing CVE-2022-46330 (DLL Hijacking in Squirrel.Windows)

About The Project

In December of 2022, a DLL Hijacking vulnerability with a CVSS score of 7.8 was reported in the Squirrel.Windows auto-install/update utility. This blog post will analyze the vulnerability, and analyze the root cause of said issue with procmon.

Analyzing the Security Advisory

Squirrel.Windows is an installation utility for Windows desktop applications that does not require a traditional Windows wizzard installation. CVE-2022-46330 states that,

Squirrel.Windows is both a toolset and a library that provides installation and update functionality for Windows desktop applications. Installers generated by Squirrel.Windows 2.0.1 and earlier contain an issue with the DLL search path, which may lead to insecurely loading Dynamic Link Libraries. As a result, arbitrary code may be executed with the privilege of the user invoking the installer.

An interesting thing about the Squirrel.Windows installation package is that it leverages Nuget, a Windows package managing application. Nuget’s website allows you to see what applications use said package, and the number of downloads for a given package. This revealed a high number of downloads for the software itself shown below, along with identifying a vulnerable application.

nuget_top_downloads

identifying_software

DLL Hijacking is nothing new, and I have blogged about it before, but it continues to plague Windows environments. Given the relatively high number of downloads of this package, I thought it would be interesting to further explore this further. At the time of this publication there’s no release version that contains the patch, but it does exist in the devel branch for end users to go forth and build.

Analyzing the Patch

CVE information page linked to Squirrel.Window’s GitHub repo pull request 1807. This pull request contains a commit to fix the DLL hijacking issue, aptly titled “Simplyfy DLLHijack mitigation and ensure urlmon is delay loaded”. This patch removes additional DLLs, specifies a default search library to be System32 for urlmon.dll, and also leverages a featuer of Microsoft Visual C++ called “delay loading”. The image below shows urlmon’s path being set to System32 prior to LoadLibrary being called.

patch

As a quick recap of this technique, DLL Hijacking occurs when an attacker can plant a DLL which is then loaded into a given target process. When an application loads additional libraries (DLLs), a specific search order is followed. Per-official Microsoft Documentation This path includes:

  1. The directory from which the application loaded.
  2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
  3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.*
  4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
  5. The current directory.
  6. The directories that are listed in the PATH environment variable.

Since urlmon.dll is a legitimate Windows System DLL, it should always look for this DLL in the System32 folder, but in Squirrel.Windows versions prior to 2.0.1 it would check the directory from which the application is loaded from first The patch previously discussed fixes this by forcing loading from System32. In absence of this patch, its possible for an attacker to plant a DLL to take advantage of the DLL hijacking opportunity due to the search path checking the directory from which the application is loaded. Exploiting this vulnerability will be explored in the next section.

Recreating The Issue

Monitoring the launch of an application leveraging a vulnerable version of Squirrel.Windows via procmon, the DLL hijacking vulnerability is visible in the image below. The procmon output show the target DLL, urlmon.dll being loaded from the source directory the application is being launched out of, in this case the User’s Downloads folder.

dll_hijack

By placing a DLL within the user’s Download folder with a name of urlmon.dll, it’s possible to load a custom DLL to execute arbitrary code. For proof-of-concept purposes, we’ll demonstrate a crash, but placing a DLL that does nothing within the Download’s folder. Upon launching the application, the urlmon.dll is loaded and a crash is triggered. The image below shows the DLL loaded within the target process of Setup (1).exe. This validates the CVE and demonstrates the DLL hijack vulnerability. More creative uses of this proof-of-concept are left as an exercise to the reader.

poc.png

Sysmon & Detecting DLL Loading w/ Sigma Rules

Microsoft’s Sysmon, utiltiy has the ability to provide signficant telemetry about events on a given host depending on the configuration applied. Sysmon can be configured to detect loading of DLLs and their associated hashes/signatures/etc… for threat hunting/forensic review. For this vulnerability to be exploited, an attacker would be loading a DLL out of a non-standard DLL directory with a known Windows DLL name that is not signed by Microsoft The detection opportunity here is high, but collecting all image load events across an enterprise environment of Windows hosts may not be realistic. Numerous Sigma rules exist for DLL hijacking and could be adapted to Squirrel.Windows if this software is used in your environment.

Beyond The Blog

As stated earlier, the are no available fixes available via Nuget or GitHub releases at the time of this publication. To take advantage of the aformentioned patch, a custom build from the Squirrel.Windows’ development branch is required. The original discussion of a end-user and the developer can be seen here.