A previously unknown zero-day vulnerability in Log4j 2.x has been reported on December 9, 2021. If your organization deploys or uses Java applications or hardware running Log4j 2.x your organization is likely affected.
To understand how Elastic is currently assessing internal risk of this vulnerability in our products please see the advisory here.
Authors and Contributors: As always, security at Splunk is a family business. Credit to authors and collaborators: Ryan Kovar, Shannon Davis, Marcus LaFerrera, John Stoner, James Brodsky, Dave Herrald, Audra Streetman, Johan Bjerke, Drew Church, Mick Baccio, Lily Lee, Tamara Chacon, Ryan Becwar. If you want just to see how to find detections for the Log4j 2 RCE, skip down to the “detections” sections.
Security researchers recently disclosed the vulnerability CVE-2021-44228 in Apache’s log4j, which is a common Java-based library used for logging purposes. Popular projects, such as Struts2, Kafka, and Solr make use of log4j. The vulnerability was announced on Twitter, with a link to a github commit which shows the issue being fixed. Proof-of-concept code was also released to github which shows that the vulnerability is trivial to exploit.
Earlier today, a serious flaw was discovered in the widely used Java logging library Apache Log4j. The vulnerability, ‘Log4Shell,’ was first identified by users of a popular Minecraft forum and was apparently disclosed to the Apache Foundation by Alibaba Cloud security researchers on Nov. 24, 2021. The vulnerability has the potential to allow unauthenticated remote code execution (RCE) on nearly any machine using Log4j.
The Oracle Java license change has become a hot topic amongst information technology professionals. As of January 2019, administrators who install Java 8 U 202 and later are only able to get security updates when they purchase support for each desktop. Furthermore, Java 11 and above is only available from Oracle under a commercial support agreement. The Java Oracle license change has raised concerns because support costs are expected to rise.
In a previous blog post, we took a look at Java’s custom serialization platform and what the security implications are. And more recently, I wrote about how improvements in Java 17 can help you prevent insecure deserialization. However, nowadays, people aren’t as dependent on Java’s custom serialization, opting instead to use JSON. JSON is the most widespread format for data serialization, it is human readable and not specific to Java.
