The window of exposure varies. It is often unknown how long the vulnerability has existed and how many systems have been exposed. But perhaps a bigger problem is how long it takes organizations to institute the recommended remedial actions.
What is the Log4j vulnerability?
Take the case of Log4j. It has been a couple of months since the Log4j zero-day vulnerability became public knowledge. Yet cybercriminals are still using it to rampage through enterprise after enterprise. Known as CVE-2021-44228, the Apache Log4j vulnerability exploits Java servers. It has been spreading fast. The sad part of the story is that the hacking world has jumped on it while many IT departments remain oblivious to it. “The Log4j vulnerability is extremely serious, having been given a CVSS of 10.0, the highest possible value,” said Simon Ritter, Deputy CTO at Azul Systems. “Unfortunately, this means it is a vulnerability that can be exploited quite easily and via a remote connection. I’ve seen several ways of using this vulnerability that only require a particular string to be entered in a web form.”
Log4j exploit is a widespread problem
What is so scary about this one is the ubiquitous nature of Java. There are almost 10 million Java developers worldwide, and about 3 billion devices exist that are running Java in some form or another. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) keeps issuing warnings about the Log4j exploit, attempting to raise awareness of the problem. Federal agencies have been ordered to search carefully through their systems for all Java servers and related dependencies and patch them all. Why are government agencies so worried? Log4j makes it possible for remote code execution and access of servers using the Java logging library. Government sources said that more than 100 attempts were being made every minute utilizing the vulnerability at its peak. One estimate from a cybersecurity firm was that the flaw was used in attempts to breach more than 40% of global networks. Yet a couple of months after the publication of this problem, it continues to cause problems. A Chinese gang, for example, continues to use Log4Shell to breach VMware server products. Another group from Iran uses it to distribute a PowerShell toolkit to exploit Java applications. How can this be happening if fixes are available? Log4j is embedded in most Java-based products and web services out there, making it difficult to remediate manually. Hence, hackers continue to use it to deliver crypto-mining malware or steal usernames and passwords to access networks and systems. “Even though the code you’ve written may not make use of Log4J, there is a strong chance other libraries or frameworks you use do,” said Ritter.
Log4j remediation: What’s the vulnerability fix?
For Log4j, CISA ordered all civilian federal agencies to immediately patch this vulnerability and work with multiple cybersecurity companies to shore up breached systems and protect potential targets. It urged enterprises to:
Enumerate any external-facing devices that have Log4j installed. Make sure that your security operations center is actioning every alert on the devices that fall into the category above. Install a web application firewall (WAF) with rules that automatically update so that your SOC can concentrate on fewer alerts.
Similarly, the U.K.’s National Cyber Security Centre (NCSC) issued a Log4j alert. It gave similar advice and stressed patching: “In the case of this vulnerability CVE-2021-44228, the most important aspect is to install the latest updates as soon as practicable.” The vendor community has done its part. IBM, Cisco, VMware, Apache, Google, Microsoft and many others released patches. Unfortunately, some IT departments haven’t yet patched their systems. This leaves hackers with innumerable channels for potential exploitation. And some companies may believe they have patched all their systems, but it is quite likely that one or two systems remain undetected. Additionally, scanners have been issued by CISA and others to hunt down any remaining vulnerable systems. Ritter added that those with applications that use Log4J update to the latest Java library version — and keep all components updated with all available patches.
Zero-day attack prevention: Log4j lessons learned
Log4j is just a recent zero-day attack example. There have been many in the past. Many more will no doubt happen in the future. The key is to be prepared. IT staff need to be on the lookout for zero-day alerts. When one happens, they need to take all recommended remediation actions. Often, these consist of steps to take to lessen the fallout until a patch is released. This could be a few days, yet the actions to take could minimize risk. Typically, these include taking specific systems offline, being extra alert for certain types of traffic, backing up systems, etc. But patches will appear rapidly. Generally, it only takes a couple of days for the vendor to issue a patch. Such high-priority patches must be deployed rapidly and efficiently, ensuring all related systems are fixed. Further, security training should be stepped up addressed to whatever areas showed weakness or lack of awareness during the attack. If the IT department took too long to spot anomalous traffic or delayed deployment of the patch, more training and certification should be urgently required to prevent a recurrence. Similarly, if the zero-day vulnerability resulted in a rash of phishing incidents, security awareness training campaigns should be stepped up.
