CVE-2023-36934: Progress Software MOVEit Transfer SQL Injection Remote Code Execution Vulnerability

Secure your products with top-tier expert knowledge and advanced Penetration Testing (CREST Approved)

Let's collaborate to build and maintain secure, trustworthy products

We transform threats into trust by integrating advanced tech and expertise in product security. Our approach encompasses Security by Design, rigorous security assurance and penetration testing, and compliance through expert documentation, from design to post-market. We offer CREST-approved pen testing in EMEA, upholding top security standards.

CREST Approved in EMEA

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Lucas Miller of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in Progress MOVEit Transfer. This bug was originally discovered by Trend Micro Vulnerability Researcher Guy Lederfein and is the same type of vulnerability being used by the Cl0p ransomware gang to exfiltrate data. A crafted request can trigger the execution of SQL queries composed from a user-supplied string. An attacker can leverage this vulnerability to execute code in the context of the “moveitsvc” user. The following is a portion of their write-up covering CVE-2023-36934, with a few minimal modifications.

An SQL injection vulnerability has been reported for Progress MOVEit Transfer. This vulnerability is due to insufficient validation of encrypted query parameters sent to the server. A remote, unauthenticated attacker could exploit this vulnerability by sending crafted requests to the target server.

A successful attack would result in arbitrary SQL command execution against the database on the target server, which can lead to arbitrary code execution under the security context of the running service.

The Vulnerability

MOVEit provides collaboration and automated file transfers of sensitive data and advanced workflow automation capabilities without the need for scripting. Encryption and activity tracking enable compliance with regulations such as PCI, HIPAA, and GDPR. MOVEit can be accessed via an API or a web interface accessed over HTTPS.

MOVEit supports the encryption of sensitive HTTP query parameters when generating redirection URLs. For example, if a request is made to the “/human.aspx” endpoint over plaintext HTTP, the user is redirected to the HTTPS endpoint. To generate the redirected URL, method MakeEncryptedURLIfNec() of class MOVEit.DMZ.ClassLib.SILGlobals will encrypt all HTTP query parameters in the original request and set the encrypted value in the ep HTTP query parameter of the new redirected URL. When this redirected request is read by the server, method GetEncryptedQueryParameters() of class MOVEit.DMZ.ClassLib.SILGlobals decrypts the ep HTTP query parameter, and the decrypted parameters are set to the server’s global variables.

In addition, some redirects call method SaveArgumentsToSessionForRedirect() of class MOVEit.DMZ.ClassLib.SILGlobals to save the global variables to the current session. These variables are stored in the sessionvars SQL table. When another request is made to the server with the HTTP cookie ASP.NET_SessionId set to the same session ID, the global variables will be loaded in method LoadArgumentsFromSessionIfNeeded() by reading them from the sessionvars table.

An SQL injection vulnerability exists within MOVEit Transfer. This vulnerability is due to insufficient validation of encrypted query parameters sent to the server.

As mentioned above, if a request is made to the “/human.aspx” endpoint over plaintext HTTP, the server will redirect to the HTTPS endpoint with all HTTP query strings in the original request encrypted in the ep HTTP query parameter. This allows generating arbitrary encrypted query strings. When another request is made to the “/human.aspx” endpoint with the ep HTTP query parameter set to the encrypted query string returned by the server from the initial request, the value will be decrypted and read in method GetEncryptedQueryParameters(). If the decrypted string contains the query string username, its value will be sanitized using the method SILUtility.XHTMLClean(), and then URL-decoded using the method HttpUtility.UrlDecode(). Note that due to the order of these operations, if the value contains a URL-encoded quote character (%27), it will not be sanitized by SILUtility.XHTMLClean() and will be successfully decoded to a quote character (‘). This improperly sanitized variable is written to the SILGlobals.LoginName variable. If this request also contains an InitialPage HTTP cookie with a value matching the regular expression “[a-z0-9]+.aspx”, the SILGlobals.LoginName variable will be saved to the sessionvars table with a session ID generated by the server and returned in the response.

If a subsequent call is made to the “/machine.aspx” endpoint with the same session ID, the SILGlobals.LoginName variable will be loaded by method LoadArgumentsFromSessionIfNeeded(). Later, the method ProcessPreAuthXMLRequest() of class MOVEit.DMZ.WebApp.SILMachine will be called. In case the SILGlobals.Transaction variable is set to “passchangerequest”, the method UserProcessPassChangeRequest() of class MOVEit.DMZ.ClassLib.UserEngine will be called with the value of the SILGlobals.LoginName variable set as the MyLoginName argument. In this method, the MyLoginName argument is used when building an SQL Select query using the MOVEit.DMZ.ClassLib.SQLBasicBuilder class. Specifically, the argument is concatenated to the query using the AddAndToWhere() method, which does not perform any sanitization on the argument, leading to SQL injection.

A remote, unauthenticated attacker could exploit this vulnerability by sending crafted requests to the target server. Specifically, an initial request can be made to the “/human.aspx” endpoint with a crafted URL-encoded value in the username HTTP query string. Another request can be made to the “/human.aspx” endpoint with the encrypted query strings returned in the first response set in the ep HTTP query parameter, and a “.aspx” page set in the InitialPage HTTP cookie, leading to the crafted username value being decrypted, URL-decoded, saved to the SILGlobals.LoginName variable, and saved to the sessionvars table. Finally, a request can be made to the “/machine.aspx” endpoint with the same session ID returned by the second response. This will lead to the crafted value being loaded from the sessionvars table and used in the vulnerable SQL query.

A successful attack would result in arbitrary SQL command execution against the database on the target server. This would allow an attacker to inject a session into the activesessions SQL table, allowing the attacker to authenticate as an arbitrary user. In addition, an arbitrary value may be set in the state field of the fileuploadinfo SQL table, which is decrypted and deserialized using BinaryFormatter. Setting this field to a crafted encrypted value would lead to insecure deserialization, which can lead to arbitrary code execution under the security context of the running service.

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the ports used by MOVEit Transfer.

Note that traffic may be SSL/TLS encrypted and must be decrypted before applying the following guidance.

The detection device must monitor for HTTP requests to the MOVEit Transfer endpoint “/human.aspx”. If found, the detection device must parse the HTTP query parameters from the following URIs:

       — Request-URI of the HTTP request
       — An InitialPage HTTP cookie value (only applicable if the value matches the regular expression “[a-z0-9]+.aspx”)

After parsing the query parameters from both sources, the detection device must search for the “username” query parameter name. If found, and the value of the query parameter contains a URL-encoded single quote character (%27), the traffic should be considered suspicious and an attack exploiting this vulnerability is likely underway.

Please also note the string matching of the “username” query parameter name, the “human.aspx” endpoint, and the “InitialPage” cookie name should be done in a case-insensitive manner.

Conclusion

Progress patched this vulnerability along with two others in early July 2023. As of now, we have not seen any evidence this bug is being used in active attacks. However, similar bugs have been used by ransomware gangs to exfiltrate data from targets. Progress offers no other mitigations other than applying the update. It is recommended that all MOVEit users test and deploy the patch as soon as possible.

Special thanks to Guy Lederfein and Lucas Miller of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

   Blog post Zero Day Initiative – Blog 

More To Explore