Log4j: Critical Remote Code Execution Threat, Risk Evaluation Insights

The flaw, which was found to allow unauthenticated remote code execution and access to servers, was discovered first in Minecraft on December 9th, but experts are warning cloud users may also be at risk. There is a variety of software that is potentially vulnerable to being exploited since Log4j is a part of so many different forms of enterprise and open-source software, ranging from email services, cloud platforms, and web applications. The severity of this risk has been deemed a 10 out of 10 after exploits began on the 1st of December. Back in 2013, however, the code was first introduced into the codebase that has now been exploited since December 1st, nine days after public disclosure.

CISA’s Advisory And Evaluating Your Risk

The Apache Software Foundation addressed the concern that is affecting versions 2.0beta9 to 2.14.1 with an update, 2.15.o-rc1. CISA has recommended admin and users either upgrade to the latest patch or apply the recommended mitigations to reduce the vulnerability. An organization that has been using the aforementioned versions of Log4j should examine log files that may have been compromised. If you notice user-controlled strings, “Jndl:Idap” could be among those affected. To best mitigate vulnerabilities, it is recommended users change log4j2.formatMsgNoLookups to true by adding:  "‐Dlog4j2.formatMsgNoLookups=True". As well as the recommended mitigations, the original CVE includes some vendor descriptions and tools that can be used to test your own systems against this vulnerability after patching to make sure you're protected.

On December 17th, it was confirmed that two new issues had been discovered and the following day, Apache released another patch. It is expected that this will be an ongoing cycle of discovering new vulnerabilities, releasing a patch, rinse and repeat as both attackers and research continue to focus efforts on Log4j.

Resources for Determining Your Exposure

The vulnerability has been deemed a 10.0 on the CVSS scale so it is crucial that you evaluate your risk level. Complications stem from the different ways that Log4j can be deployed, such as a java project or installed directly from the source or in different packages. Below are methods for identifying your vulnerabilities to log4j:

• The easiest way to detect if a vulnerability is by triggering a DNS query. CanaryTokens.org is an Open Source web app that automatically scans for the exploit string and will notify you via email notification when the DNS is queried.
• Comb through your logs for IP addresses that are commonly associated with attackers and then add them to your blocked list.
• GitHub users using Maven can use Dependabot to identify any location that has explicitly declared depending on Log4j. After enabling, you’ll be notified of the upgraded patch, which has already sent over 175,000 requests to users. This technique doesn’t work for Gradle or other managers for java dependencies, but GitHub is working to include the capability for Gradle in an upcoming update.
• You can also use the following for active or dynamic testing: 
  • NMAP Scripting Engine - NSE scripts work by checking the most popular exposed services on the internet, in this case, log4j vulnerabilities.
  • CyberReason - After configuring the settings to disable the lookup mechanism, the vulnerability is flagged insufficient and all other JNDI mechanisms will fail as well, and the log4j jarfile will be remade and patched.
  • Huntress Tester - Copy and paste the generated JNDI syntax provided into application input boxes, username inputs, or even other customizable HTTP headers. Check the results page for any connections and after verifying a detected IP address and timestamp, you can confirm the tested application is vulnerable.
  • FullHunt - An automated and extensive scanner that locates vulnerable hosts, that features support lists of URLs, fuzzing for more than 60 HTTP request headers, fuzzing for HTTP POST and JSON data parameters, and supports DNS callback for vulnerability discovery and validation.
  • Yahoo Check for Log4j -This works to try and determine if the host is likely to be vulnerable to log4j, as opposed to previous tools which specify what service is liable for exploitation by triggering the exploit.

How Far The Exploitation Is Going

Researchers at Check Point have reported attackers making at least 100 attempts every minute of scanning the internet for chances to exploit this vulnerability of Log4j. Bugcrowd founder and CTO Casey Ellis said, “This is a worst-case scenario. The combination of log4j's ubiquitous use in software and platforms, the many, many paths available to exploit the vulnerability, the dependencies that will make patching this vulnerability without breaking other things difficult, and the fact that the exploit itself fits into a tweet. It's going to be a long weekend for a lot of people… It's the kind of software that can quite easily be there without making its presence obvious, so we expect the tail of exploitability on this vulnerability to be quite long." These attackers are aiming to install cryptocurrency-mining malware, as well as reports of several botnets attempting to take advantage of the flaw in the code, including Mirai, Tsunami, and Kinsing. Microsoft researchers are also stating concern over active efforts of cryptomining malware and the potential to have Cobalt Strike installed on these compromised systems, which would give attackers the ability to steal usernames and passwords. Experts warn that over 40 percent of corporate networks have already been targeted and the list of vendors with popular products still considered vulnerable include Atlassian, Amazon, Microsoft Azure, Cisco, Commvault, ESRI, Exact, Fortinet, JetBrains, Nelson, Nutanix, OpenMRS, Oracle, Red Hat, Splunk, Soft, and VMware, but is even longer when factoring in products where a patch has been released. 

Fixes For Open Source Vendors

Since the vulnerability was disclosed to the public, several distributions have published their fix for their packages including:

• openSuse
• Debian
• Ubuntu
• Magela
• RedHat
• CVE-2021-44228 (CVSS score: 10.0) - A remote code execution vulnerability affecting Log4j versions from 2.0-beta9 to 2.14.1 (Fixed in version 2.15.0)
• CVE-2021-45046 (CVSS score: 9.0) - An information leak and remote code execution vulnerability affecting Log4j versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 (Fixed in version 2.16.0)
• CVE-2021-45105 (CVSS score: 7.5) - A denial-of-service vulnerability affecting Log4j versions from 2.0-beta9 to 2.16.0 (Fixed in version 2.17.0)
• CVE-2021-4104 (CVSS score: 8.1) - An untrusted deserialization flaw affecting Log4j version 1.2 (No fix available; Upgrade to version 2.17.0)

It is recommended that you follow Apache’s advice and update to 2.17.0 as soon as possible.

Visit our Linux Security Advisories page for more updates.

Putting A Patch On The Problem

Log4j was released for mass usage 20 years ago in 2001, leaving many wondering how long has the flaw in the code been wild and why it took so long to have been discovered and taken advantage of. Why wasn’t it reviewed sooner and how might we keep this source code from being vulnerable to exploitation in the future? Two things are certain, this is a serious threat that needs to be remedied as soon as possible, and it is crucial to stay on top of the latest security vulnerabilities and the updates and patches issued to remedy them.