How to Fix Log4j Vulnerability on Windows/MAC?

Log4J, a logging application used by nearly every cloud computing service and enterprise network, has been exploited in the wild by a code execution zero-day.

In response, developers released an update patching the flaw, which they encouraged users to install immediately. However, researchers are now reporting at least two vulnerabilities in the patch, which was released as Log4J 2.15.0.

What is Log4j, and what is it used for?

The Log4j Tutorial is intended for both beginners and experts. Our tutorial covers all of Log4j’s fundamental and advanced topics, including installation, architecture, and setup. Log4j is a java-based logging system that is quick, dependable, and customizable. It’s a Java logging API that’s open-source.

Simply said, logging is a method of indicating the current status of a system during runtime. Logs are used to gather and save vital data so that it may be analysed at any point in time.

Log4shell is a major flaw in the widely used logging programme Log4j, which is used by millions of machines hosting internet services across the world. It is expected to influence a wide spectrum of people, including organisations, governments, and individuals. Despite the fact that patches have been published, they must still be installed.

Large, powerful, and complicated software may be found in today’s world. Rather than a single author creating all of the code themself, as was the case decades before, modern software development will include big teams, and software will increasingly be composed of ‘building blocks’ assembled by the team rather than produced fully from scratch.

When they can use existing code right away, a team is unlikely to spend weeks building new code.

Log4j is one of the numerous building elements used in modern software development. Many organisations utilise it to do a common but crucial task. This is referred to as a software library.’

Developers use Log4j to track what happens in their software applications or internet services. It’s essentially a massive log of a system’s or application’s activities. This practice is known as logging, and it is utilised by developers to keep track of user issues.

What is Log4j Vulnerability?

Last week, a flaw in Log4j, an open-source logging framework widely used by apps and services on the internet, was discovered. Attackers can get into systems, steal passwords and logins, extract data, and infect networks with malicious software if the problem is not solved. (Remote Code Execution)

Log4j is widely used in software and online services throughout the world, and exploiting the vulnerability needs very little technical knowledge. As a result, Log4shell might be the most serious computer vulnerability in years.

What is the impact of Log4j Vulnerability?

Almost any programme will have the ability to log in some way (for development, operations, and security), and Log4j is a popular component for this.

Log4j is almost definitely a component of the devices and services you use on a daily basis if you’re an individual. The greatest thing you can do to protect yourself is to keep your gadgets and programmes as current as possible and to update them on a frequent basis, especially in the coming weeks.

How to Fix Log4j Vulnerability on Windows/MAC?

Every organisation is trying to build a patch that could counter this vulnerability. To fix the Log4j vulnerability, first, check if your server is vulnerable to Remote Code Execution through Log4j.

Step 1) Find if your System or Server is Vulnerable to Log4j

The most straightforward approach to see if you’re susceptible is to utilise huntress.com’s free service, which provides you with a string token that you can use to test your application’s input fields. A new connection will appear in the huntress.com connection panel if your app is vulnerable.

It’s not necessary to test through an organization’s environment, you can test in your own local environment and fix the Log4j vulnerability locally. Visit the Huntress Log4J Free Testing environment and check for the result.

fix log4j vulnerability
Fix Log4j Vulnerability on Huntress Free Testing Environment

Step 2) Apply Fix Log4j Vulnerability through the below steps

Fix 1)

To Fix Log4j Vulnerability, one can either upgrade your Log4j version to the latest release patch or check again on Huntress Log4J Testing environment. Check out the latest release Fix Log4j Vulnerability patch on Apache Log4j Security Vulnerabilities Official Website

apache fix log4j vulnerabilities security
Apache Fix Log4j Vulnerabilities security

Fix 2)

Set a specific environment variable to turn off this feature. This only works with the latest versions of Tableau Server (the oldest version tested successfully was 2021.1.3 but it was reportedly not working on 2020.2).

Fix 3)

Remove the Log4j code that is causing the issue from the installation, which was found on the Huntress Log4J Testing environment. This is a more complicated (and perhaps hazardous) technique, but it works with all versions of the Server.

