Dec 22nd 2022: UPDATES to Log4j, Log4Shell vulnerability details
CISA has just released a new advisory: https://www.cisa.gov/uscert/ncas/alerts/aa21-356a
I cannot remember, in a 25+ year cybersecurity career, having to deal with so many updates to a critical patch as we have with Log4j. Did Code Red, MS Blaster, SQL Slammer, Melissa, and more recently HeartBleed, or Exchange Server 2021, have this many failed attempts at a fix?
History of Fixes (last 10 days)
Shortly after log4j 2.15.0 was released, researchers discovered Denial of Service condition flaws. Subsequent research showed those DOS conditions could in fact be remote code execution flaws (yikes!). This led to the release of 2.16.0 and software developers scrambled to test that release.
On Dec. 22nd, a new DOS condition was identified that led to the release of 2.17.0 for Java 8. Other versions were released for older versions of Java.
3rd party Vendor Exposure?
At this point, 12 days into this Log4j event, if your vendor has not come out with a clear statement that they are NOT at risk to Log4j, you must assume they are exposed and scrambling to patch with the newest release 2.17. Where does this leave your company?
Start considering shutting down these services on potentially exposed applications. Look for indicators of compromise. Review the advice from CISO in their latest advisory (here).
CyberHoot Recommendations:
If your company is exposed to log4j vulnerabilities, you need to consider the fact that your servers might have been compromised already. This CISO advisory has a number of recommendations to follow including searching for indicators of compromise.
CyberHoot is very concerned that hackers may be waiting for the holidays to begin inflicting their ransomware attacks and more, stealing our data and identities while folks are not watching. The time to remediate, patch, and search for indicators of compromise is now. Good luck!
CyberHoot’s Original Post from Dec. 11th
A vulnerability with a severity rating of 10 (highest possible) is being targeted on the Internet. The critical risk is called “Log4Shell” and was found in Apache Log4j (versions 2.0 through 2.14.1), and disclosed on December 9, 2021. Log4j is found within Apache Software Foundation which runs nearly 1/3 of all websites. Log4Shell (CVE-2021-44228) allows remote code execution on vulnerable servers.
CyberHoot’s Vulnerability Alert Management Process (VAMP) evaluated rated this risk as a Severity 0 event and escalated it to our vCISO Clients and MSPs for action. Our own servers are not at risk as we do not use any Log4j Java code anywhere in CyberHoot.
How to Respond:
Companies should verify they are not running any exposed Log4j Java code. Here is a list of impacted 3rd party software for your reference. If you find a server at risk, there are three potential ways to fix it as follows.
Three Potential Solutions
1. Upgrade Log4j: Patching log4j to 2.15.0 and above solves the risk but requires access to the impacted Apache server and a restart of Apache.
2. A configuration Change: In Log4j version (>=2.10) the vulnerability can be mitigated by setting system property log4j2.formatMsgNoLookups to true or by removing the JndiLookup class from the classpath. Additionally, if the server has Java runtimes >= 8u121, then by default, the settings com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase are set to “false”, mitigating this risk.
3. Use a Vaccine to Innoculate your Server: CyberReason, a cybersecurity firm, has published a vaccine that patches/inoculates the impacted server eliminating the potential to exploit this vulnerability.
Closing Thoughts
If your company does not have a Threat Intelligence feed to alert you in near real-time to these critical events, consider subscribing to CyberHoot and we’ll keep you up-to-date. Better yet, hire CyberHoot vCISOs to build your Vulnerability Alert Management Process to execute in these situations.