Tuesday, July 23, 2024
EHA

New zero-day in the Log4j Java Library Exploiting in Wide

In the popular Java logging library log4j (version 2) a new critical zero-day vulnerability was discovered recently, and this zero-day is a Remote Code Execution (RCE) flaw that could be exploited by the threat actors by logging a certain string.

Due to this zero-day flaw, the home users and enterprises are exposed to ongoing remote code execution attacks. Log4j is widely utilized by both enterprise apps and cloud services since it is a Java-based logging utility that is developed by the Apache Foundation.

Flaw profile

  • CVE ID: CVE-2021-44228
  • Flaw Type: Remote Code Execution (RCE) flaw
  • Description: Apache Log4j2 <=2.14.1 JNDI features used in the configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
  • Source: Apache Software Foundation
  • Severity: Critical
  • Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
  • Credit: This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.

Affected versions of Apache log4j2

Here we have mentioned below the affected versions of Apache log4j2:-

  • 2.0 <= Apache log4j <= 2.14.1

Flaws detected and fixed

Here below we have mentioned all the flaws that are detected and already fixed:-

  • CVE-2021-44228 is fixed in Log4j 2.15.0.
  • CVE-2020-9488 is fixed in Log4j 2.13.2.
  • CVE-2017-5645 is fixed in Log4j 2.8.2.

PoC – Apache log4j

Who is affected?

This critical zero-day flaw has affected several popular services and apps like:-

  • Steam
  • Apple iCloud
  • Minecraft
  • Amazon
  • Cloudflare
  • Twitter

In Apple’s servers, a simple change in iPhone’s name triggers the vulnerability. However, after the discovery of this severe zero-day flaw several affected services have already started fixing their usage of log4j2.

While the LDAP attack vector has not affected the JDK versions greater than:-

  • 6u211
  • 7u201
  • 8u191
  • 11.0.1

Since the com.sun.jndi.ldap.object.trustURLCodebase is set to false in these versions due to which using LDAP attack vector the JNDI is not able to load remote code.

Temporary & Permanent Mitigation

Experts have recommended users to follow immediately all the mitigation properly, and here they’re:-

Temporary Mitigation:

  • Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files (only works on versions >= 2.7).

OR

  • Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class.

Permanent Mitigation:

Without the vulnerability, the latest version 2.15.0 of log4j has been released, and on the Maven Central, the log4j-core.jar is available. Moreover, from the Apache Log4j Download page, the latest release can also be downloaded.

The CVE-2021-44228 can only be exploited if the log4j2.formatMsgNoLookups parameter is set to false. As in Log4j 2.15.0 release this parameter is set to true, simply to prevent attacks. 

This implies that the Log4j users who have upgraded to version 2.15.0 and then set the flag to false will again become vulnerable to attacks. 

While the users who have not updated yet, and have set the flag to true, will be able to block these attacks even on the older versions as well. However, currently, all the older versions are vulnerable, where by default this parameter is set to “false.”

For this reason, the threat actors are actively scanning the network in search of apps that are vulnerable to Log4Shell, so, at this point to stay safe, it’s highly recommended by the experts to immediately apply all available patches and follow the mitigations properly.

You can follow us on LinkedinTwitterFacebook for daily Cybersecurity and hacking news updates.

Website

Latest articles

SonicOS IPSec VPN Vulnerability Let Attackers Cause Dos Condition

SonicWall has disclosed a critical heap-based buffer overflow vulnerability in its SonicOS IPSec VPN....

Hackers Registered 500k+ Domains Using Algorithms For Extensive Cyber Attack

Hackers often register new domains for phishing attacks, spreading malware, and other deceitful activities. Such...

Hackers Claim Breach of Daikin: 40 GB of Confidential Data Exposed

Daikin, the world's largest air conditioner manufacturer, has become the latest target of the...

Emojis Are To Express Emotions, But CyberCriminals For Attacks

There are 3,664 emojis that can be used to express emotions, ideas, or objects...

Beware Of Fake Browser Updates That Installs Malicious BOINC Infrastructre

SocGholish malware, also known as FakeUpdates, has exhibited new behavior since July 4th, 2024,...

Data Breach Increases by Over 1,000% Annually

The Identity Theft Resource Center® (ITRC), a nationally recognized nonprofit organization established to support...

UK Police Arrested 17-year-old Boy Responsible for MGM Resorts Hack

UK police have arrested a 17-year-old boy from Walsall in connection with a notorious...
Guru baran
Guru baranhttps://gbhackers.com
Gurubaran is a co-founder of Cyber Security News and GBHackers On Security. He has 10+ years of experience as a Security Consultant, Editor, and Analyst in cybersecurity, technology, and communications.

Free Webinar

Low Rate DDoS Attack

9 of 10 sites on the AppTrana network have faced a DDoS attack in the last 30 days.
Some DDoS attacks could readily be blocked by rate-limiting, IP reputation checks and other basic mitigation methods.
More than 50% of the DDoS attacks are employing botnets to send slow DDoS attacks where millions of IPs are being employed to send one or two requests per minute..
Key takeaways include:

  • The mechanics of a low-DDoS attack
  • Fundamentals of behavioural AI and rate-limiting
  • Surgical mitigation actions to minimize false positives
  • Role of managed services in DDoS monitoring

Related Articles