The above fixes have been found to be working, it’s not a guaranteed fix, but it’s worth finding the vulnerability on your server/system. These methods can be applied to both Windows/Linux/MAC or any other Operating System.

Why it’s necessary to Fix the Log4j Vulnerability?

Experts claim that the Log4j vulnerability, also known as the Log4Shell problem (CVE-2021-45046), might enable for the exfiltration of sensitive data in some scenarios. Simply put, the vulnerability might allow thieves to steal data or remove data from a device without permission.

Given the “ubiquitous” prevalence of the Log4j logging library, the Log4j or Log4Shell vulnerability was identified last Friday and is considered a major weakness, maybe one of the worst. This is an open-source logging package that practically every major Java-based corporate software and server in the industry uses. A logging library is used to keep track of all of an application’s activities.

By introducing a string of code into the library, any hacker or cyber criminal may control and execute ‘arbitrary code’ and get access to a computer system.

Researchers at Alibaba were the first to notice the problem, and Microsoft’s Minecraft soon followed with a statement stating that they, too, were affected. According to experts, the issue affects many businesses and web services, including Apple’s iCloud and Google Cloud products, among others. According to researchers, exploits for this weakness already exist and are being utilised in cryptocurrency mining frauds.

According to cybersecurity firm Praetorian, the vulnerability might lead to data theft, and they’ve informed the Apache Foundation, which manages the Log4j library, about the problem. All clients using Log4j versions 2.15.0 and lower should upgrade to 2.16.0 as soon as feasible, according to the company.

The cybersecurity firm has only provided a video depicting the data exfiltration, claiming that sharing technical information would “only complicate matters.”

Meanwhile, other companies claim that attacks based on Log4j are on the rise. “The whole Internet is being searched at the moment — at least two botnets are hunting for unpatched vulnerabilities, and we’ll be seeing more in the coming days,” Kevin Reed, CEO of Singapore-based cybersecurity firm Acronis CISO, stated. Prior to Friday, we identified exploitation attempts in the single digits; but, during the weekend, we witnessed a 300-fold increase worldwide. It’s difficult to identify which are targeted exploitations — they’re unlikely to be traced at the time.”

Candid Wuest, Acronis VP of Cyber Protection Research, compared the vulnerability to EternalBlue, which was used by WannaCry ransomware, and said that “the Log4shell vulnerability in Log4j is definitely in the top-5 most severe vulnerabilities of the last decade, one that allows for remote code execution (RCE),” and that it will take longer to patch because it is “not just one vulnerable software that can be updated, but rather a library that’s included in many applications, to result.

The history behind Fix Log4j Vulnerability

The severity level has risen to Critical

Since the publication of this CVE, security experts have discovered further vulnerabilities against the Log4j 2.15.0 version, which might lead to information leaks, RCE (remote code execution), and LCE (local code execution) attacks.

The base CVSS score was modified from 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) to 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) to 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:

The naming of this CVE has been updated to mention Remote Code Execution attacks rather than Denial of Service threats.

This only affects Pattern Layouts that use a Context Lookup (for example, $$ctx:loginId). The Thread Context Map pattern (percent X, percent mdc, or percent MDC) in the layout would also allow this vulnerability, which was originally wrongly stated on this page.

While Log4j 2.15.0 does its best to limit JNDI LDAP lookups to localhost by default, there are ways to circumvent this and users should not rely on it.

Mitigation strategies from the past that have been proven to be ineffective

Other mitigation techniques were given on this page earlier, however we observed that they merely restrict exposure while keeping certain attack paths accessible.

Setting the system property log4j2.formatMsgNoLookups or the environment variable LOG4J FORMAT MSG NO LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with percent mnolookups, percent msgnolookups, or percent messagenolookups for releases >= 2.7 and 2.14.1 are other insufficient mitigation measures.

These safeguards are insufficient since, in addition to the Thread Context attack vector outlined above, there are still code paths in Log4j that might result in message lookups: Applications that employ Logger.printf(” percent s”, userInput) or custom message factories, when the output messages do not implement StringBuilderFormattable, are known instances. Other attack paths might exist.

Upgrade Log4j to a secure version or delete the JndiLookup class from the log4j-core jar to be safe.

Leave a Reply

Back to top button