What is Apache Log4j?
You’ve most likely heard of the critical flaw CVE-2021-44228, discovered in the popular Java-based library, Apache Log4j. Nicknamed Log4Shell, it impacts numerous Apache projects, including Druid, Dubbo, Flink, Flume, Hadoop, Kafka, Solr, Spark, and Struts. Unsurprisingly, due to the ubiquity of the program, the entire cybersecurity and tech industry is in overdrive.
Although Log4j is an incredibly useful tool for developers who want to log data for later use, it doesn’t sanitize inputs. This allows malicious actors to include untrusted data in logged messages and call back to a malicious server via JDNI lookup. Et voila, cybercriminals now have the access to mine cryptocurrency (check those bills!), launch DoS/DDoS attacks, or drop dreaded ransomware.
DevOps role in remediation
Are you still hearing Teams notifications while you’re sleeping? It’s like a never-ending barrage of messages asking you to build this, check that, fix world hunger. Where do you start? What’s your responsibility?
If you’re part of a DevOps/DevSecOps team, the lines between who’s responsible for security may seem blurry, if not entirely nonexistent. To put it simply, yes security is a shared responsibility in which developers are focusing on building securely and security teams are focusing on supporting developers by selecting the right tools that automate security and play nice within existing CI/CD pipelines. All this to say, as Log4j dominates every aspect of your life, you need to focus on securing (potentially) vulnerable applications.
Mitigation game plan for developers
“The first challenge is to find out where your code and applications might have the vulnerability,” wrote William Malik, Trend Micro’s VP of Infrastructure, in his latest blog about Log4j. Leverage a tool that can scan for Log4j in your source code libraries and identify down to the line of code where the malicious string is residing.
If you find compromised code, the next step is to verify whether that code was deployed in a production environment. If it has been deployed, Malik suggests the following actions:
- Rebuild the package using the most current version of Log4j (currently 2.17.0). Routinely check the Apache Foundation for the most current update.
- Disable the application, or the server or virtual machine running it, until you can remediate the build.
- Install an IPS rule that will block inputs with the “log4j” string. Security teams should be aware that bad actors are developing ways to obscure that string, such as encoding it in base64 so it passes a text scan, etc—meaning new rules will need to be installed as the situation evolves.
- Disable logging until you can remediate the code. This may mean commenting out the Log4j reference, which can cause the application to lose some functionality – such as you may no longer be able to process messages from one user to another. In the event of this, alert security teams and others of potential delays or disruptions to business workflows.
Right now, you may be occupied by stomping out fires as they appear, but consider collaborating with security teams to build a Software Bill of Materials (SBOM). Similar to an ingredient list in a recipe, a SBOM lists all the components used to construct an application. This will help IT understand any transitive risks from vulnerabilities lower in the stack and development teams can ensure compliance with open source libraries.
Next steps
In a crisis, especially when security and development teams are already stretched thin, having a suite of effective security tools to lean on is essential. You need to minimize the “touchpoints” required to consolidate actionable information. You could use a cloud-native platform with security services leveraging automation and customizable APIs. If that sounds interesting and helpful, you can check out the Trend Micro Cloud One™ – Open Source Code Security by Snyk documentation to learn more about automated open source code scanning.