This is a continuation of the Sage 300 case study series where we explore the process of discovering and developing exploits for six (6) different vulnerabilities we found in Sage 300 that would have allowed users to bypass authentication, decrypt sensitive data including stored passwords, and obtain direct database access.

In the first part of our Sage 300 case study, we introduced Sage 300, explored the process an administrator would take to secure an installation based on the vendor documentation, highlighted red flags in the vendor documentation that raised questions about the design of the application’s security controls, investigated those security controls, and figured out how to exploit design flaws to impersonate users, access the database directly, and execute code on the underlying database system.

In the second part of our Sage 300 case study, we walked through the process of reverse engineering the encryption algorithm used by Sage 300 so we could decrypt passwords stored in the ISM files and, in the process, discovered a pattern of hardcoded secrets being used through the application binaries. We explored each vulnerability we discovered to figure out the impact and then developed proof-of-concept code snippets to exploit each one. In the end we had developed the capability to extract plaintext user credentials and SQL strings from the ISM files, decrypt passwords stored in the PORTAL database (Web Screens functionality), obtain administrator access to the Apache Solr instance associated with the Global Search feature, and retrieve other secrets stored in configuration files.

Weaponizing The Discovered Vulnerabilities

Weaponizing a vulnerability refers to the development of an exploit for that vulnerability that can be reliably deployed against vulnerable targets in the wild. This allows our research to be leveraged by fellow cybersecurity professionals to confirm the presence of the vulnerabilities in their own environments and demonstrate impact without having to learn all the technical details associated with the discovered vulnerabilities. Before we discuss the feasibility of weaponization, let’s quickly review the vulnerabilities we’ve discovered:

1. The Sage 300 access controls are only implemented client-side; workstations are trusted to authenticate users and then use a common SQL login ID to connect to the database. Since Sage 300 exposes the SQL login ID to all workstation users, it would be possible for workstation users to recover those credentials then establish direct database connection to bypass all user access controls and read/modify/delete all company data. Depending on the database configuration, it may even be possible to execute code on the underlying database server. This vulnerability is being tracked as CVE-2023-29927.

2. Sage 300 provides all workstation users read and write access to the Shared Data directory which contains files that store configuration settings and encrypted credentials. A workstation user could abuse this to perform privilege escalation via account takeovers (by changing users’ passwords) or via configuration modification (see “More On The Shared Data Folder” section in the Appendix). This vulnerability is being tracked as CVE-2022-38583.

3. Sage 300 uses a hard-coded 40-byte blowfish key to encrypt and decrypt user passwords and SQL connection strings stored in ISAM database files in the “SharedData” directory. This issue could allow attackers with access to the “SharedData” folder and the underlying SQL server (as workstation users would have) to recover user credentials, recover SQL connection strings, and leverage those SQL connection strings to exploit vulnerability #1 across all Sage 300 installations (of affected Sage 300 versions). This is being tracked as CVE-2022-41400.

4. The optional Web Screens and Global Search features for Sage 300 use a hard-coded 40-byte blowfish key ("LandlordPassKey") to encrypt and decrypt secrets stored in configuration files and in database tables. This vulnerability could be exploited by an attacker to recover the default Apache Solr credentials (associated with the optional Global Search feature) and recover all user passwords stored in the “PORTAL” database (associated with the optional Web Screens feature). This vulnerability is being tracked as CVE-2022-41397.

5. The optional Global Search feature for Sage 300 uses a set of hard-coded credentials for the accompanying Apache Solr instance. This issue could allow attackers to login to the Solr dashboard with admin privileges to access sensitive information and attack the Apache Solr product. This vulnerability is being tracked as CVE-2022-41398.

