Skip to main content

Log4Shell Is the Most Dangerous Exploit Since Shellshock

Mike Wilkes
Posted on December 10th, 2021

How to Know if You’re Impacted and How to Remediate

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. (Remote code execution is a cyber-attack whereby an attacker can remotely execute commands on someone else's computing device.) Use of Log4j dates back as far as 2001, and today the open-source tool is an integral part of popular frameworks, including Apache Struts2, Apache Solr, Apache Druid, and Apache Flink.

What SecurityScorecard is doing

SecurityScorecard has taken the immediate step of updating all Log4j installs present in our environment, and we encourage our partners and customers to do the same. Unauthenticated RCE activity has the potential to be incredibly dangerous, and organizations cannot afford to put themselves at such significant risk. The sooner organizations determine their vulnerability to this flaw and take the necessary steps to mitigate it, the safer the Internet will be.

Explaining Log4j and Log4Shell

Millions of applications use Log4j for logging, and the package is embedded in a range of open-source projects and tools. In most cases, a logging library has just one job: pass through the logging event string and record it somewhere based on the configurations in the settings file. Log4j parses the contents of each event string to check whether it contains any variables that need to be resolved or transformed.

This presents an opportunity for attackers. An event string malformed can take advantage of default security settings to permit remote code execution. It is difficult to overstate how significant of a vulnerability this is. RCE vulnerabilities can be exploited by cybercriminals to gain unauthorized access to systems and applications, including phones, tablets, workstations, smart TVs, thermostats, and other devices. Because Log4j is so ubiquitous, the discovery of an RCE vulnerability within it is a legitimate “red alert” situation for the cybersecurity community. Log4Shell has the potential to be the most dangerous and impactful exploit since the Shellshock vulnerability was discovered in 2014.

Is your organization impacted?

Any organization with assets running a version of Log4j above version 2.0 and below version 2.15.0 (the fixed version release) is likely impacted by the vulnerability. Most organizations can check their most recent vulnerability scan results, which likely contain the location of any Log4j installations active within the environment. It is also possible to query cloud application logs for strings matching the syntax “jndi.ldap.” This will identify any instances of scanning or active exploitation attempts—but it is important to note that a system is only potentially compromised if the request was processed by a vulnerable version of Log4j. Otherwise, the activity should not be considered suspicious.

What to do if you are vulnerable

Any organization using Log4j should update to version 2.15.0 as soon as possible. This latest version can be found on the Log4j download page. In order to be installed, this patched version requires a minimum of Java 8. It is also important to verify that multiple Log4j installs are not present on an impacted machine, as this can mean that multiple configuration files exist. Each of these can contain a vulnerable version of Log4j, and each will need to be remediated independently.

Moving forward with caution

Although the Log4Shell vulnerability was only just discovered, examples of attackers scanning for the exploit have already been detected in the wild. Organizations should continue to review their logs for suspicious scans and activity; however, as noted above, the exploitation string will be logged by a platform, whether it is running a vulnerable version of Log4j or not. Ensuring that all installations of Log4j are updated to the newest, patched version remains the most critical step toward securing an organization’s applications and services.

To check your cyber posture for thousands of other vulnerabilities within an instant, sign up for your free SecurityScorecard account here.


Return to Blog
Join us in making the world a safer place.