A critical exploit has been made public regarding Apache’s Log4j service which can be used to execute remote commands without authentication on devices that have JNDI Lookups enabled.

This exploit has been given the term “Log4Shell” and all known systems that use Log4j can be found here with vendor remarks on whether the system is vulnerable and if a patch has been made available. For systems where no patch is yet made available, or the system is deprecated, Winsor has been following Apache’s mitigation of setting a global environment variable of LOG4J_FORMAT_MSG_NO_LOOKUPS to true on Microsoft Windows systems (where applicable) and setting the system properly log4j2.formatMsgNoLookups on appliable Unix systems and appliances, then restarting the responsible systems and services. Older versions of the systems and their mitigations can be found on the Apache website documented above as the first link.

What is Apache Log4J and why is this library is so popular?

 

Apache Log4j is part of the Apache Logging Project. By and large, usage of this library is one of the easiest ways to log errors, and that is why most Java developers use it.

Many large software companies and online services use the Log4j library, including Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla, Twitter, and many more. Because of the library is so popular, some information security researchers expect a significant increase in the attacks on vulnerable servers over the coming days.

And while cyber criminals attempting to leverage Log4j vulnerabilities to install crypto-mining malware might initially appear to be a relatively low-level threat, it’s likely that higher-level, more dangerous cyber attackers will attempt to follow.

In addition, we recommend installing security solutions on your servers — in many cases, this will allow you to detect the launch of malicious code and stop the attack’s development.