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 showed how the Sage 300 authentication was a façade that could allow a low privileged TEST user to gain unrestricted access to the database, and (in some configurations) even the underlying host. We also showed how it was possible to exploit these issues by copying and pasting a password in an ISM file and then unmasking a password textbox. While simple, this method involved overwriting the ADMIN password, which wasn’t particularly elegant.

In this part of the case study, we will aim to completely subvert this application’s access controls by figuring out how the Database Setup utility is retrieving and decrypting the SQL password, which would allow us to simply read and decrypt the SQL password from the exposed ISM files, and probably all the other user passwords too. To accomplish this, we’ll need to get our hands dirty with some reverse engineering

Note that this portion of the case study will get quite technical. If you can’t make it through, we suggest you skip to Part 3.

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.

Software solutions have had to evolve rapidly to keep pace with cybersecurity threats. Today, nearly every significant software solution is loaded with security features to protect against a range of threats. One of the most important security features included in modern software products is access controls. Access controls are mechanisms that control which users can access, modify, and/or delete specific resources. Organizations rely on these access controls to prevent unauthorized personnel from accessing privileged data and software functionality, and to track the access of legitimate users so that the organization can respond to insider threats. With cyberattacks and insider threats on the rise, what happens when the access control mechanisms that organizations have grown to rely on are found to be critically flawed?

In this series of articles, we’ll 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.

This series is the full technical disclosure we committed to in the Vulnerability Brief we published in April. If you’re a Sage 300 user, administrator, or partner looking for a high-level overview of the issues and remediation guidance, please see that article instead.

In 2022 Konrad Haase, a member of the Control Gap Offensive Security team, discovered a series of vulnerabilities in Sage 300, a well-established on-premises enterprise resource planning (ERP) solution, that could allow an attacker to bypass authentication and user-level access controls, decrypt sensitive data including stored passwords, and obtain direct database access to read/modify/delete all records. Over the past 10 months the Control Gap team has been working with Sage to develop a product update to address these issues, which Sage released on April 27, 2023. Users of the Sage 300 program are strongly encouraged to download and install this product update as soon as possible.

On June 27 we published a series of technical articles detailing the discovery and exploitation process for the six (6) vulnerabilities described below.

In modern cyberattacks, threat actors will often begin their attacks against enterprises by obtaining low-privileged access to a single system in the internal IT environment through phishing, VPN access, or successful exploits against perimeter systems. Once they’ve gained a foothold into the secure environment, these threat actors will often perform local-system privilege escalation, which is the process of elevating their permission beyond those of their compromised user account, to expand their access and accomplish their objectives. Local-system privilege escalation will typically be performed by exploiting missing operating system patches (which address critical vulnerabilities), system misconfigurations, or vulnerable third-party applications installed on the target machine. In this article, we’ll explore how a simple oversight in a third-party application installer can compromise the security of a local system, allowing a threat actor or attacker to escalate their privileges and obtain complete system compromise. During a cyberattack, such a compromise would allow attackers to pivot and escalate their access to other systems and potentially privileged domain accounts within a corporate IT environment. This article should be of particular interest to IT administrators as this type of vulnerability affects many enterprise software products and is trivial to exploit.

The third-party application installer we’ll be examining in this article is associated with a product called Sage 300. This product caught our attention during a penetration test in 2021 where we used a vulnerability in a local Sage 300 installation to escalate our privileges on a workstation we had obtained low-privileged access to. Given the nature of the vulnerability, we assumed that our customer had made a mistake during installation or subsequent configuration, but after some research, we discovered that the vulnerability we exploited lay in the product itself, and likely affected Sage 300 installations going back several years. Following responsible disclosure, we alerted the Sage security team and worked with them towards a fix for over a year to address the vulnerability we discovered, which is now described in CVE-2021-45492