Log4j: What Is It?
On December 9, 2021, a critical exploit named “Log4j” was disclosed to the world. This exploit was particularly harrowing due to the fact that the software library which it targeted is so widely utilized. “Log4Shell” (CVE-2021-44228, CVE-2021-45046) is a vulnerability within the log4j java library. It allows hackers the ability to run malicious code (RCE – Remote Code Execution) on the vulnerable server.
As of the date of this blog post, months have gone by, and patches to address the Log4Shell vulnerability have been released. For those unable to patch their servers, mitigations are now available to harden specific applications. What’s next however? Is the next critical vulnerability already making its way into the wild? We can’t know when exactly but we can be certain that it’s a matter of time before another application, networking device, or operating system is compromised. What we can do immediately is protect our existing environments. The following 5 best practices potentially could have protected you from the Log4Shell vulnerability as well as the “next big one” coming in the future.
Implement Outbound Traffic Restrictions
At a basic level, the Log4j vulnerability relies on a mechanism whereby a malicious address is injected into an HTTP header to a target server. The vulnerable server logs the malicious payload, and parses its content. The content instructs the target server application to reach outbound to the malicious address, and to fetch some malicious code. By restricting outbound network traffic at least by port, your applications won’t be able to reach out to random endpoints on the internet over ports 389 for example.
Utilize Geoblocking
Depending on your business, it may be clear that there are only a small number of countries from which you legitimately have customers originate. In this case, it makes sense to block internet traffic from all others. As a specific example, SPK enabled geoblocking for one of our customers who hosted several development and production servers which were internet facing and had port 22/SSH open to “any”. Prior to the blocking, we saw daily occurrences of brute-force attempts into the servers. After the geoblocking, we were able to reduce these attempts by 98%.
Use A Web Content Filter
Many enterprises utilize a web content filter to limit user’s web traffic. For example, perhaps there are policies in place that prevent access to sites that contain inappropriate content. Solutions like these could extend to your server fleet as well. In fact, it may be easier to construct this type of policy, since your servers will likely only reach out to a few discrete websites – Ubuntu package repositories or Microsoft downloads, for example. By implementing a web content filter for your servers, you eliminate one vector by which malicious code can be delivered.
Use A Web Application Firewall
Web content filters inspect outbound HTTP traffic. Web Application Firewalls on the other hand, inspect HTTP traffic inbound to your servers. The User-Agent header is a common mechanism that transports the Log4Shell vulnerability. Barracuda Networks’ Web Application Firewall is an example of a flexible WAF. You could construct a rule that defines valid User-Agent strings accepted by your application, and drop all other traffic that doesn’t match. Web Application Firewalls commonly protect against other malicious content such as SQL injection attacks and DDoS attempts.
For AWS EC2 Workloads, Follow These Additional Log4j Protective Practices
What’s great about running your workloads on EC2, is that AWS provides several additional layers of protection available right at your fingertips. One very powerful service is Secrets Manager. Secrets Manager addresses the issue around storing passwords and credentials in cleartext within your application and configuration files. Additionally, Secrets Manager easily allows the rotation of credentials much more frequently. Since Log4Shell typically harvests compromised servers for information, if you eliminate hard coded passwords and credentials, you reduce the “blast radius” of a compromised server.
AWS GuardDuty is another interesting service available to EC2 workloads. GuardDuty continuously analyzes data from several sources such as CloudTrail, VPC Flow Logs, and Route53 DNS query logs. It applies Machine Learning algorithms to detect threats and trigger actions to downstream systems.
Conclusion
Hindsight is 20/20, and given what we know now about the log4j vulnerability, perhaps customers could have taken some very specific actions to prevent being compromised. For that matter, administrators could easily have upgraded or disabled log4j altogether. But the reality is that this was a newly discovered vector, and this won’t be the last. However, by applying a few best practices to our environments, we can greatly reduce our attack surface and risk against future vulnerabilities.
SPK applies cybersecurity best practices for all our clients, and for all the environments we manage. We also help engineering groups harden their products before release, and we monitor released products for new vulnerabilities. If you need help in any of these areas, please feel free to reach out to us.
