Earlier this month, security researchers uncovered a series of major vulnerabilities in the Log4j Java software that is used in tens of thousands of web applications. The code is widely used across consumer and enterprise systems, in everything from Minecraft, Steam, and iCloud to Fortinet and Red Hat systems. One analyst estimate millions of endpoints could be at risk.
Log4j is just the latest in a series of software supply chain attacks, including SolarWinds (which had a compromised build process) and Kaseya (where attackers had substituted malware-laced code).
Since the first Log4j vulnerability came to light, security vendors and analysts have published a great deal of information on what to do, ranging all over the map. Some folks have posted near-doomsday scenarios, while others have less dire predictions. Check Point Software Technologies has seen attempted exploits across nearly half of its customer base. Contrast Security has found that 58% of Java applications have vulnerable versions present, but only 37% are actually using Log4j.
The four issues go by CVE-2021-44228, CVE-2021-45046, CVE-2021-4104 and CVE-2021-45105. The US Cybersecurity and Infrastructure Security Agency is maintaining a web page with links to various vendor blogs here, along with a list of affected applications, and is trying to keep both updated with any fixes. The issues involve several features of the logging software, including the Java Naming and Directory Interface (JDNI) and JMSAppender event messages, both of which allow remote code execution. What makes this collection of vulnerabilities dangerous is that attackers don’t need a lot of expertise to gain this remote access. The last vulnerability refers to a denial-of-service condition, keeping everyone on their toes. And most recently, Blumira found a new attack vector that widens the overall surface using WebSockets.
It looks like we haven’t heard the end of Log4j. What is clear is that as an application developer, you have a lot of work to do to find, fix, and prevent log4j issues in the near-term, and a few things to worry about in the longer term.
You may already be at risk
Before you start to lock things down, Ariel Parnes, COO of Mitiga, cautions that “You should see if your organization was already hacked using Log4j sometime in the past. The criminals might be already inside.” IT manager John Cronin posits the key questions: “Do you know which of your servers use Log4j? How long will it take you to produce a list of those servers? Can you patch them on a moment’s notice? Do you have automated tools or does someone need to log into every server and do it manually? Do you have a process to patch live production servers during peak usage time?” Answering those questions will take some effort, to be sure. In a previous post, we walk through what it will take to figure out if you have been infected.
Security analysts have found exploits dating back to December 1, 2021, using a wide range of network protocols including LDAP, RMI, DNS, and HTTP. These exploits have installed a variety of malware, including hidden cryptocurrency miners, a new ransomware family that Bitdefender calls Khonsari, and code to join the Mirai botnet. And to top everything off, several researchers have reported exploits originating from state-sponsored attackers in China, North Korea, Turkey, and Iran.
Your immediate defense plan
Your first line of defense is to upgrade to the most current Log4j versions. Initially, Apache released a patch that turned out to still have vulnerabilities. The most current versions are Log4j v.2.17.0, if you are running Java 8 or later, and Log4j v.2.12.2, if you are running Java 7 across your web app infrastructure. These turn off JNDI by default and remove message lookup access, both of which lie at the heart of the various vulnerabilities. Disabling JNDI could break something in your apps, so test this carefully before you implement in any production systems.
You might also want to stop any Java-based logging if you don’t need it for any of your applications. Again, test before deploying.
And those of you who run your own Minecraft server should check and see if it is running Minecraft v.1.8.8 or later; these versions are vulnerable. Microsoft has released Minecraft v.1.18.1, which fixes the issue. You should upgrade immediately or find another and more trustworthy server that has been fixed.
What detection tools are available
Security vendors have worked overtime to augment their tools, and you should take advantage of various free offers. Below I’ve listed a variety of scanners that can be used to locate the vulnerable code in either running applications or source files. You should determine if that code has been deployed in any production instance.
- Qualys has a 30-day free trial of its web application scanner, along with this explanation on their blog on how to use it.
- Check Point’s CloudGuard AppSec, another scanner, has another free 30-day trial here.
- CERT has a written series of scanners using Windows, Python, and Bash.
- If you are using Burp Suite, IBM’s X-Force has its free scanner and SilentSignal has its plug-in.
- WhiteSource has its free scanner.
- JFrog has its Xray free Python-based scanning tool to examine your own Java code libraries.
- Here is the rule if you are using Semgrep.
- Orca Security has a free online tool that can scan AWS, Azure, and Google Cloud environments, along with a 30-day trial of its platform.
Longer term strategies to improve coding security
First, understand code dependencies. One of the challenges of Log4j is its popularity and inclusion in numerous Java libraries. Once you have rooted out the older versions across your own code, it is time to investigate what else you are running that depends on it. If you use the Apache frameworks Struts2, Flume, Dubbo, Kafka, Solr, Druid, or Fink, you will have to upgrade Log4j libraries inside these projects. If Struts strikes a familiar note, an exploit back in 2017 led to the compromise of Equifax’s databases that leaked private data from more than 140 million customers.
Tanya Janca, of WeHackPurple (an excellent source on app security in general), suggests that you use dependencyGraph, Snyk, or OWASP’s Dependency-Check. Once you find any dependency, comment out the code that calls Log4j if you can’t patch it immediately.
Understand how web application firewalls (WAFs) work. If you don’t have a WAF, now is the time to get one. If any of your code is deployed behind a WAF, turn on their detection rules and check to see if the vendor has updated its rules to cover all of the latest vulnerabilities. But realize that since the flaw was announced, researchers have demonstrated many ways to build nested and obfuscated payloads that would bypass proposed WAF filtering rules. Fastly has put together an extensive explanation on how to test WAF effectiveness.
Take advantage of Log4j vulnerability mitigation and patch tools. A number of companies have already delivered mitigation tools for Log4j:
- Cybereason has put together this code. LunaSec further improved it and hosted it on a live server as a public service.
- The Corretto team from Amazon Web Services developed a Java agent that attempts to patch Log4j. The agent is available on GitHub.
- Contrast Security has SafeLog4j, which both detects and patches, and supposedly works against WAF bypass attacks.
- Cisco is offering a 30-day free trial of its Secure Endpoint. There are other endpoint vendors that have included detection rules, including Microsoft Defender (but for now just Windows versions only).
- If you are using containers, you will need specialty protection products. For example, Red Hat has updated their Advanced Cluster Security for Kubernetes and Palo Alto Networks has updated its Prisma Cloud.