CVE-2021-38159: MOVEit Transfer SQL Injection Analysis

MOVEit Transfer

Ensure management and control over your business-critical file transfers by consolidating them all on one system. Leverage MOVEit Transfer’s file encryption, security, tamper-evident logging, activity tracking and centralized access controls to meet your operational requirements. Reliably and easily comply with SLAs, internal governance requirements and regulations like PCI, HIPAA, CCPA and GDPR.

Moveit Transfer is software for businesses to combine file transfers into one system and is also suitable for encryption in it.

Installing and License problem

The installation requirements of Moveit Transfer are not too high, and Moveit Transfer also offers Trial Licenses, so the installation seems relatively simple at first.

The first problem we got was that Ipswitch only offers the Full Installer version. Meaning, a new version needs to be installed and inserted into the old version instead of installing a patch. As for the installation, we found that their archive contains a bundled version, so it can be downloaded by changing the version in the path. But when we installed it, we discovered another bigger problem...

The second problem encountered, is that the License can only be used in the latest version. We tried unpacking the DLLs instead of installing but to no avail (probably because we haven't reversed it properly).

Therefore, the analysis fell into a congested just because...did not have the right license version.

With suggestions from @jstnkndy, we can that deploying through Azure can solve both of the above problems.

Diff and Analysis

To analyze the vulnerability, we need to collect all DLL files and decompile them, comparing them with the old version to get which is the point the Vendor patched.

By decompile and comparison, we get a lot of difference, probably due to quite a different version. We took a quick look and got a lot of fixed statements that seem to be related to SQL Injection, but almost are belongs to the MoveitApplication, which is the application part of the system, requiring authentication to access them. That is, it will be necessary to review all the changed statements, not just find the modified statements direct relative to SQL Injection.

We found out that it was in midmz.dll without reviewing all changes. After analyzing a bit more deeply, we found that the API related to SSO with SAML has an escape XML before the process in the next step. Maybe vulnerability here!

Brief SAML protocol

Single Sign-On (SSO) is a solution that allows users to simply sign in at one point to log into different systems without having to create new accounts.

The SAML protocol is a standard to deal with both Authentication and Authorization serving SSO. In addition, the most common standard is OAuth, but it only deals with Authorization.

SAML components include User-Agent, Service Provider, Identity Provider.

The flow of SAML is briefly described in the following figure

When the User-Agent sends back the SAML Response from the Identify Provider to the callback, the Service Provider needs to verify it.

SQL Injection Vulnerability

Dive into the SSO functionality. The server will receive the SAML Response and be processed through the Handler.

We also noticed that they have implemented the SAML Parser themselves.

This information is obtained by the parser directly from the Attribute, Element of XML is the returned SAML Response.

Due to no further processing, when checking these fields in the database by entering the SQL Query directly, it leads to a SQL Injection vulnerability.

Next versions they fixed it by using SILUtility.XHTMLClean() to escape special values.

And not only does this InResponse value and Login SSO endpoint, but we also see them patch a lot of other values and locations.

Exploit

Since the query returns no additional value and the system returns no error information, the most likely way is to use a Time-based attack.

At the same time, Moveit Transfer also allows use of different types of databases, so different payloads are required to detect.

Payload is inserted and rewritten into SAML Response then Base64 encodes and sends back to Server to callback endpoint SSO.

Although the vulnerability has been patched for a long time, we found that out of more than 2000 websites using this application, maybe at least 600 sites are still affected by this vulnerability.

Reference and Credit

Thanks @jstnkndy for helping us a lot in the process of analyzing this vulnerability.

Credit biennd4, anhnt427 from VcsLab of Viettel Cyber Security.