Log in
Register
Cyber Forum
More options
Toggle width
Share this page
Share this page
Share
Share
Cyber Forum
Log in
Register
More options
Toggle width
Share this page
Share this page
Share
Share
Menu
Install the app
Install
Home
CyberWeekly Podcast
Breaking News! Podcast
Cyber Risk Rating
Forums
New posts
Forum list
Trending
Leaderboards
News Feeds
Resources
Latest reviews
Sophos X-Ops Intelix
Threat Reports
Members
Current visitors
My.CompTIA
Help Documents
Preference Center
Forums
Security
Active Exploits Discussion/Recommendations
Log4j Vulnerability Information
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Jonathan Braley" data-source="post: 2528" data-attributes="member: 77"><p><strong>Log4Shell Update</strong></p><p>12-17-2021</p><p></p><p>Our operations team will continue to monitor the situation over the weekend and will update here as needed.</p><p></p><p><strong>Mitigation Status:</strong></p><p></p><p>Apache released Log4j version 2.16.0 in a security update to address the CVE-2021-45046 vulnerability. A remote attacker can exploit this second Log4j vulnerability to cause a denial-of-service (DOS) condition in certain non-default configurations.</p><p></p><p><strong>Note</strong>: Affected organizations that have already upgraded to Log4j 2.15.0 will need to upgrade to Log4j 2.16.0 to be protected against both CVE-2021-44228 and CVE-2021-45046.</p><p></p><p>Per reporting today, patch 2.16.0 appears to mitigate known vulnerabilities sufficiently. It is possible more bypasses and vulnerabilities could emerge as security researchers and cybercriminal continue to investigate. We will update as necessary.</p><p></p><p>Patching a plethora of devices one by one may not be feasible, especially after companies spent countless hours already upgrading to 2.15. So using tools to disable JDNI to LDAP so that they cannot be exploited remotely could be a beneficial effort. A combination of both patching and disabling JDNI may be a viable safeguard. We have a resources section listed below.</p><p></p><p><strong>Currently Known Vulnerabilities:</strong></p><p></p><p><a href="https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/" target="_blank">https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/</a> </p><p></p><p><strong>CVE-2021-44228 [Critical]</strong>: The original 'Log4Shell' or 'logjam' vulnerability is an untrusted deserialization flaw. Rated critical in severity, this one scores a 10 on the CVSS scale and grants remote code execution (RCE) abilities to unauthenticated attackers, allowing complete system takeover.</p><p></p><p>Reported by Chen Zhaojun of Alibaba Cloud Security Team to Apache on November 24th, CVE-2021-44228 impacts the default configurations of multiple Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and others.</p><p></p><p>Being the most dangerous of them all, this vulnerability lurks in the log4j-core component, limited to 2.x versions: from 2.0-beta9 up to and including 2.14.1. A fix for Log4Shell was rolled out in version 2.15.0 but deemed incomplete (keep reading).</p><p></p><p>--</p><p></p><p><strong>CVE-2021-45046 [Critical, previously Low]</strong>: Rated low in severity, this one is a Denial of Service (DoS) flaw scoring a mere 3.7. The flaw arose as a result of an incomplete fix that went into 2.15.0 for CVE-2021-44228. While the fix applied to 2.15.0 did largely resolve the flaw, that wasn't quite the case for certain non-default configurations.</p><p></p><p>Log4j 2.15.0 makes "a best-effort attempt" to restrict JNDI LDAP lookups to localhost by default. But, attackers who have control over the Thread Context Map (MDC) input data can craft malicious payloads via the JNDI Lookup patterns to cause DoS attacsk. This applies to non-default configurations in which a non-default Pattern Layout using either a Context Lookup, e.g. $${ctx:loginId}, or a Thread Context Map pattern (%X, %mdc, or %MDC).</p><p></p><p>"Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default," states the NVD advisory. For those on 2.12.1 branch, a fix was backported into 2.12.2.</p><p></p><p>--</p><p></p><p><strong>CVE-2021-4104 [High]</strong>: Log4j 1.x and 2.x</p><p></p><p>While previously thought to be safe, Log4Shell found a way to lurk in the older Log4j too. Essentially, non-default configuration of Log4j 1.x instances using the JMSAppender class also become susceptible to the untrusted deserialization flaw.</p><p></p><p>Although a less severe variant of CVE-2021-44228, nonetheless, this CVE impacts all versions of the log4j:log4j and org.apache.log4j:log4j components for which only 1.x releases exist. Because these are end-of-life versions, a fix for 1.x branch does not exist anywhere, and one should upgrade to log4j-core 2.16.0.</p><p></p><p>--</p><p></p><p><strong>CVE-2021-42550 [Moderate]</strong>: This is a vulnerability in the Logback logging framework. A successor to the Log4j 1.x library, Logback claims to pick up "where log4j 1.x leaves off."</p><p></p><p>CVE-2021-4104 was discovered to impact Log4j 1.x as well, and the possibility of potential impact to Logback was assessed. Newer Logback versions, 1.3.0-alpha11 and 1.2.9 addressing this less severe vulnerability have now been released.</p><p></p><p>--</p><p></p><p>BleepingComputer came across multiple security researchers claiming that it is possible to achieve full-on RCE, even with 2.15.0.</p><p></p><p>"The worst possible scenario resulting from Log4j 2.15.0 is yet to be fully determined, but suffice to say, it doesn't seem like it's just limited to DoS. As the situation continues to evolve, organizations and developers are encouraged to upgrade to version 2.16.0, and to continue to monitor Apache's Log4j advisory page for updates."</p><p></p><p>"The action required by defenders is clear cut in all cases: <strong>moving to 2.16.0 where jndi is disabled by default is the safest course of action</strong>, and is the approach we're recommending for our customers."</p><p></p><p><strong>Analyst Comments:</strong></p><p></p><p>It is essential that companies identify and apply security measures to systems accessible over the internet. Protocols used for connectivity to and from internal corporate assets should have as many security controls as possible. Multifactor authentication should be enabled in systems that are accessed remotely - RDP should not be used over the WAN - VPN connections are more secure. </p><p></p><p>After initial access, according to the report from BleepingComputer, Log4j was used to leverage vCenter servers in attacks. VMWare uses a Linux-Based kernel, so it is safe to assume that VMWare is vulnerable to Log4j attacks. Companies may want to identify servers using VMware or 'anything Linux' and apply hardening measures accordingly - whether making adjustments and network isolation/segmentation at Layer 3 of the OSI model or removing access directly at NIC responsible for facilitating host access.</p><p></p><p><strong>Resources: </strong></p><p><strong></strong></p><p><strong>Indicators of Compromise:</strong></p><ul> <li data-xf-list-type="ul">Apache Log4j RCE Attempt<ul> <li data-xf-list-type="ul"><a href="https://station.trustar.co/constellation/reports/f1c259c8-e013-4709-88b3-46ff9965b9b3" target="_blank">https://station.trustar.co/constellation/reports/f1c259c8-e013-4709-88b3-46ff9965b9b3</a></li> </ul></li> <li data-xf-list-type="ul">Log4Shell Indicators<ul> <li data-xf-list-type="ul"><a href="https://station.trustar.co/constellation/reports/de9add6c-d4a7-439d-a6ff-5a03ff896d76" target="_blank">https://station.trustar.co/constellation/reports/de9add6c-d4a7-439d-a6ff-5a03ff896d76</a></li> </ul></li> <li data-xf-list-type="ul">MalwareNinja Log4Shell IoCs<ul> <li data-xf-list-type="ul"><a href="https://station.trustar.co/constellation/reports/99a112f8-54c1-4fab-8a7a-59ee2e0657c8" target="_blank">https://station.trustar.co/constellation/reports/99a112f8-54c1-4fab-8a7a-59ee2e0657c8</a></li> </ul></li> <li data-xf-list-type="ul">Azure Sentinel Log4Shell IoCs<ul> <li data-xf-list-type="ul"><a href="https://station.trustar.co/constellation/reports/5bd99330-a2a8-48d9-b8b3-f593a887ba1d" target="_blank">https://station.trustar.co/constellation/reports/5bd99330-a2a8-48d9-b8b3-f593a887ba1d</a></li> </ul></li> <li data-xf-list-type="ul">MalwareBazaar Log4Shell IoCs<ul> <li data-xf-list-type="ul"><a href="https://station.trustar.co/constellation/reports/1dc094e3-4539-4529-a7c4-607741245cd8" target="_blank">https://station.trustar.co/constellation/reports/1dc094e3-4539-4529-a7c4-607741245cd8</a></li> </ul></li> <li data-xf-list-type="ul">ThreatFox Log4Shell IoCs<ul> <li data-xf-list-type="ul"><a href="https://station.trustar.co/constellation/reports/d41b2f8b-f940-4fe5-ae95-1a6bf9d2f5df" target="_blank">https://station.trustar.co/constellation/reports/d41b2f8b-f940-4fe5-ae95-1a6bf9d2f5df</a></li> </ul></li> <li data-xf-list-type="ul">CronUp Log4Shell IoCs<ul> <li data-xf-list-type="ul"><a href="https://station.trustar.co/constellation/reports/7dde8cef-71ea-475c-8c2c-34dcfc7dd5a4" target="_blank">https://station.trustar.co/constellation/reports/7dde8cef-71ea-475c-8c2c-34dcfc7dd5a4</a></li> </ul></li> <li data-xf-list-type="ul">RedDrip7 Log4Shell IoCs<ul> <li data-xf-list-type="ul"><a href="https://station.trustar.co/constellation/reports/19bc5641-49ad-427a-8258-3bb4ac725349" target="_blank">https://station.trustar.co/constellation/reports/19bc5641-49ad-427a-8258-3bb4ac725349</a> </li> </ul></li> <li data-xf-list-type="ul">CrowdSec Log4Shell IoCs<ul> <li data-xf-list-type="ul"><a href="https://station.trustar.co/constellation/reports/55904e7d-1337-41be-8f92-db2267fc15fa" target="_blank">https://station.trustar.co/constellation/reports/55904e7d-1337-41be-8f92-db2267fc15fa</a></li> </ul></li> <li data-xf-list-type="ul">Andrew Grealy Log4Shell IoCs<ul> <li data-xf-list-type="ul"><a href="https://station.trustar.co/constellation/reports/33268837-ccd1-4c90-bc77-2fa160892857" target="_blank">https://station.trustar.co/constellation/reports/33268837-ccd1-4c90-bc77-2fa160892857</a></li> </ul></li> <li data-xf-list-type="ul">Log4Shell IoCs 12-14-2021 Pt1<ul> <li data-xf-list-type="ul"><a href="https://station.trustar.co/constellation/reports/93c0a479-9e3f-4b3f-b126-156b2b5fe01e" target="_blank">https://station.trustar.co/constellation/reports/93c0a479-9e3f-4b3f-b126-156b2b5fe01e</a></li> </ul></li> <li data-xf-list-type="ul">Log4Shell IoCs 12-14-2021 Pt2<ul> <li data-xf-list-type="ul"><a href="https://station.trustar.co/constellation/reports/265ff465-7eb1-410f-ad36-1833fcf16eca" target="_blank">https://station.trustar.co/constellation/reports/265ff465-7eb1-410f-ad36-1833fcf16eca</a></li> </ul></li> <li data-xf-list-type="ul">WatchGuard Threat Lab Log4Shell IoCs 12-17-2021<ul> <li data-xf-list-type="ul"><a href="https://station.trustar.co/constellation/reports/9b1a0163-fca6-411e-8d39-cc7e8821a7d8" target="_blank">https://station.trustar.co/constellation/reports/9b1a0163-fca6-411e-8d39-cc7e8821a7d8</a> </li> </ul></li> </ul><p><strong>Vulnerable product List from NCSC:</strong></p><ul> <li data-xf-list-type="ul"><strong><a href="https://github.com/NCSC-NL/log4shell/blob/main/software/README.md" target="_blank">https://github.com/NCSC-NL/log4shell/blob/main/software/README.md</a> </strong></li> </ul><p><strong></strong></p><p><strong>Scanning Tools and Resources:</strong></p><ul> <li data-xf-list-type="ul"><a href="https://github.com/NCSC-NL/log4shell/blob/main/scanning/README.md" target="_blank">https://github.com/NCSC-NL/log4shell/blob/main/scanning/README.md</a> </li> </ul><p></p><p><strong>NCC Group JNDI Disabling Tool</strong></p><ul> <li data-xf-list-type="ul"><strong><a href="https://research.nccgroup.com/2021/12/12/log4j-jndi-be-gone-a-simple-mitigation-for-cve-2021-44228/" target="_blank">https://research.nccgroup.com/2021/12/12/log4j-jndi-be-gone-a-simple-mitigation-for-cve-2021-44228/</a> </strong></li> </ul><p><strong></strong></p><p><strong>Cybereason Log4Shell Vaccine Offers Permanent Mitigation Option for Log4j Vulnerabilities (CVE-2021-44228 and CVE-2021-45046)</strong></p><p><strong>Take action now to implement this vaccine and protect your Apache servers from this critical vulnerability. </strong></p><p><strong></strong></p><p>You should still update your Apache systems to permanently remediate the vulnerability, but patching takes time, and some systems may not be able to be updated immediately—or at all. This Vaccine will disable the vulnerability and allow you to remain protected while you assess and update your servers. </p><p></p><p>The latest version is pushed to our github at <a href="https://github.com/Cybereason/Logout4Shell" target="_blank">https://github.com/Cybereason/Logout4Shell</a></p></blockquote><p></p>
[QUOTE="Jonathan Braley, post: 2528, member: 77"] [B]Log4Shell Update[/B] 12-17-2021 Our operations team will continue to monitor the situation over the weekend and will update here as needed. [B]Mitigation Status:[/B] Apache released Log4j version 2.16.0 in a security update to address the CVE-2021-45046 vulnerability. A remote attacker can exploit this second Log4j vulnerability to cause a denial-of-service (DOS) condition in certain non-default configurations. [B]Note[/B]: Affected organizations that have already upgraded to Log4j 2.15.0 will need to upgrade to Log4j 2.16.0 to be protected against both CVE-2021-44228 and CVE-2021-45046. Per reporting today, patch 2.16.0 appears to mitigate known vulnerabilities sufficiently. It is possible more bypasses and vulnerabilities could emerge as security researchers and cybercriminal continue to investigate. We will update as necessary. Patching a plethora of devices one by one may not be feasible, especially after companies spent countless hours already upgrading to 2.15. So using tools to disable JDNI to LDAP so that they cannot be exploited remotely could be a beneficial effort. A combination of both patching and disabling JDNI may be a viable safeguard. We have a resources section listed below. [B]Currently Known Vulnerabilities:[/B] [URL]https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/[/URL] [B]CVE-2021-44228 [Critical][/B]: The original 'Log4Shell' or 'logjam' vulnerability is an untrusted deserialization flaw. Rated critical in severity, this one scores a 10 on the CVSS scale and grants remote code execution (RCE) abilities to unauthenticated attackers, allowing complete system takeover. Reported by Chen Zhaojun of Alibaba Cloud Security Team to Apache on November 24th, CVE-2021-44228 impacts the default configurations of multiple Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and others. Being the most dangerous of them all, this vulnerability lurks in the log4j-core component, limited to 2.x versions: from 2.0-beta9 up to and including 2.14.1. A fix for Log4Shell was rolled out in version 2.15.0 but deemed incomplete (keep reading). -- [B]CVE-2021-45046 [Critical, previously Low][/B]: Rated low in severity, this one is a Denial of Service (DoS) flaw scoring a mere 3.7. The flaw arose as a result of an incomplete fix that went into 2.15.0 for CVE-2021-44228. While the fix applied to 2.15.0 did largely resolve the flaw, that wasn't quite the case for certain non-default configurations. Log4j 2.15.0 makes "a best-effort attempt" to restrict JNDI LDAP lookups to localhost by default. But, attackers who have control over the Thread Context Map (MDC) input data can craft malicious payloads via the JNDI Lookup patterns to cause DoS attacsk. This applies to non-default configurations in which a non-default Pattern Layout using either a Context Lookup, e.g. $${ctx:loginId}, or a Thread Context Map pattern (%X, %mdc, or %MDC). "Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default," states the NVD advisory. For those on 2.12.1 branch, a fix was backported into 2.12.2. -- [B]CVE-2021-4104 [High][/B]: Log4j 1.x and 2.x While previously thought to be safe, Log4Shell found a way to lurk in the older Log4j too. Essentially, non-default configuration of Log4j 1.x instances using the JMSAppender class also become susceptible to the untrusted deserialization flaw. Although a less severe variant of CVE-2021-44228, nonetheless, this CVE impacts all versions of the log4j:log4j and org.apache.log4j:log4j components for which only 1.x releases exist. Because these are end-of-life versions, a fix for 1.x branch does not exist anywhere, and one should upgrade to log4j-core 2.16.0. -- [B]CVE-2021-42550 [Moderate][/B]: This is a vulnerability in the Logback logging framework. A successor to the Log4j 1.x library, Logback claims to pick up "where log4j 1.x leaves off." CVE-2021-4104 was discovered to impact Log4j 1.x as well, and the possibility of potential impact to Logback was assessed. Newer Logback versions, 1.3.0-alpha11 and 1.2.9 addressing this less severe vulnerability have now been released. -- BleepingComputer came across multiple security researchers claiming that it is possible to achieve full-on RCE, even with 2.15.0. "The worst possible scenario resulting from Log4j 2.15.0 is yet to be fully determined, but suffice to say, it doesn't seem like it's just limited to DoS. As the situation continues to evolve, organizations and developers are encouraged to upgrade to version 2.16.0, and to continue to monitor Apache's Log4j advisory page for updates." "The action required by defenders is clear cut in all cases: [B]moving to 2.16.0 where jndi is disabled by default is the safest course of action[/B], and is the approach we're recommending for our customers." [B]Analyst Comments:[/B] It is essential that companies identify and apply security measures to systems accessible over the internet. Protocols used for connectivity to and from internal corporate assets should have as many security controls as possible. Multifactor authentication should be enabled in systems that are accessed remotely - RDP should not be used over the WAN - VPN connections are more secure. After initial access, according to the report from BleepingComputer, Log4j was used to leverage vCenter servers in attacks. VMWare uses a Linux-Based kernel, so it is safe to assume that VMWare is vulnerable to Log4j attacks. Companies may want to identify servers using VMware or 'anything Linux' and apply hardening measures accordingly - whether making adjustments and network isolation/segmentation at Layer 3 of the OSI model or removing access directly at NIC responsible for facilitating host access. [B]Resources: Indicators of Compromise:[/B] [LIST] [*]Apache Log4j RCE Attempt [LIST] [*][URL]https://station.trustar.co/constellation/reports/f1c259c8-e013-4709-88b3-46ff9965b9b3[/URL] [/LIST] [*]Log4Shell Indicators [LIST] [*][URL]https://station.trustar.co/constellation/reports/de9add6c-d4a7-439d-a6ff-5a03ff896d76[/URL] [/LIST] [*]MalwareNinja Log4Shell IoCs [LIST] [*][URL]https://station.trustar.co/constellation/reports/99a112f8-54c1-4fab-8a7a-59ee2e0657c8[/URL] [/LIST] [*]Azure Sentinel Log4Shell IoCs [LIST] [*][URL]https://station.trustar.co/constellation/reports/5bd99330-a2a8-48d9-b8b3-f593a887ba1d[/URL] [/LIST] [*]MalwareBazaar Log4Shell IoCs [LIST] [*][URL]https://station.trustar.co/constellation/reports/1dc094e3-4539-4529-a7c4-607741245cd8[/URL] [/LIST] [*]ThreatFox Log4Shell IoCs [LIST] [*][URL]https://station.trustar.co/constellation/reports/d41b2f8b-f940-4fe5-ae95-1a6bf9d2f5df[/URL] [/LIST] [*]CronUp Log4Shell IoCs [LIST] [*][URL]https://station.trustar.co/constellation/reports/7dde8cef-71ea-475c-8c2c-34dcfc7dd5a4[/URL] [/LIST] [*]RedDrip7 Log4Shell IoCs [LIST] [*][URL]https://station.trustar.co/constellation/reports/19bc5641-49ad-427a-8258-3bb4ac725349[/URL] [/LIST] [*]CrowdSec Log4Shell IoCs [LIST] [*][URL]https://station.trustar.co/constellation/reports/55904e7d-1337-41be-8f92-db2267fc15fa[/URL] [/LIST] [*]Andrew Grealy Log4Shell IoCs [LIST] [*][URL]https://station.trustar.co/constellation/reports/33268837-ccd1-4c90-bc77-2fa160892857[/URL] [/LIST] [*]Log4Shell IoCs 12-14-2021 Pt1 [LIST] [*][URL]https://station.trustar.co/constellation/reports/93c0a479-9e3f-4b3f-b126-156b2b5fe01e[/URL] [/LIST] [*]Log4Shell IoCs 12-14-2021 Pt2 [LIST] [*][URL]https://station.trustar.co/constellation/reports/265ff465-7eb1-410f-ad36-1833fcf16eca[/URL] [/LIST] [*]WatchGuard Threat Lab Log4Shell IoCs 12-17-2021 [LIST] [*][URL]https://station.trustar.co/constellation/reports/9b1a0163-fca6-411e-8d39-cc7e8821a7d8[/URL] [/LIST] [/LIST] [B]Vulnerable product List from NCSC:[/B] [LIST] [*][B][URL]https://github.com/NCSC-NL/log4shell/blob/main/software/README.md[/URL] [/B] [/LIST] [B] Scanning Tools and Resources:[/B] [LIST] [*][URL]https://github.com/NCSC-NL/log4shell/blob/main/scanning/README.md[/URL] [/LIST] [B]NCC Group JNDI Disabling Tool[/B] [LIST] [*][B][URL]https://research.nccgroup.com/2021/12/12/log4j-jndi-be-gone-a-simple-mitigation-for-cve-2021-44228/[/URL] [/B] [/LIST] [B] Cybereason Log4Shell Vaccine Offers Permanent Mitigation Option for Log4j Vulnerabilities (CVE-2021-44228 and CVE-2021-45046) Take action now to implement this vaccine and protect your Apache servers from this critical vulnerability. [/B] You should still update your Apache systems to permanently remediate the vulnerability, but patching takes time, and some systems may not be able to be updated immediately—or at all. This Vaccine will disable the vulnerability and allow you to remain protected while you assess and update your servers. The latest version is pushed to our github at [URL]https://github.com/Cybereason/Logout4Shell[/URL] [/QUOTE]
Name
Verification
Post reply
Forums
Security
Active Exploits Discussion/Recommendations
Log4j Vulnerability Information
Top
Bottom
Home
Forums
Threat Reports
My.CompTIA
Menu