The Log4j vulnerability, was first detected in December 2021. Log4j is an open-source Java library that is widely used by developers to monitor apps and captures logs. Cybersecurity experts classified it as a critical severity due to its vulnerability to remote code execution (RCE) attacks, local code execution (LCE) attacks, and information leakage. Millions of attack attempts exploiting this vulnerability were reported. Microsoft identified a group of attackers from China that used this weakness as a back door to inflict organizations with Nightsky ransomware. Due to being open-source and easy to use, Log4j is used in a wide range of software, and some organizations were initially unaware of its presence within their software infrastructure. This vulnerability usually comes in via third party software. Organizations commonly don’t monitor the libraries and external components (such as Log4j) used by third party software and thus were uncertain about the extent of cyber risk exposure for their organizations.
In the past 4 months, Apache has released a series of patches to counter this issue. Upgrading to the latest patch 2.17 is the straightforward measure to protect against this software vulnerability. Users without the latest patches are still exposed to getting attacked by cyber criminals. However, even after patching, an organization could have already been compromised by this attack. The good news is that, with Log4j being a logging library, there is a good chance of the attacker having left traces behind in the log. There are other measures that could be taken, such as restricting outgoing internet traffic, but this is rarely a viable and surely not a long-term solution.
Aside of installing patches, an important step is to monitor the activities of your software. Log4j is used only to log activity and events. There should be no further activities such as the Log4j process trying to access other systems. Monitoring changes in behavior of the software using the Log4j library is an option for identifying malicious behavior. For instance, Amazon Web Services (AWS) released patches to track and patch the vulnerable applications. These patches were found vulnerable to be manipulated by existing malicious containers on the system to elevate their privileges and take over the host or execute code remotely. This further emphasizes the need for monitoring after installing patches.
Additionally, Log4j scanners can be implemented to identify systems that are still vulnerable by the Log4j threat. However, it must not be the only solution, as some of these scanners have reported false positive results.
If there are systems which are unpatched, this threat will continue to exist. The solution is to patch and stay alert, but to also have a solid cyber security and cyber resilience plan in place which can identify and stop attacks ideally even before these occur.
European Identity and Cloud (EIC) conference 2022
For a deeper dive into cybersecurity topics and to help your organizations to develop more resilient cybersecurity and identity management architectures, KuppingerCole offers content in a variety of formats, including live events such as the 2022 KuppingerCole European Identity and Cloud (EIC) conference taking place in Berlin and online in May.
The agenda for the conference includes keynote presentations on dynamic authorization on zero trust architecture, promoting cyber resilience through identity and zero trust and many panel discussions and presentations from experts on latest cyber security, identity management and digital transformation topics.
Related research Blog Post: Prepare, Prevent and Protect
Leadership Brief: Responding to Critical Software Vulnerabilities
Leadership Brief: Prepare and Protect against Software Vulnerabilities