Security researcher Pierre Barre has drawn attention to three dozen vulnerabilities in IBM Security Verify Access (ISVA), including ones that could have allowed attackers to compromise the entire authentication infrastructure based on the authorization and network security policy management solution.

An attacker looking to exploit these issues would need to mount a man-in-the-middle (MiTM) attack or gain access to the internal network of an organization using IBM’s ISVA appliances and Docker images.

At least half of the security defects, including seven remote code execution flaws, one authentication bypass, eight privilege escalation bugs, and some other issues, could be exploited for full compromise.

“When the IBM Security Verify Access (ISVA) runtime docker instance (a core component of this solution) is reachable over the network, an attacker can bypass the entire authentication and interact with this back-end instance as any user, providing a complete control over any user without authentication,” Barre says.

The docker instance provides advanced access control and federation capabilities, essentially being a back-end for authenticating users.

Because the back-end is fully accessible from the local network (or can be exposed to the internet) and because its back-end API is vulnerable to an authentication bypass, an attacker could enroll malicious multi-factor authenticators to any user, to gain persistent access.

“In an offensive scenario, an attacker will likely delete authenticators for admins and security team and enroll new authenticators corresponding to admin accounts and get full control over the infrastructure while locking out legit admins,” Barre says.

The researcher underlines that IBM has not released patches for the bug and that it would likely leave it unpatched because the customer is responsible for filtering communication to the instance. Instead, IBM recommends network restrictions and security best practices to mitigate risks.

“Note that even with network restrictions, a low privileged user on a trusted machine can fully compromise the authentication solution, since the back-end used to manage the entire authentication infrastructure can be reached without authentication by sending a specific HTTP header,” Barre explains.

According to the researcher, isolating the ISVA runtime Docker instance using network segmentation, implementing optional authentication based on SSL certificates that was added in the latest ISVA release, flagging new authentication added to an account as suspicious, applying security patches, and reviewing logs to identify suspicious access to the Docker instance should mitigate the vulnerability.

Barre also discovered that official IBM Docker images contain hardcoded encryption/decryption keys and that some of them are even world-readable by default, allowing an attacker to decrypt the file containing the entire configuration of ISVA, including credentials and RSA keys and certificates, which is stored inside the Docker instance.

The researcher also discovered local privilege escalation flaws that allow an attacker to run several binaries as root, potentially executing arbitrary code as root, injecting commands, and escaping the telnet client.

Furthermore, Barre discovered that the official IBM Docker images were using outdated OpenSSL packages containing known vulnerabilities, that it was possible to log in as root if an SSH server was installed inside the instance, and that a password was not defined for the ‘cluster’ user.

Several Docker images, the researcher says, allowed the download of snapshot files over HTTPS without checking the SSL certificate of the remote server, allowing an MiTM attacker to replace the snapshot with a malicious one.

Other vulnerabilities could lead to the compromise of the Postgres database, denial-of-service (DoS) attacks, exfiltration of sensitive information, remote code execution (RCE) due to insecure downloads and configurations, and potential supply chain attacks due to the use of a third-party repository configuration.

The issues were discovered in October 2022 and reported to IBM in early 2023. Most of them were addressed progressively in Security Verify Access versions 10.0.7 and 10.0.8, with the most recent iteration released in June 2024, roughly 1.5 years after initial disclosure.

IBM published four advisories detailing 27 of the vulnerabilities. When asked for a statement on these issues and the long patching frame, IBM directed SecurityWeek to the most recent advisory, saying it has nothing to add to it.

Barre, on the other hand, has complained about the difficulties met when communicating with IBM PSIRT and IBM support regarding these vulnerabilities, about bug tickets being closed multiple times without patches being released, and about CVE identifiers still missing from IBM’s security bulletins.

Four separately disclosed vulnerabilities found by the researcher in ISVA were reported to IBM in March 2023 and patched in April 2024. These bugs too could allow an MiTM attacker to compromise the authentication infrastructure, Barre says.

Related: Cisco Patches Vulnerability Exploited in Large-Scale Brute-Force Campaign

Related: Hundreds of PC, Server Models Possibly Affected by Serious Phoenix UEFI Vulnerability

Related: Vulnerability in IBM Db2 Leads to Information Disclosure, Denial of Service

Related: Cross-Tenant AWS Vulnerability Exposed Account Resources