OPA for Windows Vulnerability Exposes NTLM Hashes – Source: www.darkreading.com

Source: adison pangchai via Shutterstock

Organizations using Open Policy Agent (OPA) for Windows should consider updating to v0.68.0 or later to protect against an authentication hash leakage vulnerability identified in all earlier versions of the open source policy enforcement engine.

The vulnerability designated the identifier CVE-2024-8260, stems from improper input validation, and allows attackers to trick OPA into accessing a malicious Server Message Block (SMB) share. This can result in credential leakage and the potential exposure of sensitive system information.

Enabling Credential Leaks

“Successful exploitation can lead to unauthorised access by leaking the Net-NTLMv2 hash — or in lay terms, the credentials — of the user currently logged into the Windows device running the OPA application,” said researchers at Tenable, who discovered the bug and issued a report this week. “Post-exploitation, the attacker could relay authentication to other systems that support NTLMv2 or perform offline cracking to extract the password.”

Many organizations use OPA for Windows to implement and enforce authorization and resource access policies across their software stack, including cloud native applications, microservices, and APIs. The technology gives organizations a way to ensure consistent policy automation and compliance across mixed Linux and Windows environments.

The vulnerability that Tenable discovered essentially allows attackers to force a vulnerable system to authenticate to an attacker’s server and thereby share user credentials in the process. The problem had to do with older versions of OPA for Windows not properly verifying the kind of files it received. Ordinarily, OPA should only use what are known as Rego files for rules and policies around decision making. What Tenable discovered was that because of improper validation, an attacker could pass an arbitrary SMB share instead of a Rego file to the OPA Command Line Interface or one of its Go library functions. An attacker could inject a path to their own server in the SMB share and force the system running the vulnerable OPA instance to authenticate to it.

“This can result in credential leaks or the execution of malicious logic, posing serious risks to system integrity and security,” Tenable said. An adversary that obtains a NTLM hash by exploiting CVE-2024-8260 could use the hash in a variety of ways, including authenticating to other systems and services, moving laterally, connecting to file shares, and attempting to extract the password.

NTLM (New Technology LAN Manager) is a suite of authentication protocols from Microsoft that many organizations use to enable single sign-on to enterprise applications and services. Attackers have often exploited NTLM in so-called pass-the-hash attacks and NTLM relay attacks, where they essentially reuse a captured hash to authenticate to different applications and services without actually knowing the password.

A Reminder of Open Source Risks

Tenable described the vulnerability it discovered as highlighting the risks organizations assume when consuming open source software and code. In research that Black Duck described in its “2024 Open Source Security and Risk Analysis Report,” the vendor found some 96% of code bases it reviewed to contain open source components. On average, 77% of all code in these codebases originated from open source. Some 84% codebases that underwent a risk assessment contained one or more security vulnerabilities and 74% had high-risk vulnerabilities like Log4Shel and XZ Utils in them. A surprising 14% of the code bases that Black Duck assessed had unpatched open source vulnerabilities in them that were 10 or more years old.

“As open-source projects become integrated into widespread solutions, it is crucial to ensure they are secure and do not expose vendors and their customers to an increased attack surface,” said Ari Eitan, director of Tenable Cloud Security Research, in a statement. “This vulnerability discovery underscores the need for collaboration between security and engineering teams to mitigate such risks.”

About the Author