Credit: Dreamstime
Security researchers uncovered a series of major vulnerabilities in the Log4j Java software that is used in tens of thousands of web applications in December. 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 per cent of Java applications have vulnerable versions present, but only 37 per cent 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, they 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.
Developers may already be at risk
Before developers start to lock things down, Ariel Parnes, COO of Mitiga, cautions that “you should see if your organisation 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 the business has 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.
An immediate defence plan
A developers first line of defence 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 users are running Java 8 or later, and Log4j v.2.12.2, if they are running Java 7 across your web app infrastructure.
These turn off JNDI by default and remove message look-up access, both of which lie at the heart of the various vulnerabilities. Disabling JNDI could break something in apps, so test this carefully before users implement in any production systems.
Users might also want to stop any Java-based logging if they don’t need it for any of their applications. Again, test before deploying.
And those of who run their 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. Developers 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 developers 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. Users 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 users 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 Java code libraries.
- Here is the rule if developers are using Semgrep.
- Orca Security has a free online tool that can scan Amazon Web Services, Microsoft 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 users have rooted out the older versions across their own code, it is time to investigate what else they are running that depends on it.
If developers use the Apache frameworks Struts2, Flume, Dubbo, Kafka, Solr, Druid, or Fink, they 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, ofWeHackPurple (an excellent source on app security in general), suggests that developers use dependencyGraph, Snyk, or OWASP’s Dependency-Check. Once users find any dependency, comment out the code that calls Log4j if they can’t patch it immediately.
Understand how web application firewalls (WAFs) work. If users don’t have a WAF, now is the time to get one. If any of their 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 realise 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 AWS 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 developers are using containers, they 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.
