Log4j : Frenzy , but you want to know what is it all about?
On December 9th, 2021 a new vulnerability was discovered affecting the java logging library, Log4j. Since this news broke out, threat actors around the world have rushed to take advantage of this easy-to-exploit vulnerability and wide-scale attacks are now ongoing. All companies and its engineers, security, support teams are also busy in identifying and fixing this issue. Almost every enterprise company is impacted by it. It has base CVSS score of 10!! .
CVE-2021–44228 is a Remote Code Execution vulnerability in the Apache Log4j library, a Java-based logging tool widely used in applications around the world. This vulnerability allows an attacker who can control log messages to execute arbitrary code loaded from attacker-controlled servers — and I anticipate that most apps using the Log4j library will meet this condition.
This is really good video to understand for those who want to understand what all this is about.
Then there are resources which can used to check your own applications and code. Using tools like synk to look at the code. The presence of JAR files belonging to the log4j library can indicate an application is potentially susceptible to CVE-2021–44228. The specific files to search for should match the following following pattern: “log4j-core-*.jar”. For example, on Windows, if the file is located in C:\Program Files\ApplicationName\log4j-core-version.jar it indicates ApplicationName should be investigated. On Linux, the lsof utility can show which processes currently have the JAR file in use and can be run via the following syntax: “lsof /path/to/log4j-core-version.jar;”
Using tools like Qualys to look at server level. If your organization uses the log4j library, upgrade to log4j-2.1.50.rc2 immediately. You should also be sure that your Java instance is up-to-date. Then looking up vendor documentation for patches or potential fixes. A patch for CVE-2021–44228 has been released, but unfortunately, we’re at the mercy of many of our vendors to push updates that completely patch the vulnerability. The log4j package may be bundled in with software you use provided by any given vendor. In this scenario, unfortunately, the vendors themselves will need to push the security updates downstream. As you assess your own risk and threat model, please consider the components of the software you use and especially what may be publicly accessible.
Resource library: Putting up few resources i came across:
Software list which is affected
What do you do ??
If you are in engineering, support, security i am assuming you are going to have a busy year end depending on how much your organization uses these. You can either patch this for apply a quick fix for mitigation of immediate risk. For patching Apache Log4j2 version 2.15.0 fixes this vulnerability
but Log4j 2.15.0 requires Java 8. Therefore, teams that use Java 7 will need to upgrade Java before upgrading Log4j.
Upgrade takes planning and getting downtimes. So for immediate reduction in risk, you can do it at configuration level possible only for ≥ 2.10 only. You can set the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For lower versions of 2 like 2.0 to 2.10.0, you have to remove the jndi lookup class from the classpath. Even version 1.0 is impacted, but since is out of support, nobody will mention explicit instructions, but you are at risk.
Ciao and good luck everyone, its a race against time !
