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 riskBefore 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 planYour 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 availableSecurity 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.Longer term strategies to improve coding securityFirst, 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:
Copyright © 2021 IDG Communications, Inc.
Source link