Log4Shell Vulnerability Summary

Photo by Markus Spiske on Unsplash

Log4Shell Vulnerability Summary

The Chief - Omar's photo
The Chief - Omar
·

4 min read

Table of contents

Bismillah

Back in 2021, a report was published on the Log4jshell vulnerability common in Log4j assets for both IT and cloud assets.

As a summary, I was able to gather the following information on the vulnerability, which systems are vulnerable to Log4Shell, how it affects these systems, and how it can be mitigated. Sources are included in the last section of the blog post.

What is Log4Shell?

In summary, it is a Remote Code Execution Vulnerability that affects Apache's Log4J library versions:

  • 2.0-beta9.

  • 2.14.1.

The vulnerability can be seen in the action the Java Naming and Directory Interface(JDNI) implements to resolve variables.

Before we get deeper into JDNI, you might be wondering what the Log4J library is. In a few words, Log4J is a Java-based logging library used in a range of consumer and enterprise services, websites, apps, and more.

Back to JDNI, the features affected by this vulnerability include:

  • Message.

  • Lookup substitution.

Systems Vulnerable

The systems vulnerable to this attack include any IT or Cloud assets that implement the Log4J for the vulnerable versions.

Impact On Systems

The Log4J vulnerability was rated as critical by Apache, alongside CVE-2021-45046.

Back to impact, the vulnerability is rated as critical since:

  • Java is used extensively across IT platforms for major infrastructure.

  • Log4J is easy to exploit and has a resource-intensive mitigation process.

  • Log4J allows malicious actors to run code remotely on vulnerable networks and take control of full systems.

According to the FBI, some of the common attempts at exploiting this vulnerability have been attempts to scan for and gain access to networks to deploy crypto-mining and botnet malware.

How To Mitigate

In complete honesty, the full mitigation strategy requires a whole blog post by itself, so for this one, I'll just go through an overview of the recommendations by CISA:

  1. For Vendors:

    1. Immediately identify, mitigate, and update products as follows:

      • Java 8 or higher: Upgrade Log4J version to 2.17.0

      • Java 7: Upgrade to Log4J version 2.13.0, or just upgrade to Java 8 as Java 7 is end of its life.

    2. Inform end users of products affected by the vulnerability.

  2. For Affected Organizations with IT and Cloud assets

    1. Identify vulnerable assets in your environment

      1. Inventory all assets that make use of Log4j.

      2. Identify the inventoried assets that are likely vulnerable

    2. Mitigate known and suspected vulnerable assets in your environment

      1. Treat known and suspected assets as compromised.

      2. Patch Log4j and other affected products to the latest version.

      3. Keep an inventory of known and suspected vulnerable assets and what is done with them throughout this process(track patching).

        • To ensure/check if a threat actor compromised an asset and then patched it to hide their operations.

      4. Verify the mitigation has worked:

        • Scan patched assets.

        • Monitor the assets carefully.

        • Remain alert to changes from vendors for the software on the asset.

    3. Initiate hunt and incident response procedures.

      • Hunt for signs of exploitation and compromise.

      • If compromise is detected, orgs should:

        • Initiate incident response procedures

        • Consider reporting compromises immediately to applicable cybersecurity authorities.

    4. Evaluate and apply other mitigations.

      • Remain alert to changes from vendors for the software on the asset, and immediately apply updates to assets when notified by your vendor of an available patch.

      • Continue monitoring Log4j assets closely.

      • Continue to monitor the Apache Log4J Security Vuln webpage(https://logging.apache.org/log4j/2.x/security.html) for updates.

      • Block specific outbound TCP and UDP network traffic.

  3. For organizations with OT/ICS Assets:

    1. Review their operational architecture and enumerate the vulnerability status against current product alerts and advisories.

      • For products with no security advisory specifically against the status of the vuln, treat them with additional protections.

    2. Implement the identification and isolation steps in the above section for vulnerable assets.

    3. Use a risk-informed decision-making process to apply the latest version of hotfixes or patches.

    4. Minimize network exposure for all control system devices and/or systems.

    5. Locate control system networks and remote devices behind firewalls and isolate them from the business network.

Recap

A lot has been said, a lot of technical information to process, so take a breather now. If you need more info on the vulnerability, do follow the links in the section below.

Otherwise, see you next time In shaa Allah.

Sources

https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a

More info: https://www.ncsc.gov.uk/blog-post/log4j-vulnerability-what-should-boards-be-asking

JavavulnerabilitySecurity