What can or what must IT security managers do in the coming months to identify and eliminate possible consequences of the Log4j vulnerability? Some things should be on the agenda – in a mix of immediate and long-term measures.
Log4j is and remains a dangerous vulnerability almost three months after its disclosure. And even if no attacks are running yet, IT security officers should assume that the cybercriminals have gained access to IT systems. In order to effectively defend against imminent attacks, it will therefore be necessary in the coming months to immediately localize and close weak points and to monitor one’s own IT and network traffic.
Hackers can remotely execute code using the widely used Log4J login library. The CVE-2021-44228 vulnerability, which was announced on December 9, 2021, is particularly dangerous due to the widespread use of the de facto standard Log4J in a wide variety of web applications. Many companies do not know if and where they have implemented Log4j in their systems. As early as December 2021, Bitdefender Labs noticed specific actions by cybercriminals, for example to install cryptominers via botnets or to launch new ransomware attacks.
Even if the large wave of attacks has apparently not yet materialized, a highly dynamic risk situation can be assumed. Because it is so easy to install remote executable code via Log4j, the danger is imminent. The attackers also use Log4J as a gateway to gain access to the corporate network. It can be assumed that the actual attacks will follow, because hackers initially got a foot in the door of the company network as inconspicuously as possible. Many of the attacks now being prepared that will start in the near future may no longer be detected as a result of an intrusion via Log4j.
Figure 1: By resolving a log variable after a system is triggered, attackers exploit the Log4j logging function to install executable code in the attacked system. In this example, the victim system becomes part of the Muhstik botnet and a cryptominer is installed.
Uncertainty among manufacturers and companies
The Log4j library itself offers a very useful and simple function to log and process requests to systems. That is why it has become the de facto standard. As a versatile, cross-platform framework, it runs on various operating systems such as Windows, Linux, macOS and FreeBSD. Java – and thus Log4J – is used, for example, in webcams, car navigation systems, terminals, DVD players, set-top boxes, medical devices and even in parking meters. However, this creates a problem: Many IT administrators will not know which applications connect their company network to the Internet via Log4j. It is no coincidence that Bitdefender telemetry data, i.e. information from installed Bitdefender systems, shows that many security teams are tackling potential vulnerabilities themselves to see if they are affected.
And you are not alone with this lack of overview. Software providers or open source projects also do not know whether their products or projects contain the vulnerability. Like all companies, they have to get an idea of the security status and are now informing their customers – or will continue to do so in the near future.
Five tips for the “Log4J marathon” of the coming months
In this unclear, constantly changing risk situation, IT security managers in companies and managed security providers must be very vigilant in the coming months in the service of their customers. The following advice will help to identify risks and block attacks in the short and long term:
1. Patch and update immediately where the vulnerability is already known: Companies should immediately apply all patches available for their applications according to the instructions from the software provider. This principle applies now more than ever.
2. Inventory IT infrastructure and software bill of materials: Administrators should audit their entire infrastructure and software. This allows you to identify all systems that have implemented an Apache Lofj2 logging framework. The update to Log4j version 2.17.1 then follows.
3. Check the software supply chain for updates: Once the IT administrators know which systems are affected, they should keep themselves informed whether the respective open source software projects. Do the vendors of commercial software products provide patches. What measures do you recommend to close the gap?
4. Don’t forget systems without direct access to the Internet: Of course, applications and systems that are directly connected to the Internet have top priority in the security inventory. But many hackers only use this entry gate as a starting point for sideways movements to attack other systems. Therefore, those responsible for IT should be just as vigilant in monitoring and protecting systems without a direct connection to the Internet.
5. Time for a layered defense: Exploiting Log4j is the first step – launching an attack is the next. This may give IT administrators time to prepare and prevent a vulnerability from becoming an actual security incident. Telemetry data shows which cyber security modules prevent attackers from exploiting the vulnerability.
It starts with protection at the network level: Threat Intelligence provides information on the reputation of URLs or IP addresses. But the static malware is also doing its bit and has installed cryptominers or known malicious payloads. This not only offers protection against these attacks. Administrators and managed security providers should also assume that these attacks will continue to spread. Extended Detection and Response (XDR) detects sideways movements from one system to the next. Advanced threat detection techniques identify suspicious behavior in processes. External experts from a managed detection and response (MDR) service help to identify risks and attacks.
Defending against attacks via Log4j will be a long-term task. Administrators should monitor access to their network and what is happening on the network very carefully in the coming months. Every anomaly needs to be checked. In particular, IT administrators and managed service providers should take any sign of reverse TCP shell seriously.