On December 10, 2021, a new maximum severity security problem was publicly released to the American National Vulnerability Database (NVD), related to the log4j Java logging library. This problem received a CVSS (Common Vulnerability Scoring System) score of a perfect 10.0 – the highest possible severity score.
This high-severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. This vulnerability allows an attacker to exploit the remote system and the remote code execution if the service log’s incoming data uses Log4j 2 versions 2.0 to 2.14.1.
Book a demo today to see GlobalDots is action.
Optimize cloud costs, control spend, and automate for deeper insights and efficiency.
How to defend from log4j and similar problems
Although log4j has an unusual severity, this is not the first time a vulnerability pops up, and this will not be the last. There are 3 steps an organisation must take to mitigate log4j and similar issues.
1. Know your application stack.
The organisation must be aware of where java, rust or .net are used, at which versions, and with which 3rd party libraries.
2. Create barriers for access and reduce the attack surface.
Place your applications behind managed WAF that do virtual patching as first aid, SASE that scan network patterns, or Zero Trust Access solutions to allow only authorized traffic.
3. Log everything to 3rd party immutable log services.
3rd party logging solutions ensure that you can look for affected apps and bad traffic even during a crisis. In GlobalDots, we especially value logging solutions with a wide, up-to-date integration catalogue and advanced visualization. These help you gain insights from areas of your infrastructure where in-application logs are hard to consume.
GlobalDots partners join the effort
Lacework
Our most recent addition to the Cloud Workload Protection portfolio now offers a free 14-day threat assessment for a faster detection of log4j issues affecting your public cloud environment.
Hystax Acura
Our partner announced as follows regarding the Acura automated cloud migration platform:
Acura doesn’t use Log4j in its own code. However, there is one third-party component that can be impacted there – ELK (Elasticsearch-Logstash-Kibana) stack which serves for logging for remote replication agents, so potentially attackers can use the Logstash vulnerability to perform the attack.
To mitigate this, users should cover the ingress port udp/12201 of Hystax Acura controller (or respective Load Balancer in case of HA deployment) by a whitelist of known source IP ranges where replication agents work.
Hystax Support team will reach out clients for the implementation of an update to their Acura deployments, once the updated version of ELK stack is released.
Cato Networks
Our leading SASE vendor reports that Cato customers have already been informed that if they have the Cato IPS enabled, they are protected. Cato is actively blocking the traffic signature of this vulnerability automatically. No patching or updates to the Cato platform is required.
Authorized partners of Cato Networks can utilize Cato’s rapid response blog post.
Cato security researchers continue to monitor this exploit and have provided interesting and valuable insights that you can read here.
How can GlobalDots protect you from log4j vulnerabilities?
Globaldots is constantly looking into its internal systems to ensure that they are not susceptible to log4j issues. We review all 3rd party technology partners in our portfolio for log4j issues and mitigation steps. If you have a question about log4j issues with a technology implemented by Globaldots, please contact [email protected].
For further information and assistance about how to defend from log4j and similar vulnerabilities, contact us.
