A new secondary JNDI injection vulnerability was discovered in a recent version of WebLogic, allowing attackers to trigger JNDI injection during another JNDI lookup process, effectively enabling Remote Code Execution (RCE) on the targeted system.
A patch has been implemented for this vulnerability, which was not present in earlier versions of Oracle software and was included in the official Oracle Q2 quarterly update.
An attacker can exploit WebLogic’s JNDI functionality through two main methods. First, if the target class implements the OpaqueReference interface and WebLogic uses the ForeignOpaqueReference class, a malicious lookup operation can trigger JNDI injection via the getReferent method.
Second, by setting the java.naming.factory.object attribute to the MessageDestinationObjectFactory class during InitialContext initialization, the getObjectInstance method becomes vulnerable to JNDI injection when a lookup operation is performed.
It gets around normal restrictions on JNDI attributes, which lets any code run on the WebLogic server, and it looks at two new JNDI injection vulnerabilities, CVE-2024-20931 and CVE-2024-21006, in the context of the WebLogic server.
Integrate ANY.RUN in Your Company for Effective Malware Analysis
Are you from SOC, Threat Research, or DFIR departments? If so, you can join an online community of 400,000 independent security researchers:
- Real-time Detection
- Interactive Malware Analysis
- Easy to Learn by New Security Team members
- Get detailed reports with maximum data
- Set Up Virtual Machine in Linux & all Windows OS Versions
- Interact with Malware Safely
If you want to test all these features now with completely free access to the sandbox:
CVE-2024-20931 exploits the initialization of InitialContext, while CVE-2024-21006 introduces a malicious objectfactory during this initialization and triggers upon lookup. WebLogic’s lookup operation calls methods based on the target class’s implemented interfaces.
Only by implementing ClassTypeOpaqueReference and its related methods (getObjectClass/getReferent) or OpaqueReference (getReferent) can these vulnerabilities, along with CVE-2023-21839, CVE-2023-21931, and CVE-2024-20931, be exploited.
.webp)
WebLogic patches for CVE-2023-21839 and CVE-2024-20931 prevent unauthorized JNDI lookups. The fix modifies the `weblogic.jndi.internal.ForeignOpaqueReference#getReferent` method. When `getReferent` is called, `InitialContext` automatically sets the `java.naming.factory.initial` and `java.naming.provider.url` properties.
It prevents the use of the malicious `remoteJNDIName` value within the `lookup` call, effectively stopping remote JNDI exploitation through `ForeignOpaqueReference`. Additionally, `weblogic.jndi.internal.JNDIUtils#isValidJndiScheme` validates the JNDI scheme to further restrict unauthorized access.
.webp)
According to pwnull, the code appears vulnerable to JNDI injection even if standard JNDI properties like “java.naming.factory.initial” are not set. The attacker can exploit the “java.naming.factory.object” attribute, which is commonly used in newer JDK versions.
.webp)
The exploit leverages the BeanFactory#getObjectInstance method in Tomcat to call MessageDestinationObjectFactory#getObjectInstance in WebLogic, which ultimately triggers JNDI injection through MessageDestinationReference#lookupMessageDestination.
.webp)
WebLogic might restrict how to configure JNDI lookups by controlling properties like `java.naming.factory.initial` and lookup names. To bypass these limitations, `java.naming.factory.object` can be used to set a custom object factory.
The factory implements the `getObjectInstance` method of `MessageDestinationObjectFactory` achieving secondary JNDI injection in WebLogic, allowing to indirectly control resource binding and potentially circumvent restrictions.
Is Your Network Under Attack? - Read CISO’s Guide to Avoiding the Next Breach - Download Free Guide