Introduction

We know you’ve probably heard about the Log4Shell vulnerability by now; it’s been one of the most important cybersecurity flaws found last year. Quite popular technologies and software, such as ElasticSearch, Hadoop and Minecraft, have been affected by it. 

For many businesses, the Log4Shell outbreak was a wake-up call, where it became obvious that vulnerabilities can come from places you don’t expect. In fact, vulnerabilities are usually from least expected locations (because you’re defending the obvious ones). So what can you do as a company to protect yourself from Log4Shell or other vulnerabilities that pop up in the future? The combination of offensive and defensive tools is the key. 

But first, in case you’ve missed it so far, what is Log4Shell?

Log4j: a logging tool

Log4j is a Java library used to log error messages in applications. Log4j is used in web apps, cloud services, and email platforms, so it’s pretty probable you’ve been using it. It is a standard third party tool. So, what’s the deal?

The outbreak of Log4Shell

It came to light recently that the cross-platform library is affected by a critical remote code execution vulnerability — tracked as CVE-2021-44228 and dubbed Log4Shell — that can be exploited to gain complete access to the targeted system by getting the affected application to log a specially crafted string.

Log4Shell was reported to Log4j developers by the Alibaba cloud security team on November 24, 2021, and a patch was made available on December 6, with the release of version 2.15.0. Proof-of-concept (PoC) exploits were developed shortly after.

How does the vulnerability work?

Log4j2 (the current version of Log4j) supports, by default, a logging feature called “Message Lookup Substitution”. This feature enables certain special strings to be replaced, at the time of logging, by other dynamically-generated strings. For example, logging the string Running ${java:runtime} will yield an output similar to: 

Running Java version 1.7.0_67

In particular, it has been discovered that one of the lookup methods, the JNDI lookup paired with the LDAP protocol, will fetch a specified Java class from a remote source and deserialize it, executing some of the class’ code in the process. This basically means that if any part of a logged string can be controlled by a remote attacker, the remote attacker gains remote code execution on the application that logged the string.

Why is this vulnerability so dangerous?

This vulnerability got the highest CVSS score possible, a 10 out of 10. The main reasons for that are:

1 - Easy to exploit, a lot of public working exploits out there.

2 - Log4j2 is one of the most popular Java logging frameworks. There are currently almost 7,000 Maven artifacts that depend on log4j-core (the vulnerable artifact), and there are countless others Java projects that use it.

3 - The vulnerability can easily be used in a drive-by-attack scenario by bombarding random HTTP servers or, alternatively, a specific webapp can be brute-forced by filling all available HTML input fields with the payload string, using automated tools such as XSStrike.

4. The vulnerability is context-dependent, since arbitrary user input must reach one of the Log4j2 logging functions. It’s pretty common to find strings dynamically printed, given that it’s usually considered a safe practice.

How can you stay safe?

Every business that uses technology uses defensive tools, whether they are an enterprise with an IT team of 50 people, or they’re a mom and pop business that uses a managed service provider. Even our computers have had simple anti-virus and other security measures for over 30 years. But when it comes to cybersecurity plans, offensive tools are severely undervalued. 

Offensive tools use a hacker’s point of view to truly test your defenses. Even the best programmers or defensive teams can have blindspots when creating technologies, and offensive experts are able to take a more objective view. By testing your environment, you have the opportunity to fix the vulnerabilities before malicious hackers find them. 

Currently, Red Sentry’s Attack Surface Scanner performs a wide range of exploits to validate if any of your assets is actually vulnerable to a certain kind of attack. Among those working exploits, we have a Log4Shell scanner (specifically for CVE-2021-44228), which uses the most common flow of attack to inject code into the headers of a request made to the asset URL, and check if an engagement was possible. So, it gives us no more than a Proof of Concept, without putting your information at risk.

Staying ahead of the curve

In order to cover other flows of attack and Log4j vulnerabilities out there, the Red Sentry development team is currently working on an RS Interactive Shell feature, which allows us to check for a unique variety of engagements and attacks. This new feature will be launched to our platform during this first quarter, and may be the difference between your company being protected and being exposed. Contact us for more information.