Observability can help identify where Log4j is used and minimize any potential impact it may have until the software component is updated.
In what some security experts are claiming is the most serious vulnerability they have seen in their decades-long careers, the newly discovered vulnerability in Apache’s Log4j software library should be yet another reason to adopt observability.
According to the Computer & Infrastructure Security Agency (CISA), “Log4j is very broadly used in a variety of consumer and enterprise services, websites, and applications—as well as in operational technology products—to log security and performance information. An unauthenticated remote actor could exploit this vulnerability to take control of an affected system.”
The problem is that the software has been widely used for years. And it is embedded in many applications. Modern application development techniques based on microservices, APIs, and composable elements mean it is easy to incorporate such software into numerous applications without even knowing by simply re-using components that perform Log4j’s core functions. Low-code/no-code methods allow for even easier use and re-use of components, thus amplifying the problems.
The security implications of such re-use of software, and particularly open source software, were highlighted in a report last year by the Laboratory for Innovation Science at Harvard and The Linux Foundation. The report noted the need for an “understanding and addressing of the security complexities in the modern-day software supply chain where open source is pervasive, but not always understood.” It noted that it is difficult to fully understand the security of open-source software because “by design, it is distributed in nature, so there is no central authority to ensure quality and maintenance,” and it can be freely copied and modified.
See also: Continuous Intelligence Needed to Parry New Cyber Threats
The heart of the problem
CISA and its partners, through the Joint Cyber Defense Collaborative, are responding to active, widespread exploitation of a critical remote code execution (RCE) vulnerability (CVE-2021-44228) in Apache’s Log4j software library, versions 2.0-beta9 to 2.14.1, known as “Log4Shell.” Organizations are urged to upgrade to Log4j 2.17.0 (for Java 8), 2.12.3 (for Java 7) and 2.3.1 (for Java 6), and review and monitor the Apache Log4j Security Vulnerabilities webpage for updates and mitigation guidance.
To recap: Log4Shell, a zero-day vulnerability within Apache Log4j, a popular Java logging library, poses significant threats as it can be exploited for unauthenticated remote code execution. Remote execution code, or RCE, can allow any bad actor behind a computer to run code on a server. If not handled promptly and properly, hundreds of millions of machines will be vulnerable.
The vulnerability can be exploited via Log4j’s Java Naming and Directory Interface (JNDI) lookup feature allowing for remote code execution by an attacker who can manipulate log messages.
The challenge for end-user companies is that they may not know if their applications use the vulnerable versions and where the software is deployed.
Hunting for this activity is greatly benefited by visibility into the web, application, and network traffic. And proactive monitoring is key to immediately identifying and understanding what is happening to stop its impact and isolate it. Such capabilities are core functionality in many observability platforms. Hence, the need for observability to help identify where Log4j is used and minimize any potential impact it may have until the software component is updated.
