Log4j Vulnerability – What you should be doing NOW

Apache log4j is an open-source logging utility that is bundled within numerous Java applications around the world for the purpose of logging and troubleshooting. On December 9, 2021, a remote code execution (RCE) vulnerability in Apache log4j 2 was identified and has been exploited since then. This vulnerability was rated a 10 out of 10 on the Common Vulnerability Scoring System, or CVSS, due to the potential impact that it can have if leveraged by attackers. The details are documented under the heading CVE-2021-44228.

According to James Wetter and Nicky Ringland, Open-Source Insights Team, more than 35,000 Java packages, amounting to over 8% of the Maven Central repository (the most significant Java package repository), have been impacted by the recently disclosed log4j vulnerabilities, with widespread fallout across the software industry.

As of December 16, 2021, 35,900 of the available Java artifacts from Maven Central depend on the affected log4j code. This means that more than 8% of all packages on Maven Central have at least one version that is impacted by this vulnerability.

Log4j Vulnerability – What you should be doing NOW

It is essential to understand the dependencies on software development. Most artifacts that depend on log4j do so indirectly.The deeper log4j is embedded in the application, the more time-consuming it is to rewrite the portion of the dependency. Thus, the vulnerability is in a dependency chain and calls for a lot of intermediate steps for fixing this issue.

The Log4j library is embedded in almost every Internet service or application we are familiar with, including Twitter, Amazon, Microsoft, Minecraft, SAP, ABB, and more.Given the number of combinations and options, the newly introduced protections at times may not help, as attackers have many alternatives to bypass them. It simply means multi-layered security posture, and not single-layer protection, is the need-of-the-hour to ensure resilient protection.

AUTHOR

Srikara Chamrajnagar

Srikara Chamrajnagar

Senior Vice President and Practice Head, Cloud and Infrastructure Services

SUBJECT TAGS

#Log4j Vulnerability
#Cybersecurity
#Open source packages
#Remote Code
#Cloud Security
#Threats
#Identity Theft

Proof-of-concept code to abuse the insecure logging library also spreads across the web. This makes this whole situation dangerous because the code is so prevalent, it is easy to exploit, and there are plenty of working examples of attack code out there while many systems remain unpatched.

As a corporate, we need to do the following with respect to corporate software within the environment supporting the day-to-day operations.

  1. Identify the list of software used within the organization from the software CMDB and group them on vendors.
  2. Re-assess the criticality of the data managed by the application and connect with the stakeholders. Keep the stakeholders informed.
  3. Reach out/check with each vendor on the status of Log4J vulnerability and get your assurance.
  4. If the vendor has proposed a patch, then patch your application by following the patching guidelines as described by the vendor.
  5. Follow the vendor site for patch updates frequently to ensure that there are no more issues that need to be addressed.
  6. Connect with the Security team to keep a watch on the Outbound connections.

Further, as an enterprise, you may also need to do the following with respect to your internal security operations:

  • Ensure your firewall threat feeds is in place and updated.
  • With the help of your SOC, identify the list of Indicators of Compromise (IOC).
  • Validate the gateway firewall traffic for identified outbound connections and block the IPs.
  • Use Nessus with Log4j plugin to identify the list of software with log4j vulnerability
  • Segregate the applications and reach out to vendors for patches.
  • Watch out for unusual traffic as mapped by MITTRE framework in the network operations and security operations.
  • Watch out for SOAR indicators and the layers traversed for better mitigation and protection

HTC’s Accelerated Log4j Response:

HTC’s top priority remains the security of our clients and products. We are actively tracking the latest Log4j developments and updating our products and services accordingly. As we write this article, our development teams are releasing remediation for Log4j as fast as possible, updating the patches, and moving to the latest version that’s available. We have addressed this critical cybersecurity issue for many of our clients and are on the way to reaching out to others.

    Talk To Our Experts






    All fields marked with * are mandatory
    Arrow upward