Despite the release of Kerberos more than 20 years ago, many enterprises today have not transitioned away from using NTLM authentication in their enterprise IT environments. As attackers continuously refine their tools and tactics, finding new and sophisticated ways to exploit NTLM's inherent vulnerabilities, the risks associated with maintaining NTLM are becoming increasingly prominent. This article aims to demonstrate some of the most popular and contemporary attacks exploiting NTLM, provide insight as to why Microsoft is working on disabling NTLM by default during the Windows 11 lifecycle, and underline the urgency for transitioning away from this outdated protocol. Keeping NTLM authentication enabled can lead to rapid (less than one minute) compromises of entire Active Directory domains.

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.

Businesses of all sizes have increasingly been developing and deploying complex internet-facing web applications to provide consumers with richer experiences. While richer web experiences represent an opportunity for businesses to interact with and provide value to consumers in new and exciting ways, they also represent new attack surface for hackers. Many applications today exist to facilitate the storage, processing, and presentation of some variety of data, which is often compartmentalized through the use of roles and user accounts. Unauthorized access to web applications can often provide hackers with valuable information to sell on the darkweb or to use in future attacks against the organization or that organization’s users/clients. It’s important for developers building web applications to understand common web application attacks, their implications, and corresponding defences to architect robust and secure web applications that consumers can trust to keep their data secure.

In this article we’ll explore three authentication-related vulnerabilities we discovered in the PlexTrac platform (now described by CVE-2022-37144 through CVE-2022-37146), outline how these vulnerabilities could be combined to potentially bypass each step of the authentication process to gain access to sensitive data, and discuss how to build web applications that defend against such vulnerabilities.

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