Attackers are actively exploiting a critical, pre-authorization remote-code execution (RCE) vulnerability in the popular Access Management platform from digital identity management firm ForgeRock.
Access Management, a commercial access-management platform, is based on the OpenAM open-source access-management platform for web applications. The platform front-ends web apps and remote-access setups in many enterprises.
On Monday morning, the Cybersecurity and Infrastructure Security Agency (CISA) warned that the vulnerability could enable attackers to execute commands in the context of the current user. The flaw can be found in Access Management versions below 7.0 running on Java 8. That means 6.0.0.x, 6.5.0.x, 6.5.1, 6.5.2.x and 6.5.3, as well as older, unsupported versions are all sitting ducks.
Also on Monday, ForgeRock said in an updated security advisory that the flaw doesn’t affect Access Management 7 and above. It only impacts a subset of ForgeRock customers who are using older versions of the company’s Access Management product.
An exploit for the critical vulnerability at the heart of the matter – CVE-2021-35464 – was first reported by Michael Stepankin, a researcher for the cybersecurity firm PortSwigger, on June 29. In his report, Stepankin explained that he created a new Ysoserial deserialization gadget chain specifically for the exploit.
As GitHub details, Ysoserial is a proof-of-concept tool for generating payloads that exploit unsafe Java object deserialization. Serialization is a mechanism of converting the state of an object into a byte stream. Deserialization, in turn, is the reverse process: That’s the mechanism whereby the byte stream is used to recreate the actual Java object in memory, used to persist the object.
Within hours of Stepankin’s post on June 29, ForgeRock released a workaround and advisory to its customers to protect them from the vulnerability. On July 9, the company updated its advisory with a permanent fix.
What a Dinky PoC
In his post, Stepankin summed up the flaw as an RCE made possible “thanks to unsafe Java deserialization in the Jato framework used by OpenAM.” The proof of concept (PoC) requires this single GET/POST request for code execution:
GET /openam/oauth2/..;/ccversion/Version?jato.pageSession=<serialized_object>
He said that an attacker who crafts such a request can send it to an exposed, remote endpoint in order to pull off RCE.
The researcher discovered the vulnerability while looking into OAuth vulnerabilities. OAuth is an open standard for access delegation, commonly used as a way for people to sign into services without entering a password, by using signed-in status on another, trusted service or website. Examples include the “Sign in with Google” or “Sign in with Facebook” that many websites use in lieu of asking visitors to create a new account. These “Sign in” or “Log in” prompts are called consent prompts.
A year ago, Microsoft warned that during the pandemic, against the backdrop of widespread remote working and the increased use of collaboration apps, attackers were ramping up application-based attacks that exploit OAuth 2.0.
With the help of a few scripts, Stepankin discovered all servers that respond to the “/well-known/openid-configuration” URI and checked out their configuration. He decided to focus on “truly impactful” vulnerabilities: Hence, he zeroed in on systems that are either open-source or available to download and decompile. “ForgeRock OpenAm was one such system that I found in the bug bounty scope,” he wrote. “It appeared to me as a monstrous Java Enterprise application with a huge attack surface, so I decided to take a deeper look into it.”
His takeaways from tackling the Java monster:
- Source code analysis and local testing are essential for finding issues like this one.
- URLDNS and JRMPClient gadget chains are the most universal for testing deserialization in Java.
- Even in solutions designed for authentication, you can find a big attack surface available without any auth.
- Automatic source code analysis tools are not sufficient if they don’t cover dependencies.
- Java deserialization rocks.
Patch Available
On Saturday, ForgeRock updated its advisory to advise users to take immediate action to either implement one of the workarounds or the patch as soon as possible.
ForgeRock urged users to apply a workaround, to be applied “immediately” to secure deployments, noting that the workarounds are suitable for all versions, including older, unsupported ones.
Stepankin noted that the vulnerability was patched in ForgeRock AM version 7.0 “by entirely removing the ‘/ccvesion’ endpoint, along with other legacy endpoints that use Jato.”
He mentioned this big “but”: “Jato framework has not been updated for many years, so all other products that rely on it may still be affected.”
The researcher also noted that the flaw doesn’t affect instances running with Java version 9 or newer, “since Jato requires classes that have been removed in Java 9. It’s one of the reasons why ForgeRock AM versions prior 7, such as 6.5, are still running on Java 8,” he continued.
Patch or Workaround
Users who can’t patch can apply one of two workarounds that ForgeRock provided in its advisory.
CISA recommends these steps for Access Management users to secure their platforms against the active, ongoing exploits:
- Review the ForgeRock Security Advisory and the Australian Cyber Security Centre Alert;
- Check for vulnerable instances of the Access Management software (see ForgeRock’s Technical Impact Assessment); and
- Prioritize deploying an update to Access Management version 7 or apply the workaround urgently.
Tasty Targets
Marcus Hartwig, manager of security analytics at cybersecurity firm Vectra, told Threatpost on Monday that identity and access management (IAM) platforms like OpenAM are “always ripe targets for attackers since they allow attackers to access multiple downstream applications federated with the solution.”
As well, Hartwig said in an email, “even if the compromised account lacks access to a specific application, many IAM solutions support creating new downstream accounts on applications through protocols like SCIM, which further allows attackers to progress their attacks.”
He said that it’s “paramount” for organizations that leverage IAM solutions for SSO into downstream applications to “monitor account behavior in their environs to detect attacks that circumvent the preventative security that Access Management solutions focus on.”
071221 16:19 UPDATE: Corrected the article to specify that there’s a patch available. We regret the error.
071221 20:21 UPDATE: Corrected inaccurate timeline for patch release.
Check out our free upcoming live and on-demand webinar events – unique, dynamic discussions with cybersecurity experts and the Threatpost community.
