BLOG

How to Mitigate Log4j Today and Stop Future Exploits

Catherine Newcomb
Catherine Newcomb

Navi Gill

Navpreet Gill
Published January 10, 2022


What is the Log4j vulnerability?

It’s been a tough few weeks for many in the IT world. On December 9th, a critical zero-day vulnerability was discovered and announced in the ubiquitous logging library from the Apache Software Foundation used for Java applications known as Log4j. Hundreds of thousands of websites and applications use this software to perform logging for developers to debug their websites and track other trends for their applications and web pages. It has been estimated that the Log4j framework is used in hundreds of thousands of open-source software projects. Developers often build software from these open-source tools without examining the underlying code, which could have existing vulnerabilities.

As a brief recap of the Log4j vulnerability and the kind of exploit it allows attackers to execute:

F5 Labs states: “Log4j has a previously undiscovered security vulnerability where data sent to it through that website — if it contains a special sequence of characters — results in Log4j automatically fetching additional software from an external website and running it. If an attacker exploits this, they can make the server running Log4j run any software they want — including software that can completely take over that server. This is known as a Remote Code Execution (RCE) attack.”

Log4j has high potential for business disruption

Due to the prevalence of Log4j, the initial CVE-2021-44228 (nicknamed Log4Shell) was determined to be a critical vulnerability. The severity of this vulnerability, along with the fact that the patch itself contained a vulnerability and needs to be patched, means that IT professionals may be dealing with the consequences of this vulnerability for a while. This, coupled with the fact that IT personnel need to check for nested references of Log4j—that is, to check if any libraries in use in their software reference the Log4j library—means that Log4Shell may result in a cascading effect. It may be challenging to determine the full scope of impact the Log4j vulnerability and Log4Shell may have on your organization. Get a free threat assessment if you’re concerned your organization may be at risk.

If you haven’t done so already, the first order of business any organization should do to mitigate Log4j is PATCH! Patch servers running Log4j. Patch software using libraries that run Log4j. Just PATCH and keep patching!

As your organization continues the essential and comprehensive process of discovering and patching these vulnerabilities, it is critical to protect yourself from attacks using Log4Shell exploits and prevent damage from propagating further if an attacker has already infiltrated your environment. Additionally, on January 4th, the U.S. Federal Trade Commission issued a notice that organizations failing to remediate Apache’s Log4J vulnerabilities may face legal action stressing the significance of Log4j.

Even if you are fully patched, it’s important to remember that Log4j isn’t the first vulnerability of its kind, and it won’t be the last. That’s why it is essential to proactively protect yourself against current and future vulnerabilities while also having a plan to protect your network if an attacker does take advantage of a vulnerability in your systems. Fortunately, a mitigation strategy is relatively easy to implement.

When it comes to mitigating vulnerabilities like Log4j, make sure you:

  1. Proactively protect your organization from attacks using Log4Shell and other vulnerabilities of its kind by implementing a WAF
  2. Put up safeguards to ensure that if your organization is attacked, you can stop the exploit in its tracks before it does serious damage within your network
  3. Perform an audit to determine the full scope of impact of the vulnerability
  4. Patch all code that is using or referencing the vulnerability, using your audit to ensure no exposure is left unpatched

Mitigating the Log4j vulnerability with signatures blocking known attack vectors

If left unaddressed, cyber adversaries can quickly take over thousands of websites and online apps—allowing them to steal sensitive data. The most effective solution is to patch the app code with the latest version of Log4j and block malicious requests with a web application firewall (WAF).

You may also need to protect your organization from Log4Shell attacks while installing the necessary patches for the Log4j vulnerability on your vulnerable servers and software stack. That’s where a WAF can also help.

F5 WAF solutions—all built atop F5’s consistent, robust WAF engine and available in deployment and consumption models to best address your security needs—help mitigate the impact of the Apache Log4j Remote Code Execution (RCE) vulnerability in your infrastructure. F5 offers four options for protecting your application with our robust WAF engine:

  1. F5 Advanced WAF
  2. NGINX App Protect WAF
  3. Silverline WAF
  4. Volterra WAF

F5 has released a set of signatures that block known attack vectors for Log4j vulnerabilities. Both F5 Advanced WAF and NGINX App Protect WAF can block exploitation attempts using signatures specific to Java Naming and Directory Interface (JNDI) injection and generic JNDI Injection signatures. These signatures are a part of the Server-Side Code injection signature set that is being updated based on continuing investigation of the threat and known WAF bypasses with new rules to detect Log4Shell attacks effectively. In this way, F5 WAF enables “virtual patching.” Visit here for mitigation support for BIG-IP and NGINX Application Security products.

F5 Advanced WAF offers advanced protections well beyond simply defending against the OWASP Top 10 and is perfect for security-focused organizations that wish to self-manage and tailor granular controls for traditional apps. If you are already an F5 BIG-IP customer, you already have the industry’s most powerful WAF—the F5 WAF engine—on your network. Licensing Advanced WAF on BIG-IP, particularly if you are an F5 BEST licensee, can automate mitigation for new and ongoing threats, improve security efficacy for better protection, and unlock machine learning and behavioral analytics for no-touch app protection. 

For a self-managed WAF solution built for your Agile DevOps team and designed to protect your modern infrastructure or a Kubernetes environment, NGINX App Protect WAF will best serve your needs. Visit Mitigating the log4j Vulnerability with NGINX blog for more details on NGINX App Protect WAF.

