My job is to craft and implement attack scenarios for Cymulate customers to launch in their environment and increase their cyber-resilience. In this tech-blog post I will talk about a new vulnerability dubbed “PrintNightmare”(CVE-2021-34527) and demonstrate how the attack is implemented in the Cymulate Continuous Security Validation platform, Purple Team module.
The scenario is implemented in the Cymulate Continuous Security Validation platform, Purple Team module. This allows blue teamers a simple way to launch the scenario in their environments using one tool. Whether using Cymulate or implementing à la carte the goal is to evaluate the enterprise IT system configuration’s resilience to this scenario and take steps to increase it.
RpcAddPrinterDriver is a legitimate function designed to allow remote printing scenarios and driver installation. The function is designed to allow users with SeLoadDriverPrivilege. By default Administrators and print operators have these privilege to add drivers to a remote Print Spooler. A typical case would be an IT admin installing a new printer driver for users in the organization.
The Logic Flaw
RpcAddPrinterDriver has a logic flow, where the remote connecting party can specify parameters that invalidate authentication.
The Microsoft Windows print spooler service (which is enabled by default on all Windows systems) fails to restrict access to the RpcAddPrinterDriverEx() function which can result a remote, authenticated attacker executing malicious code with SYSTEM privileges on vulnerable machines.
In our testing we managed to replicate the attack using different public Proof-of-Concept in the following versions of Windows:
- Windows Server 2019
- Windows Server 2016
- Domain Controller Windows Server 2019
- Windows 7
- Windows 8.1
- Windows RT 8.1
- Windows 10
- Windows Server 2004
- Windows Server 2008
- Windows Server 2008 R2
- Windows Server 2012
- Windows Server 2012 R2
- Windows server 20H2
*Note: The June Patch does not fix the vulnerability
In order to exploit the PrintNightmare Vulnerability, we used a public POC released by the security researcher Cube0x0 and available on his Github. The exploit allows an adversary to execute Malicious DLL’S remotely or locally which results in either Remote Code Execution(RCE) or Local Privilege Escalation(LPE). In our example, we will demonstrate the RCE Method. we compiled a simple Unmanaged DLL that will pop a calculator on the vulnerable remote system once the exploit is executed. It is important to note that having a low privilege domain user is enough to gain code execution on a machine that has the spooler service available.
Before we exploit the vulnerability we need to know if the system we are targeting is vulnerable to the attack. Using Impacket rpcdump we can verify if the target is vulnerable by querying the available remote services. If MS-RPRN is listed among the services we know that the spooler service is exposed and the machine is vulnerable.
As shown above, we can see the machine we query is 10.180.180.26 and the MS-RPRN protocol is available.
Hosting the Malicious Payload
Now that we are confident that the machine is exploitable we can proceed to the last pre-requirement to exploit the vulnerability remotely. We need to host our payload on a share that the exploit can communicate with.
In our case we will use Built-In PowerShell commands to create a shared folder on our attacking machine that will allow anonymous access to it and copy our malicious payload to it:
Combining the Pieces
Our Malicious DLL is now hosted on the share we created on the attacking machine we control. Let's use the POC and provide our malicious DLL to it to pop a calculator on the remote machine. We will provide a low privilege user to the exploit, the path to our hosted malicious DLL, and the target we found that is vulnerable.
As seen above we managed to successfully run code on the remote machine resulting in the execution of calculator with the privileges of SYSTEM.
Replicating the Entire Scenario Using Cymulate Purple Team Module
As mentioned in the beginning, the scenario described in this paper is implemented in the Cymulate Purple Team module. This automated instantiation enables repetitive execution of the scenario. For example, to launch the scenario from different start points in the enterprise infrastructure, or to validate proper remediation or detection after taking countermeasures.
As a Cymulate researcher, the transition from concept to implementation is very fluid. The result of a flexible and open framework that is easy to use. We use the same framework as our customers who in preparing custom scenarios from A to Z so that they can be used by red and blue teamers out of the box, repeatedly, managed, and integrated with the current security stack. Following is a description of the implementation.
Cymulate Purple Team Module
The Cymulate Purple Team module is an open framework used to craft and automate custom attack scenarios. The creation of scenarios requires minimal adversarial skills while launching the scenarios and analyzing the results is achievable by security team members of any skill level.
The module makes it possible to perform different penetration testing tasks on a daily basis. The advanced use of the Purple Team module is for red/blue teamers to exercise a full attack on the enterprise environment by combining real-world adversary techniques. For blue teamers, it gives better visibility of what aspects of your current detection and response need to be improved, and it provides a better understanding of some of the more sophisticated attacks used by red teamers with a few clicks, minimal effort, and skill set.
The Module supports the following:
Chained – different executions can be chained together to mimic the path used by a real adversary. An example would be running mimikatz to collect credentials from a machine, using the collected credentials to move laterally and escalate privileges to Domain Admin.
Atomic – testing a specific scenario Atomic Executions are standalone executions.
We can use atomic executions if we want to test different scenarios. For example, Enumerating all members of the domain admins group in a domain environment.
For the scenario described above, we will use the Chained approach. We begin by creating a template and adding the executions to the template.
After adding the executions, we can chain other executions together. Below is an example of chaining the RPCDump execution which will find if the machine is vulnerable, proceed to create a new SMB Share and host our malicious payload in it and execute the exploit to execute code remotely on the vulnerable machine. By chaining multiple input arguments the Purple Module knows it needs to get its information regarding the user and password to use, location of our malicious hosted DLL, and the vulnerable target we would like to target as shown below:
To implement the scenario described in this paper we chained all the relevant executions into a template, from which assessments can be created, launched, and validated.
The result of running the assessment is a full replication of the scenario, resulting in remote code execution on the vulnerable machine with the privileges of SYSTEM.
The Vulnerability is not fixed as of 05/07/2021 Following are some mitigation that will make it harder to exploit.
- Disable the Windows print spooler service in domain controllers and other Windows systems that do not require printing (IMPORTANT: note that this service is enabled by default on all Windows systems). Microsoft recommends using a Group Policy Object to achieve this
- Disable inbound remote printing through Group Policy. The impact of this workaround is that the system will no longer function as a print server, but local printing to a directly attached device will still be possible.
- Prioritize domain controllers when applying the workaround due to the severity and consequences of these systems being compromised
Test the effectiveness of your security controls against possible cyber threats with a 14-day trial of Cymulate's platform.
This blog was written by Yonatan Machluf, a member of our Cymulate Research Team.