6. The optional Web Screens feature for Sage 300 uses a hard-coded 40-byte blowfish key ("PASS_KEY") to encrypt and decrypt the database connection string for the PORTAL database found in the "dbconfig.xml" file stored in the “SharedData” folder. This vulnerability could be exploited to provide attackers access to the “PORTAL” SQL database. This vulnerability provides attackers with workstation-user access, which can be leveraged to access/modify/delete all database records associated with the Web Screens product, and, when combined with CVE-2022-41400 (vulnerability #3 above), a mechanism to recover plaintext user passwords. This vulnerability is being tracked as CVE-2022-41399.

Since the discovered vulnerabilities are all related to design flaws or hardcoded values that haven’t changed over multiple releases (years) of the product, it makes sense for us to invest some time to weaponize these vulnerabilities so that the next time we encounter a vulnerable Sage 300 installation during one of our offensive security engagements we can quickly deploy a program to automatically compromise our target organization’s ERP system. Weaponizing these vulnerabilities also shouldn’t be too difficult; we’ve already done some of the work in our proof-of-concept code from earlier.

High-Level Plan

At a high-level, we can assemble a tool to perform the following activities:

1. Connect to a default or user-specified shared data directory to:

   1. Read the usernames and passwords from the “browse.ism” file and decrypt all passwords (including password history).

   2. Read the SQL connection strings from the “orgs.ism” file and decrypt the SQL passwords to get usable connection strings for each company.

   3. Read the SQL connection string from the “dbconfig.xml” file and decrypt the password to get a usable connection string for the “PORTAL” database.

2. Connect to the “PORTAL” database using the recovered connection string to extract and decrypt credentials for all Web Screen users stored in the “UserTenant” table.

3. Connect to each of identified SQL databases and check if the Sage user is a system administrator that would (by default) have access to advanced (and dangerous) SQL functions like “xp_cmdshell”. We could automate the process of reconfiguring the server to gain command execution, but our tool would be both safer and more flexible if we didn’t.

4. Connect to a target server and check if an Apache Solr server exists, can be accessed using the default administrator credentials, and return the version of the installation. Again, we could automate the exploitation of Apache Solr exploits, but our tool would be both safer and more flexible if we didn’t.

Our tool should return all of the information necessary to demonstrate impact without doing anything that may be destructive (i.e., modifying files). The professional using the tool could then leverage the returned information to conduct further attacks using established tradecraft, like deploying exploits against Apache Solr or achieving code execution.

Implementation

After some internal discussion, the team here at Control Gap has decided that releasing an implementation of the tool outlined above would not be in the best interest of the Sage 300 user-base at this time. We feel that there is sufficient information in this article for interested administrators, developers, and fellow security professionals to confirm the presence of the vulnerability in their systems and demonstrate impact. At this point in time, we feel that releasing a fully weaponized tool would only serve to further enable threat actors. That said, we did implement the tool for our own internal use, which you can see the output of below:

Sage300-2-90: Console output of the “Sage300-SR” tool developed by Control Gap to exploit the identified issues in Sage 300.

Mitigations and Lessons Learned

Administration

At time of publication, the newly released Sage 300 2023.2 product update addresses most of the disclosed issues and contains completely overhauled installation and administration instructions to mitigate the lone unpatched vulnerability (CVE-2023-29927). Please refer to the official Sage Knowledge Base article for updated security hardening guidance.

In general, it is recommended for administrators to evaluate the installation and configuration requirements for each new piece of software entering their organization to increase the chances of spotting glaring software security issues like the ones presented in this article. It is also recommended to ensure that all business-critical databases and software solutions are regularly being backed-up and that those backups are ready to be deployed to ensure business continuity.

Software Development

For developers reading this article, the important lessons learned are as follows:

• Clients (like workstation users) are typically outside of our control and should never be trusted. This means that access controls and input validation need to be implemented and enforced on the server-side (something we do control).
• Passwords and cryptographic keys should be generated on a per-client basis during installation, not hardcoded nor distributed as a common default. Clients should be able to rotate these keys and passwords.
• Any logic or secrets included in client applications can be recovered by a motivated attacker. Do not include anything in client applications that you don’t want users to see or have access to.
• The reverse engineering demonstrated in this article cannot be prevented, but it can be made more difficult via code obfuscation. Obfuscation is a cheap way to make it more difficult (but never impossible) for an attacker to extract information from a program. Obfuscation is not a replacement for secure coding practices.
• There exist several secure software development frameworks and standards that, if followed, could have prevented the security vulnerabilities described in this article, including the NIST Software Development Framework, PCI Secure Software Standard, and PCI Secure Software Lifecycle Standard. For a more ad-hoc approach, consider using something like the OWASP Secure Coding Practices – Quick Reference Guide.

Sage Isn’t Alone

It is important to clarify that while Sage 300 was the product being dissected in this article, it is certainly not the only product that is affected by these types of vulnerabilities. For example, in 2022 alone there were approximately 150 CVEs published related to the use of hardcoded credentials (CWE-798), 2 CVEs published related to the use of hardcoded cryptographic keys (CWE-321), and approximately 55 CVEs published related to improper access control (CWE-284).

Disclosure Timeline

The high-level disclosure timeline for the various issues has been outlined below:

Thank You

We’d like to thank the Sage security, incident response, management, and development teams for working with us to resolve these issues.

To the readers that made it this far, thank you for taking the time to read our case study.