The Log4j vulnerabilities represent a complicated and concerning set of issues for organizations and management around the globe. International cyber security watchdogs say that organizations should continue to remain cognizant of risks associated with Log4J attacks, and should stay on high-alert for potential Log4j-based threats. In the eyes of some experts, Log4j is among the most dangerous flaws disclosed in recent years.
Upon its discovery, a Log4j fix was not apparent or available, and the cyber security workforce spent many hours attempting to identify and mitigate the vulnerability. Since then, a patch has been released. However, vulnerability isolation and patching hasn’t necessarily proceeded in the way that experts might have hoped…
Recent Log4j developments
In a recent scan, cyber security researchers discovered that more than 90,000 internet-exposed servers continue to contain vulnerable versions of the software. And this number may represent a mere fraction of the available attacker targets, as researchers only investigated publicly facing servers running on open source software. Once internal network servers and servers running proprietary applications are accounted for, the cumulative number of vulnerable targets could far surpass 90,000.
Limitations of patching
While the obvious Log4j fix does consist of patching, a Google open source scanning service recently revealed that just 7,140 Java packages have been patched since Log4j was disclosed. This number represents only 40% of affected packages, which total 17,840. In other words, many vulnerable Java packages containing the Log4j library remain unpatched.
Adding to the concern around continued possibilities for exploit, researchers note that 36% of Log4j versions downloaded from Maven Central remain vulnerable.
One difficulty is that many organizations lack visibility into their software components, which explains the continued use of vulnerable versions of Log4j. Few organizations maintain detailed configuration management databases that would show precise Log4j usage locations.
Log4j fix information
The continued exploitation of Log4j indicates that organizations aren’t prioritizing vulnerability identification, patching and other protective measures. For some, there may not be a single Log4j fix. However, you’ll find both short and long-term means of improving protection for your organization below.
1. Update Web Application Firewalls (WAFs) and other perimeter security tools. In so doing, organizations can immediately halt inbound and outbound Log4j attacks. However, experts note that hackers will likely attempt to overcome such barriers and that updating these tools likely represents a partial or temporary fix. Try out a breach and attack simulation tool to assess your WAF or NGFW protection against Log4j-related attacks.
2. Monitor your network activity. Are you seeing any unexpected outbound connections? Consider disabling outbound communications from internet-facing devices that are not business critical. In the event that you have a vulnerable system to which someone can pass a malicious JNDI command, but the malware fetch is blocked, you will have some level of protection.
3. Check device update status’. Search through every server, printer and other devices for inbound Transmission Control Protocol (TCP) connections. Contact device vendors to explore updates for Log4j. Java script is commonly in use on network appliances, printers, mobile phones and other types of devices. Experts suggest temporarily doing without use of these types of devices, if possible, until you can access Log4j information from the vendor.
4. Update all servers to Log4j 2.15.0. The importance of updating servers cannot be overstated, as hackers are quick to identify and exploit such vulnerabilities.
Unpatched devices and systems using Log4j represent easy targets for threat actors. To further enhance protections, organizations may also wish to implement multi-factor authentication, zero-trust principles, network segmentation, and endpoint detection systems. Further, reach out to your security vendor for more customized security insights.
In the event that a vulnerable Log4j asset is found, security teams should act on the basis that the system has seen compromise – searching for threats, malicious activity and ways to take action.
For more Log4j and Log4j solutions or Log4j fix information, see CyberTalk.org’s past coverage. Lastly, to receive more cutting-edge cyber security news, best practices and analyses, please sign up for the CyberTalk.org newsletter.