Via: Rawpixel

What is the Log4j Vulnerability?

The new Log4j 2 vulnerability CVE-2021-44228, now called Log4Shell, has been one of the biggest cybersecurity vulnerabilities in the past years. Web application development and enterprise app development companies are now concerned as the vulnerability has a 10.0 CVSS score. Log4Shell is a Java logging library used in numerous products and tracked by most organizations. This vulnerability permits a remote code execution and it has had a very serious impact because developers were uninformed that Log4J would be so risky to be used without an appropriate filtered input process.  The execution of an arbitrary code happens when Log4J is used and the attacker causes a string to reach the logger. More simply, the attackers can make any server that is using log4j run any software they desire. 

                      Network penetration testing can certainly assist in mitigating Log4Shell, and security teams in many organizations, such as Microsoft and IBM have now taken steps to fight this threat.

How to Mitigate the Log4Shell Vulnerability

Fortunately, practices to mitigate the threat are easy to implement.

Microsoft provided the following workarounds for companies to consider: 

• In case the Log4j 2 vulnerable component cannot be updated, Log4J 2 versions 2.10 to 2.14.1 support the parameter log4j2.formatMsgNoLookups to be set to ‘true’, to disable the vulnerable feature. Ensure this parameter is configured in the startup scripts of the Java Virtual Machine:
  -Dlog4j2.formatMsgNoLookups=true.
• Alternatively, customers using Log4j 2.10 to 2.14.1 may set the LOG4J_FORMAT_MSG_NO_LOOKUPS=”true” environment variable to force this change.
• Kubernetes administrators may use “kubectl set env” to set the LOG4J_FORMAT_MSG_NO_LOOKUPS=”true” environment variable to apply the mitigation across Kubernetes clusters where the Java applications are running Log4j 2.10 to 2.14.1, effectively reflecting on all pods and containers automatically.
• For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Who are we at MarkiTech.AI?

Markitech.AI is a top AI development company with a mission to innovate healthcare one project at a time for payers, providers, and end-users. 

                     We have completed 40+ HIPAA-compliant projects in healthcare and we are the trusted firm to help all levels of healthcare, whether you are building an application to integrating systems or developing your infrastructure.

              We are experts in AI/ Machine Learning with 35+ engineers, data scientists & health care experts. 

               A collaborative firm dedicated to helping healthcare innovate and develop. 

              We would like to offer FREE digital transformational consultancy via our Fractional CTO team of highly experienced individuals and understand your unique technology challenges and see if there is a potential fit.

Book a free consultation today to see how can help digitally transform your business at https://markitech.ca/our-services/

Credits:

Microsoft, Docker