Latest Updates on The Log4Shell Exploit

It’s just over one month since the Log4Shell vulnerability rocked the cybersecurity world. The vulnerability—rated at 10 on the 10-point CVSS vulnerability severity scale—provides a potential path into servers or other devices running Java-based applications via a logging tool named Log4j. In this blog, we provide the latest updates on this critical vulnerability, including how the security world is dealing with the fallout and any incidents that have exploited it.

Log4Shell: Statistics and Incidents

Opportunistic threat actors immediately began scouring the Internet in droves for vulnerable internet-facing servers and devices running Log4j. Just five days after Apache disclosed the vulnerability, malicious actors had already attempted to exploit it in over 40% of global networks. Aside from the ubiquity of Java (and Log4j) in enterprise applications across the world, a huge factor in this vulnerability’s severity is how trivial it is to exploit.

Software developers use tools like Log4j to record the activity of an application. Using this log data, developers and IT Ops teams fix bugs, monitor performance and troubleshoot other errors. The Log4Shell vulnerability facilitates remote code execution by allowing attackers to simply send a special string (set of characters) to a Java application, which can lead to full server or device control. At the peak of exploit attempts, one security vendor saw 25,000 sites attacked per hour, indicating a spray and pray approach to find vulnerable servers.

Significant intrusions into networks from Log4Shell haven’t materialized to the degree expected given how quickly hackers began weaponizing the exploit and searching for vulnerable devices. One notable high-profile exception was a cyber attack on The Belgian Ministry of Defense, which led to a partial shutdown of the government department’s IT network. Most exploits so far have been restricted to smaller-scale malicious activity, such as crypto-mining.

A Coordinated Response

Undoubtedly, a big factor behind so few significant security incidents from Log4Shell is the swift and coordinated response from the security community in the wake of its disclosure. Jen Easterly, Director of CISA, said in a January 2022 briefing that the latest update on the Log4Shell vulnerability was a “good news story,” with CISA seeing an “unprecedented level of collaboration among its partners.” Here are two key elements of the cybersecurity community’s response that helped limit the immediate damage from Log4Shell.

Effective Communication

Effective communication from software vendors, security researchers, security vendors and government departments helped businesses quickly grasp the severity of the Log4Shell vulnerability.

Businesses knew fairly quickly that they needed to detect and remediate vulnerable instances of Log4j within their environments. Software vendors worked quickly to update affected software or services and inform end users. Scanners and vulnerable app lists released by CISA helped businesses identify web services and apps exposed to Log4Shell hacks.

Quick Patching

A zero-day vulnerability as serious as Log4Shell quickly descends into a ticking time bomb. Affected businesses were immediately catapulted into a race to apply a security patch for Log4j before hackers could exploit it. Effective communication helped most businesses understand that this vulnerability could not wait for regularly scheduled patches; it needed ad hoc action.

Depending on the version of Java used in an application, swiftly applying relevant patches for that version helped to safeguard many businesses from the potential adverse security incidents that Log4Shell could lead to. The latest secure versions are Log4j 2.17.1 (Java 8), 2.12.4 (Java 7), and 2.3.2 (Java 6). Any outdated Log4j version is highly susceptible to and has probably already been exploited by threat actors. At Nuspire, we immediately initiated emergency patching of any vulnerable systems in our infrastructure.

The Future of Log4Shell Attacks

While the initial damage has been minimal, there are likely to be future waves of Log4Shell attacks. Many organizations large and small may have been hacked before they applied the latest Log4j security patches. If applying the patch was delayed by several days or more following Apache’s disclosure, it’s more prudent to assume compromise than not.

Threat actors who managed to exploit the vulnerability may be silently biding their time and figuring out how to best use the footholds they’ve established into corporate networks. Some threat actors may sell these footholds to ransomware gangs and other cybercrime groups, while others figure out how to best conduct post-exploitation activities, such as privilege escalation or command and control.

The key point here is to not let your guard down just because you’ve managed to apply the relevant security patch. You need to actively search for signs of threat actors having already breached your network and respond appropriately. Help with this can come from managed detection and response services, which we offer at Nuspire.

Conclusion

Industry commentators sometimes denigrate the cybersecurity industry’s reliance on fear, uncertainty and doubt (FUD). In the case of Log4Shell, the simplicity of the exploit and the pervasiveness of the vulnerable tool fully justified communicating the dangers and encouraging quick action. Ongoing defenses, such as detection and response, are critical for identifying signs of post-exploitation activity such as scanning or lateral movement.

Contact Nuspire today to learn more about how we can help your business prepare for and respond to cybersecurity vulnerabilities like Log4Shell.