If you wish to enjoy the same protections as you’d want with Advanced WAF or NGINX App Protect WAF but need or prefer a hands-off approach to help you mitigate exploits right away, a managed service like F5’s cloud-based Silverline WAF may be the perfect fit. Silverline WAF is F5’s premier, fully-managed WAF service, providing a comprehensive solution to protect your applications in a hybrid- or multi-cloud environment, supported by the security experts in F5’s SOC. F5 Silverline SOC team has implemented the necessary mitigations, continuously monitoring threats and applying required mitigations and protections from vulnerabilities such as Log4j.

Our Volterra WAF platform also received updated signatures to further mitigate any exposure related to Log4j vulnerabilities. These signatures are now included in the default WAF policy, and no additional action is required for our Volterra WAF customers to mitigate Log4Shell attacks. Volterra WAF will be the best option for users who are looking for a cloud-native WAF with a SaaS-based deployment.

The F5 WAF offerings and services—F5 Advanced WAF, NGINX App Protect WAF, F5 Silverline WAF, and Volterra WAF—may be consumed and deployed in concert wherever they are needed to best address and protect your applications and defend against application-layer threats.

Additionally, advanced attack campaigns are difficult to detect from singular attacks. F5 Threat Campaigns, available with F5 Advanced WAF and/or NGINX App Protect WAF, defends apps and IT infrastructure from sophisticated attacks by accurately detecting and proactively blocking current attack campaigns. While F5 WAFs on their own serve as an essential security control point, threat intelligence can associate a single attack incident to a more extensive and sophisticated campaign, enabling you to defend against targeted attacks that may evade baseline WAF security policies. Threat Campaigns can be easily added to your Advanced WAF and NGINX App Protect WAF deployment to automate security to detect and block threats.

Establish a defense against Log4Shell attacks in case of compromise

Considering how many libraries use Log4j, it may be challenging to determine the full scope of the impact of the vulnerability for your organization right away. During this time, you may, unfortunately, be vulnerable to exploitation.

For example, an attacker could craft a request to a rogue endpoint to pick up and deploy a piece of malware. Or an attacker could create a request to a server, which leads the compromised server to execute commands from the hacker that are counter to its normal operation and compromise your organization.

Even if an attacker has already exploited the exposure, you’re not yet out of options. Fortunately, once an attacker executes a piece of remote code exploiting Log4Shell, you can stop the exploit from propagating within your network by inspecting outbound server traffic.

Suppose you had a solution at the edge of your network that could decrypt and enable inspection of encrypted traffic packets. In that case, you could catch malware or malicious traffic propagated due to a Log4j vulnerability and block it before it does further damage. An example would be reaching out to a command-and-control server to launch more attacks or even exfiltrate data. Since servers are typically connected to the internet, your server traffic will be traversing your environment over TLS. Therefore, inspecting encrypted server traffic is critical to containing and stopping the spread of an already compromised and vulnerable environment.

Using a product like F5 SSL Orchestrator provides visibility into encrypted traffic and stops encrypted threats by helping perform decrypted outbound analysis. SSL Orchestrator decrypts traffic traversing your network, even server traffic, and sends the traffic to third party inspection services (such as an NGFW, WAF, SWG, IPS, or DLP), which can then allow, block, or bypass traffic to ensure no encrypted malware spreads throughout your network on the way in; and no malicious traffic bound for C2 (command and control) servers or exfiltrated data can make it out of your environment. SSL Orchestrator is designed and purpose-built to enhance SSL/TLS infrastructure, provide security solutions with visibility into SSL/TLS encrypted traffic, and optimize and maximize your existing security investments to protect your network from cascading attacks.

Conclusion

Log4j isn’t the first vulnerability that is both severe and wide-reaching, and it won’t be the last. As important as it is to protect yourself against Log4j exploitations now—which are still ongoing at the time of publication—it is equally critical to strengthen your application and network security to shield your assets from the inevitable next critical vulnerability.

When the next critical vulnerability comes, being prepared means following these four steps. Ideally before a vulnerability is announced, employ a WAF so that your apps are protected from known attack vectors such as Log4Shell. Additionally, and also ideally before a vulnerability is announced, have a solution protecting your network so that if you are attacked during the process of patching and attackers are able to infiltrate your network, you can prevent hackers from using an exploit to control your servers or exfiltrate your data. Then after a vulnerability is announced, the next course of action is to determine your exposure. (F5’s free threat assessment can help!) Next, patch, patch, patch! With these four strategies in place, you will be prepared for the next vulnerability when it comes.

F5 can help you build a comprehensive mitigation plan that prevents attackers from exploiting a vulnerability and protects your environment from additional damage or compromise even after successful exploitation.

If you have any further questions on mitigating the Log4j vulnerability or other similar vulnerabilities, reach out to your F5 sales team or contact us at sales@f5.com. To stay up to date on how F5 responds to Log4j, follow our blog, which is being updated as new information becomes available.

If you are currently under attack and in need of urgent assistance, call our Security Operations Center (SOC) at (866) 329-4253 or +1 (206) 272-7969. For international phone numbers, visit https://www.f5.com/attack. Existing BIG-IP customers can reach out to the Security Incident Response Team.