In the last few days, threat actors have been exploiting a critical pre-authentication vulnerability within Progress MOVEIt Transfer. There have been several great blog posts covering the incident response, forensic artifacts, and detection engineering efforts when it comes to preventing compromise. [1] [2] [3].
Assetnote was successful at determining the full exploit chain for this vulnerability, inclduing the SQL injection and the remote code execution attack vector. This exploit chain has been reproduced by our security research team and checks have been available and running on all customers. When critical vulnerabilities are exploited in the wild, our team works diligently in reverse engineering the exploit payloads and providing assurance to our customers on whether or not they are truly vulnerable via our Attack Surface Management platform.
You can watch our RCE proof of concept video below:
This blog post will go into some detail about how to get an environment set up to reverse engineer this issue. At a later date, we will be disclosing the proof of concept and steps taken to reproduce the vulnerability.
Given that this vulnerability is still being actively exploited, no proof of concept will be published until a public proof of concept becomes available, or 30 days from now, after organisations have had time to patch their instances or remove them from the external internet.
When reverse engineering patches, the first step is to confirm that you are able to download and install two adjacent versions of the software (unpatched & patched) so that we can perform patch diffing. For a lot of researchers, this can often be the blocker before they have even gotten to the meatier parts of this process.
We were able to achieve this by first signing up for a trial for Progress MOVEIt Transfer and instantly obtaining a serial key and a download for the latest version of the software (2023.0.1). This is a good start, but how are we going to get the unpatched version?
Doing some searches on Google, we came across the link https://cdn.ipswitch.com/ft/MOVEit/Transfer/2022/2022.1.1/MOVEit-Transfer-2022.1.1-FullInstall.exe. We knew that 2023.0.0 was vulnerable, and with a bit of wrangling, we were able to download this version through the following URL – https://cdn.ipswitch.com/ft/MOVEit/Transfer/2023/2023.0/MOVEit-Transfer-2023.0.0-FullInstall.exe.
Installing this software has some challenges. We need a valid serial key to install the software, which thankfully we obtained through requesting a free trial. That serial key however, in order to use it for the older build, we have to go through the steps of the “Offline Activation” which generates a license.txt which you can feed back into the installer.
After installing both versions of the software, we zipped up the C:MOVEitTransfer for each respective version and ran it through DiffMerge to see what had changed. We had to remove .dll files from the exclusion list inside DiffMerge’s settings so that we could determine exactly which files to take a closer look at.
We are aware that the exploitation logs for this vulnerability include requests to MOVEitISAPI.dll, but this is not something we can decompile with ILSpy. It is a native binary that we will have to use Ghidra to reverse engineer. Before we get to that point, we decided to focus on what could be decompiled to see if there were any clues as to how this vulnerability is exploited.
Looking at the DLL files inside the wwwroot/bin folder, we can see that there are a number of files that have changed. The next step is to decompile these DLL files using ILSpy and compare the source code again using DiffMerge.
 |
|---|
After decompiling these files and comparing the patched and unpatched versions with DiffMerge, we noticed this specific code had been removed from the patched version:
 |
|---|
Seeing this, we quickly realised the impact of this code, allowing you to set session variables arbitrarily based on the header input from a request. This seemed like a real lead towards discovering the root cause of this vulnerability.
We spent some time tracing the code and understanding how this function was called in the first place. Our investigation led us to machine2.aspx, which seemingly can only be called via the internal network. Looking at the blog post from Huntress Labs and speaking with wvu on Twitter, we realised that the way machine2.aspx was called was via an SSRF through MOVEitISAPI.dll?action=m2.
For us to investigate this further, we needed to install the software and get a dynamic debugging environment set up. This is quite simple given that the MOVEit Transfer installer works out of the box without too much fiddling. It installs the software, as well as a MySQL database by default. Remember to save all of the credentials you have set locally.
Confirm that you can login to the MOVEit Transfer web application on localhost, and once that’s done, download a copy of Jetbrains Rider in order to set up a debugging environment. We prefer using Rider when doing dynamic debugging as it automatically attaches to the process running the web application and dynamically decompiles all of the loaded assemblies.
You can achieve this by clicking the “Attach to Process” button when starting up Rider, and selecting the W3WP process that runs the moveitdmz application:
 |
|---|
After attaching to the process, on the left hand side you will see all of the assemblies are decompiled magically by Rider. You can pick the assembly you’re interested in, for our case, midmz -> MOVEit.DMZ.WebApp -> SILMachine2 -> Set a breakpoint in the Machine2Main function:
 |
|---|
At this point, we are able to debug the application and confirm that we are able to hit machine2.aspx via the SSRF located at MOVEitISAPI.dll?action=m2.
While there are several more steps necessary for exploitation, we plan on releasing these details after organizations have had time to patch their instances.
We will update this blog post in 30 days time with the full details of the exploit chain.