On May 31st, 2023, Progress disclosed a serious vulnerability in its MOVEit Transfer software. The vulnerability is remotely exploitable, does not require authentication, and impacts versions of the software that are 2023.0.1 (15.0.1) or earlier. We are aware of multiple reports of active exploitation of this vulnerability in the wild, and attackers are already mobilizing their efforts to find unpatched MOVEit Transfer deployments.

Any company running this software should immediately patch to a secure version or remove the affected assets from the Internet. In addition, because of the danger posed by shadow IT, we recommend all companies conduct a sweep of their attack surface to ensure that they are not running a vulnerable instance without their knowledge. While this is not a “sky falling” moment for defenders, we do advise approaching this vulnerability with a sense of urgency.

The remainder of this post provides an overview of the vulnerability, then explores how exploitation works and how companies can search for vulnerable assets. We then look at steps organizations can take for remediation, including how to look for indicators of compromise. Finally, we highlight how defenders can use this vulnerability as a way to prepare for the future and improve the overall health of their external attack surface.

Vulnerability Details (CVE-2023-34362)

According to the advisory from Progress, CVE-2023-34362 is an unauthenticated SQL injection vulnerability that allows an attacker to make unauthorized queries to the MOVEit Transfer application’s backend database. This could, for example, allow an attacker to delete data from the backend database or add themselves as a user with permission to authenticate to the application through the web frontend.

Depending on the backend database in use, this could also allow an attacker to execute arbitrary code on the backend database server using the xp_cmdshell stored procedure within Microsoft SQL Server as well. In terms of real world exploitation, Rapid7 has observed the attackers leveraging the SQL injection vulnerability to write arbitrary files to the webroot of the application server. This exploitation vector is possible when the application server and the backend database run on the same server.

Detecting Exploitation of MOVEit Application Servers

Attackers may have been exploiting MOVEit as a zero day vulnerability as early as May 27, 2023, according to Mandiant’s article Zero-Day Vulnerability in MOVEit Transfer Exploited for Data Theft. Since then, Mandiant has created YARA detections for common indicators, including second-stage DLL files and the webshell that is the first stage payload to execute code on a target system. Unfortunately, an absence of the YARA rule indicators is not a guarantee that a system has not been exploited.

In light of this background, Praetorian highly recommends that organizations consider their externally facing MOVEit Transfer instances to be potentially compromised and conduct an investigation into the asset to identify potential indicators of compromise. Praetorian also recommends that organizations take additional actions to further investigate their systems for a potential compromise.

While it’s impossible to prove a negative (lack of exploitation), organizations could take four approaches to identify whether an attacker has exploited the vulnerability in their system. A review of database tables and applications can highlight newly created users that indicate exploitation. Examining the application web root can uncover common file names attackers are using to mimic the legitimate human.aspx file. Likewise, examining the internal and external network traffic for unusually high volumes can help uncover a compromise. Finally, companies can examine process execution logs and other data collected from the impacted system to identify signs of post-exploitation activity, such as execution of common enumeration and reconnaissance commands.

Mitigation

Companies will need to act in accordance with the following well-known playbook to mitigate this vulnerability, and must do so quickly and rigorously:

1. Prevent any additional downside risk by removing impacted assets or patching them.
2. Search for indicators of compromise on vulnerable assets
3. Evaluate potential data exposure and determine an action plan.

We now look at each step in turn.

The most urgent thing to do when confronted by any serious vulnerability is to stop the bleeding. If an asset has not been compromised, patch it immediately. Fortunately, Progress has already released a patch. Identifying machines in your attack surface that are vulnerable and then preventing any new breaches of these assets is step 1.

Once a company is sure that no additional vulnerable instances of MOVEit remain (both externally and internally), it needs to determine if any indicators of compromise exist on these machines. Hopefully this analysis will yield a clean bill of health, but if any of these assets appear to have been compromised, the company will need to execute its standard breach response playbook.

Finally, even if an organization detects no signs of breach, it needs to evaluate and remediate any potentially exposed data. For example, if passwords or other secrets were potentially compromised, the organization would need to rotate those credentials as soon as possible. If customer data could be involved, consider consulting with your legal team on next steps, making sure that you fully comply with laws and regulations. Again, the next steps will vary depending on each company’s business, but the overall approach is the same: take reasonable steps based on risk minimization for the type of data potentially exposed. Your goal in this step is to maximize the overall business outcome, which may involve some risk acceptance.

When the Dust Has Settled…

Issues such as CVE-2023-34362 are what we like to call a “predictable surprise.” That is, every CISO and SOC team knows that new vulnerabilities will be discovered in the wild. In such cases, having a really good understanding of what services you have deployed is critical. Step one of mitigation is a place where defense often goes wrong, because the defenders miss an asset. In the case of a remotely-exploitable vulnerability like this one, attackers are likely to find any asset defenders miss.

This highlights the importance of every company having a high-fidelity view of their as-deployed attack surface. “As deployed” is an important distinction due to the delta that often exists between theory (such as an asset database or terraform configurations) and practice (what is running in the Cloud or in your DMZ). An exercise that enables defenders to view their attack surface as attackers do is therefore important. It should trigger a healthy discussion about whether particular assets actually need to be exposed or whether the data they store is appropriate for that location. Savvy defenders will use this fire drill as a reason to reevaluate the accuracy and scope of their attack surface comprehension, and look for ways to minimize it in advance of the inevitable vulnerability that comes next.

If you would like us to scan your domains for this vulnerability, please reach out to Thomas Reburn (thomas.reburn@praetorian.com). Priority for this service will go to existing clients, but we can and will assist others as scheduling allows.