Oracle Weblogic Server Flaw Allows Attackers Full Control – PoC Released
- С сайта: Vulnerability(cybersecuritynews.com)
- Вернуться к списку новостей
С сайта: Vulnerability(cybersecuritynews.com)
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.
📁🄳🄾🄲🅄🄼🄴🄽🅃
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)
WLNamingManager.class
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)
ForeignOpaqueReference.class
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)
MessageDestinationObjectFactory.class
The exploit leverages the BeanFactory#getObjectInstance method in Tomcat to call MessageDestinationObjectFactory#getObjectInstance in WebLogic, which ultimately triggers JNDI injection through MessageDestinationReference#lookupMessageDestination.
.webp)
notepad.exe
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.
#Cyber_Attack #Cyber_Security #Vulnerability #cyber_security #JNDI_Injection #vulnerability #WebLogic
Оригинальная версия на сайте:
Oracle Weblogic Server Flaw Allows Attackers Full Control – PoC Released
Author: EswarA 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.
📁🄳🄾🄲🅄🄼🄴🄽🅃
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.
WLNamingManager.classWebLogic 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.
ForeignOpaqueReference.classAccording 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.
MessageDestinationObjectFactory.classThe exploit leverages the BeanFactory#getObjectInstance method in Tomcat to call MessageDestinationObjectFactory#getObjectInstance in WebLogic, which ultimately triggers JNDI injection through MessageDestinationReference#lookupMessageDestination.
notepad.exeWebLogic 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.
#Cyber_Attack #Cyber_Security #Vulnerability #cyber_security #JNDI_Injection #vulnerability #WebLogic
Оригинальная версия на сайте:
