Dec 19, 2021
130 Views
0 0

Upgraded to log4j 2.16? Surprise, there's a 2.17 fixing DoS

Written by

TellYouThePass ransomware revived in Linux, Windows Log4j attacks
Credit card info of 1.8 million people stolen from sports gear sites
CISA urges VMware admins to patch critical flaw in Workspace ONE UEM
All Log4j, logback bugs we know so far and why you MUST ditch 2.15
New stealthy DarkWatchman malware hides in the Windows Registry
This $19 bundle helps fill your résumé with CompTIA certifications
Western Digital warns customers to update their My Cloud devices
Save 50% on access to 2,400 hours of IT training from ITU Online
Qualys BrowserCheck
STOPDecrypter
AuroraDecrypter
FilesLockerDecrypter
AdwCleaner
ComboFix
RKill
Junkware Removal Tool
How to remove the PBlock+ adware browser extension
Remove the Toksearches.xyz Search Redirect
Remove the Smashapps.net Search Redirect
Remove the Smashappsearch.com Search Redirect
Remove Security Tool and SecurityTool (Uninstall Guide)
How to remove Antivirus 2009 (Uninstall Instructions)
How to Remove WinFixer / Virtumonde / Msevents / Trojan.vundo
How to remove Google Redirects or the TDSS, TDL3, or Alureon rootkit using TDSSKiller
Locky Ransomware Information, Help Guide, and FAQ
CryptoLocker Ransomware Information Guide and FAQ
CryptorBit and HowDecrypt Information Guide and FAQ
CryptoDefense and How_Decrypt Ransomware Information Guide and FAQ
How to make the Start menu full screen in Windows 10
How to install the Microsoft Visual C++ 2015 Runtime
How to open an elevated PowerShell Admin prompt in Windows 10
How to Translate a Web Page in Google Chrome
How to start Windows in Safe Mode
How to remove a Trojan, Virus, Worm, or other Malware
How to show hidden files in Windows 7
How to see hidden files in Windows
eLearning
IT Certification Courses
Gear + Gadgets
Security
log4j
All set for the weekend? Not so fast. Yesterday, BleepingComputer summed up all the log4j and logback CVEs known thus far.
Ever since the critical log4j zero-day saga started last week, security experts have time and time again recommended version 2.16 as the safest release to be on.
That changes today with version 2.17.0 out that fixes a seemingly-minor, but ‘High’ severity Denial of Service (DoS) vulnerability that affects log4j 2.16.
And, yes, this DoS bug comes with yet another identifier: CVE-2021-45105.
Suspicion of a DoS bug affecting log4j 2.16.0 arose on Apache’s JIRA project about three days ago, shortly after 2.15.0 was found to be vulnerable to a minor DoS vulnerability (CVE-2021-45046).
As reported by BleepingComputer yesterday though, severity for CVE-2021-45046 was upped from a Low (3.7) to a Critical (9.0) by Apache, after newer bypasses allowed the possibility of data exfiltration via this exploit.
“If a string substitution is attempted for any reason on the following string, it will trigger an infinite recursion, and the application will crash,” state the JIRA issue, with a PoC payload:
A few hours ago, security researchers including vx-underground and Hacker Fantastic tweeted about a possible Denial of Service flaw affecting log4j version 2.16 as well:
New exploit on Friday, as is tradition: Researchers have discovered Log4J version 2.16 is vulnerable to DoS via “${${::-${::-$${::-j}}}}”

More info: https://t.co/pzeWiQEa68
And it turns out, after debating the issue over a course of the last three days, Apache did assign a new CVE and has rolled out a fresh release.
Tracked as CVE-2021-45105, and scored ‘High’ (7.5) on the CVSS scale, the DoS flaw exists as log4j 2.16 “does not always protect from infinite recursion in lookup evaluation.”
Although JNDI lookups were completely disabled in version 2.16, self-referential lookups remained a possibility under certain circumstances. 
“Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups,” state the version’s release notes seen by BleepingComputer.
“When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, “${dollar}${dollar}{ctx:loginId}“), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process.”
To fix the vulnerability, log4j version 2.17.0 (for Java 8) has been released today and allows only “lookup strings in configuration” to expand recursively. In any other usage, only the top-level lookup would be resolved, and not any nested lookups.
The version is expected to reach the largest Java package repository, Maven Central later today.
Although Apache has officially released details on the upcoming 2.17.0 release so far, GitHub commits seen by BleepingComputer indicate a release 2.12.3 might also be on its way for those on the 2.12.x branch versions.
The development comes around the same time as Google’s analysis that reveals over 35,000 Java packages contain log4j vulnerabilities.
“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,” explain James Wetter and Nicky Ringland of Google’s Open Source Insights Team in yesterday’s blog post.
According to Google, the vast majority of vulnerable Java packages in Maven Central borrow log4j “indirectly”—that is log4j is a dependency of a dependency used by the package, a concept also referred to as transitive dependencies.
Out of the 35,863 packages identified by Google, just about 7,000 borrowed log4j directly, indicating not all developers may have adequate visibility into their software: 
“User’s lack of visibility into their dependencies and transitive dependencies has made patching difficult; it has also made it difficult to determine the full blast radius of this vulnerability,” explains Google.
Looking at the history of publicly disclosed critical vulnerabilities affecting Maven packages, and the fact less than 48% of these packages had a fix applied for these, Google researchers predict “a long wait, likely years” before log4j flaws are completely eliminated from all Java packages.
As reported by BleepingComputer, threat actors are targeting vulnerable servers with log4j exploits to push malware, with the Conti ransomware gang specifically eying vulnerable VMWare vCenter servers.
As such, organizations should upgrade to the latest log4j versions and continue to monitor Apache’s advisories for updates.
All Log4j, logback bugs we know so far and why you MUST ditch 2.15
Log4j: List of vulnerable products and vendor advisories
Log4j attackers switch to injecting Monero miners via RMI
Hackers start pushing malware in worldwide Log4Shell attacks
Researchers release ‘vaccine’ for critical Log4Shell vulnerability
Not a member yet? Register Now
This image looks very different on Apple devices — see for yourself
Conti ransomware uses Log4j bug to hack VMware vCenter servers
To receive periodic updates and news from BleepingComputer, please use the form below.
Terms of Use Privacy PolicyEthics Statement
Copyright @ 2003 – 2021 Bleeping Computer® LLC – All Rights Reserved
Not a member yet? Register Now
Read our posting guidelinese to learn what content is prohibited.

source

Article Categories:
Cybersecurity News

Comments are closed.