SafeBreach Labs discovered a new vulnerability in the Code42 on-premise server for Windows
In this post, we will demonstrate how this vulnerability can be used in order to achieve persistence, defense evasion and in some cases privilege escalation by loading an arbitrary unsigned DLL into a service that runs as SYSTEM.
Code42 is best known for developing and marketing the CrashPlan data backup service.
CrashPlan backs up data to remote servers or hard drives.
Part of the software runs as a service which is executed as “NT AUTHORITY\SYSTEM,” which provides it with very powerful permissions.
In our initial exploration, we targeted the Code42 server service based on the assumption that such a critical service would have a high-level permission to the PC hardware as well as the capability to induce privilege escalation.
After the Code42 server service was started, it executed CrashPlanPROServer.exe as NT AUTHORITY\SYSTEM.
Once the library was loaded, we noticed that the service tries to look for a missing DLL file in order to load it:
Note: We filtered the irrelevant events from the above screenshot.
As you can see, the service was trying to load a missing DLL file
Demonstrating a DLL Hijacking Vulnerability
On our VM, c:\python27 has an ACL which allows any authenticated user to write files onto the ACL. This makes privilege escalation simple and allows a regular user to write the missing DLL file and achieve code execution as NT AUTHORITY\SYSTEM.
It is important to note that an administrative user or process must (1) set the directory ACLs to allow access to non-admin user accounts and (2) modify the system’s PATH variable to include that directory.
In order to test this vulnerability, we compiled a proxy DLL (unsigned) out of the original `MSVCR120.dll` file, which loads another DLL which writes the following to the filename of a txt file:
- The username which executed it.
- The name of the DLL file.
We were able to load three arbitrary DLLs and execute our code as NT AUTHORITY\SYSTEM.
Root Cause Analysis
Once the Code42 server service is started (CrashPlanPROServer.exe), it tries to load a DLL file by calling the LoadLibraryW WinAPI function:
As we can see in the screenshot, there are two root causes for the vulnerability:
- Uncontrolled Search Path – The lack of safe unmanaged DLL loading.
The service tries to load the DLL files using LoadLibraryW, instead of using LoadLibraryExW which can control the paths from which the DLL files can be loaded.
- No digital certificate validation is made against the binary (e.g. calling WinVerifyCrypt). The program doesn’t validate whether the DLL that it is loading is signed. Therefore, it can load an arbitrary unsigned DLL.
Potential Malicious Uses and Impact
Below we show three possible ways that an attacker can leverage the vulnerability we discovered and documented above.
Signed Execution, Whitelisting Bypass, and Defense Evasion
The vulnerability gives attackers the ability to load and execute malicious payloads using a signed service. This ability might be abused by an attacker, for example to achieve Application Whitelisting Bypass for purposes such as execution and evasion.
The vulnerability gives attackers the ability to load and execute malicious payloads in a persistent way, each time the service is loaded. That means that once the attacker drops a malicious DLL in a vulnerable path, the service may load the malicious code each time it is restarted.
The service provides the attacker the ability to operate as NT AUTHORITY\SYSTEM which is the most powerful user in Windows.
- Code42 Server for Windows – 7.0.2 on-premises server and earlier.
The vulnerability was fixed in the 7.0.3 on-premises server release.
Aug 29th, 2019 – Vulnerability reported to Code42
Aug 30th, 2019 – Code42 confirmed the vulnerability
Sep 20th, 2019 – Status Update from Code42
Sep 23th, 2019 – Code42 provided an estimated release date for the patched version
Oct 2nd, 2019 – Code42 issued CVE-2019-16861
Oct 15th, 2019 – Code42 provided the affected products and versions, and asked us to wait 30 days before publishing the blogpost in 30 days
Oct 15th, 2019 – SafeBreach agreed to wait 30 days.
Nov 15th, 2019 – Code42 released a security advisory.