Detectify scans for actively exploited Log4j vulnerability, CVE-2021-44228

Thanks to Detectify Crowdsource hackers, Detectify quickly developed a security test to detect Critical vulnerability CVE-2021-44228 Apache log4j RCE and you can start scanning with Detectify now. This vulnerability has set the internet alight over the past few days. Right now, exploit developers and security researchers are still understanding the potential capabilities provided by the vulnerability. Detectify received a working POC for this critical 0-day vulnerability from the Crowdsource community on Friday. 

Impact

In short, the CVE-2021-44228 Apache log4j RCE vulnerability allows an attacker, who can control log messages or log message parameters, to execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.

Here are some of the software identified as potentially vulnerable:

• solr
• druid
• flink
• struts2
• logstash
• redis
• elasticsearch
• kafka
• pulsesecure
• spark
• tomcat

Information from Apache.org:

CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints.

Severity: Critical

Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Versions Affected: all log4j-core versions >=2.0-beta9 and <=2.14.1

Affected customers will be alerted

On Friday morning, Detectify received the proof-of-concept (POC) for CVE-2021-44228 Apache log4j RCE from the Crowdsource community, allowing us to deploy a test for the vulnerability in production within hours of validating the POC. Customers already running Detectify Application Scanning will be checked for this vulnerability and alerted if it is detected in your assets. Note: you will need to have Detectify IPs on your allow-list for the tests to be successful.

This is yet another example as to why crowdsourcing security research is becoming a need and not just a nice-to-have. Solely relying on internal security research teams and testing against CVE libraries is a thing of the past. Crowdsourcing vulnerabilities is the quickest way to get vulnerability research from the streets to your hands to verify if applications are exploitable. 

What if I am using log4j?

The entire security community seems to be tracking this closely including this blueteamsec thread on reddit. Here are the recommendations directly from Apache:

In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.

For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m. For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Further reading:

If you’re a Detectify customer, we highly recommend scanning all critical assets as soon as you can. All users have access to log4j vulnerability scanning now.

If you’re not already a customer, click here to sign up for a free trial and immediately start scanning. Go hack yourself!