Log4Shell (Log4j) or Log 4 Hell ?!

 

From four days ago we did whatever we could do to make secure many infrastructures against the recent RCE (remote code execution) zero-day vulnerability: Apache log4j. Especially we focused on virtualization environments and critical components like vCenter Servers, vRealize Suite, Horizon View Connection Server's Apache Tomcat, and Unified Access Gateway (UAG). I truly confess it's a bad situation, very very bad. Personally, I believe that no exploit was worse than this in 2021, because there are many solutions from a variety of vendors that use Apache as the web App (and subsequently log4j as the Apache's logging component): From Cisco, VMware, Dell to many Industrial Applications of OT Networks.

The log4j is a Java-based logging framework of Apache web services, but its default JNDI feature (Java Naming & Directory Interface) is the primary point of this zero-day. The severity rate of this vulnerability is critical (10/10) that was publicly announced on Dec 9th, 2021 by the developer team and led them to release of the CVE-2021-44228.

All versions below 2.14.1 are vulnerable by default. However, in the last day Apache Software Foundation (ASF) announced the second vulnerability CVE-2021-45046 that version 2.15.0 can be affected too. So, the suggested workarounds are not enough and cannot address this catastrophic exploit lonely. SANS said: "The new version 2.16.0 has been made available to completely fix the issue (so far at least)"

As ASF explained about the Apache log4j 2 update: "In version 2.16.0 the message lookups feature has been completely removed. Lookups in configuration still work. Furthermore, Log4j now disables access to JNDI by default. JNDI lookups in configuration now need to be enabled explicitly. Also, Log4j now limits the protocols by default to only Java, LDAP, and LDAPS and limits the LDAP protocols to only accessing Java primitive objects. Hosts other than the localhost need to be explicitly allowed."

This vulnerability lets the attacker execute RCEs on target without authentication, which potentially is a high risk that you should never ignore. However, VMware announced VMSA-2021-0028 which listed all the exploitable products and also their current workarounds and possible fixes. Of course, there are many other products that are under investigation to find further weaknesses against the possibility of this vulnerability. So, I strongly recommend executing any immediate remediation action, because the situation is still @#$%ed up and one of the best choices is the following FAQ of this "In the Wild" exploit.

At last, you should be aware that in most products you cannot handle directly this issue and need to review the vendor's provided solution to fix it. While these actions are not enough to protect against the attacker's activities, but it was mentioned on many FAQs that adding this line: "-Dlog4j2.formatMsgNoLookups=true" has no require to revert back to the latest setting. So, it seems the patching will roll the products forward and is accommodated with the provided workarounds. Then I think it's not just a temporary solution.