From identity forgery to full RCE: An AWS instance identity typically corresponds to a hostname. But the researchers explored how this could be abused within Conjur’s resource model, which uses three parameters: Account (Conjur account name), Kind (resource type, host, user, variable, policy, etc.), and Identifier (unique resource name). These parameters are also used in API queries.They discovered that Conjur’s authentication logic didn’t validate the “kind” part of an identity. This meant they could use their spoofed AWS identity to authenticate as a user or policy in the system instead of a host, significantly expanding the attack surface.”This step changed the game,” they said. “It bridged the gap between unauthenticated access and a meaningful attack surface in Conjur. By combining a forged STS response, a policy identity instead of a host, and flaws in the Host Factory flow, we gained the ability to mint new hosts with names and ownership entirely under our control.”Next, they examined Conjur’s Policy Factory, a mechanism that allows admins to apply reusable policy templates to new resources. These templates can contain Embedded Ruby (ERB) code that gets executed when applied.Their goal was creating a template with arbitrary ERB code to achieve arbitrary code execution, but since Conjur doesn’t include built-in templates by default, they couldn’t abuse an existing one.The researchers determined that policy templates were stored in Conjur’s secrets table and secrets were only intended to be assigned to resources of type variable, not hosts. However, in practice Conjur’s code didn’t enforce this restriction.Further inspection revealed additional validation gaps. For example, a query like {Account}:variable:conjur/factories/{kind} didn’t validate the Account field. By specifying an account name like MyAccount:host, they transformed the resource ID into MyAccount:host:variable:conjur/factories/{kind}.”This was the final step, and the one that delivered full remote code execution,” the researchers said. “The code ran because: We tricked Conjur into fetching a host as if it were a variable. We assigned ERB as a secret and Conjur executed it, exactly as it was designed to. This vulnerability turned arbitrary host creation into arbitrary command execution. It was a seamless, start-to-finish exploit chain that went from unauthenticated access to root.”CyberArk addressed these issues in June, issuing five distinct CVEs. However, the full technical details of the vulnerabilites are now being disclosed publicly for the first time.
First public remote code execution flaw in HashiCorp Vault: HashiCorp Vault is an open-source credentials management system, also available in an enterprise edition, that serves a similar purpose to CyberArk Conjur: storing and controlling access to secrets such as API keys, database passwords, certificates, and encryption keys used for authentication across distributed systems in multi-cloud and hybrid environments. It is commonly deployed in DevSecOps pipelines.As with Conjur, Cyata researchers conducted manual code reviews of Vault, focusing on logic flaws in components responsible for authentication and policy enforcement, rather than memory corruption or race conditions typically detected by automated tools. This approach led to the discovery of nine vulnerabilities, including the first remote code execution (RCE) exploit in Vault’s 10-year history. Because these were deep logic issues rather than surface-level bugs, many had remained hidden in the codebase for years.The researchers began by examining Vault’s most commonly used authentication methods: traditional username and password (userpass); LDAP, which relies on directory services like Active Directory or OpenLDAP; and TLS certificate-based authentication, often used for machine-to-machine communication.In the userpass method, they found a flaw that allowed attackers to determine whether a username exists (username enumeration), as well as a way to bypass brute-force protections that should lock out users after multiple failed login attempts. In the LDAP method, they discovered similar lockout bypasses and a way to circumvent multi-factor authentication (MFA) enforcement.For the Ttme-based one-time password (TOTP) MFA method, which is enabled across many deployments, they identified bugs that allowed brute-force protection bypasses, enabling attackers to attempt guessing MFA codes without triggering lockouts.In certificate-based authentication (non-CA mode), the researchers uncovered a logic flaw where Vault verified only that the TLS client certificate’s public key matched the pinned certificate but failed to check that the certificate name (CN) matched as well. Since Vault uses the CN value to map to an internal EntityID, an attacker with access to a certificate’s private key could generate a certificate with a valid public key but a forged CN, impersonating another identity in the system.Another vulnerability allowed privilege escalation from an admin account to root, the highest level of access in the system. By design, Vault prevents the root policy from being assigned to any user identity, including admins, to mitigate the risk of full system compromise. However, the researchers found a way to bypass this security barrier.The most critical flaw involved leveraging Vault’s logging system to achieve arbitrary code execution through plug-ins, third-party binaries that extend Vault’s functionality. To exploit the plug-ins system, the researchers needed to write arbitrary code to a file in the plug-ins directory and set executable permissions. They achieved this by manipulating the audit component to insert malicious code into logs using a custom prefix, then writing those logs into the plug-ins’ directory.This vulnerability, now tracked as CVE-2025-6000, is the result of multiple logic flaws and has existed since the early days of the Vault project. With this exploit, attackers could delete a critical file containing the keys needed to decrypt all stored secrets, potentially causing ransomware-like disruption, among other things.Cyata reported the vulnerabilities to HashiCorp, which has since patched them in the latest software versions. Security bulletins detailing the issues were also released today.”This research reinforces a critical truth, even memory-safe software can fail at the logic level, and when it does, the consequences can be just as severe,” the researchers said. “Vault is designed to be the ultimate protector of secrets and infrastructure access. But this work shows how subtle logic bugs in authentication flows, identity resolution, and policy enforcement can quietly break trust.”
First seen on csoonline.com
Jump to article: www.csoonline.com/article/4035274/researchers-uncover-rce-attack-chains-in-popular-enterprise-credential-vaults.html
