800.584.4279

“Log4j” Zero-Day Vulnerabilities: Suite3 Response

A newly-discovered vulnerability came to prominence the morning of Friday, December 10, 2021. In simple terms, the root cause is a piece of software code that is often included in many commercially available software packages. In more technical terms, this is a RCE (Remote Code Execution) vulnerability that is currently being exploited in the wild, leveraging a commonly used Java-based module used for application activity logging. Upon further investigation of the capabilities of the affected library, a second vulnerability (designated CVE-2021-45056) was discovered on Tuesday, December 14, and then upgraded to a CVSS score of 9.0 on Friday, December 17. Both vulnerabilities utilize the Log4j libraries developed by the Apache Foundation. Because the affected software is quite common and the exploits are very simple to code, they are potentially quite harmful.

Fortunately, maturity of the cybersecurity industry and its partners has seen an incredibly rapid and thorough response to this challenge. There are large nets being cast to achieve detection, many patches or other remediations are already in place as of this writing, and more are continuing to be developed.

To better address the questions and concerns related to these vulnerabilities, we’ve provided the following Q&A.

Q: How bad is the situation?

A: The worst thing about it is that the complexity of the exploit is very low; it’s an easy thing to do, and there are lots of bits of code out there that use the vulnerable code component. It’s sufficiently common and dangerous to come to the attention of most major news sources. There have been multiple reports of successful ransomware attacks due to a Log4j-related exploit.

Q: How do I know if I’m immediately at risk?

A: If you run any software or services that are directly exposed to the internet through or in front of your firewall, you may be immediately affected, especially if that software is known to use Oracle Java or Java components (NOT JavaScript; that’s different). Anything behind your firewall (servers, switches, other applications) may still be technically vulnerable, though an exploit is far less likely. Because so many software examples available have used the vulnerable code, patch availability strongly depends on the vendor. When in doubt, ask them or look it up. There are some great links in the Further Reading section below that contain the Log4j responses from various software vendors.

Q: Are there any patches for these vulnerabilities yet?

A: One of the impressive things about this outbreak from an IT perspective has been how wonderfully quickly vendors have responded to this challenge with patches or workarounds; most software vendors have issued something as of this writing. See the Further Reading section below for a publicly-maintained list of potentially vulnerable applications and the patches for them (if available). The list is indexed for easy review. However, the best way to find out if you’re vulnerable is by contacting the vendor(s) for your Line of Business (LoB) applications and asking them directly, if they’ve not already contacted you.

Some clients have asked if the most recent version of Java will fix this vulnerability; unfortunately, the answer is no. This vulnerability affects an optional, freely downloadable software library built and maintained by the Apache Foundation. There is nothing wrong with the Java Runtime Environment itself.

Q: How do the vulnerabilities work?

A: A vulnerable application would receive a text-based command through a variety of possible channels that would cause the module to stop what it’s doing and, instead, download and execute whatever code the attacker specifies in the injected command. That may sound vague, but because the affected software can be used in a variety of contexts, it’s hard to get more specific in a general briefing. Exploitation of the first vulnerability seems to require that the vulnerable system be directly exposed to the internet. Exploitation of the second vulnerability however may occur through secondary channels, though only if certain configurations or conditions are present.

Q: Are any affected Suite3 products or services installed in my company?

A: As of this writing, no. We’ve done due diligence with all our software authors regarding the states of the products and services we provide to our clients. In one case, a process run by one of our services might have been potentially vulnerable, and we implemented a correction within minutes of its official publication.

Q: Are my backups safe?

A: If they’re done with Suite3’s BRS or NA-BRS solution stack, your backups are absolutely invulnerable to the Log4j vulnerabilities based on research done and information provided by our vendors.

Q: What else is Suite3 doing about this?

A: We are continuing to check and review our clients’ installed software and hardware to make sure no vulnerable code is actively being run. If that possibility exists, we will communicate to our clients where remediation actions might be needed. In some cases, we have automatically patched some of the affected libraries, especially those related to APC PowerChute UPS management software.

Q: What’s the good news?

A: Again, the good news is that the agility and responsiveness of the cybersecurity industry as a whole has been excellent. Everyone from small web application writers to the U.S. Department of Homeland Security have responded and are actively coordinating with each other to arrest the impact of these vulnerabilities and their potential for exploitation. Discovery and detection information, admissions of vulnerability, as well as updates, patches, workarounds, and other remediations have been quickly communicated and freely shared across the industry, allowing IT providers like Suite3 to quickly and accurately assess the safety of our clients and determine next actions.

Further Reading:

CISA’s statement on the scope of the vulnerability: 
https://www.cisa.gov/news/2021/12/11/statement-cisa-director-easterly-log4j-vulnerability 

Security research firm Huntress does a good job of breaking down the technical scope: 
https://www.huntress.com/blog/rapid-response-critical-rce-vulnerability-is-affecting-java 

A global cybersecurity effort to list all safe and vulnerable applications and services in one place: 
https://github.com/NCSC-NL/log4shell/tree/main/software 

Another global effort to centralize and list the official Log4j responses from various vendors:
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Microsoft’s notes on the Log4j impact on its products: 
https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/ 

Updated to include additional information: Friday, December 17, 2021 – 2:30 PM