What app developers need to do now to fight Log4j exploits

What app developers need to do now to fight Log4j exploits

Why developers may already be at risk, how to detect and mitigate the Log4j vulnerabilities now, and how to improve code security in the future.

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.

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:

Follow Us

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags softwaredevelopercyber securityApache Log4j

Show Comments