One of Santa’s (evil) helpers delivered a nasty early Christmas present last month: a zero-day.
The “Log4J” vulnerability was discovered by an Alibaba threat researcher and lies in a widely used open-source library.
Versions 2 to 2.14.1 of the Apache Log4j library are vulnerable to a format string attack allowing an attacker to run arbitrary code on the system running the application.
The reason why this vulnerability is worthy of its critical 10 CVSS3 score is down to two factors: opportunity and impact.
Log4j is one of the most popular Java logging libraries, used in a plethora of enterprise applications, web services and open-source frameworks. Therefore, the number of potential targets a threat actor can exploit is high.
Unfortunately, the vulnerability is also trivial to exploit. An unauthenticated attacker simply needs to input a string containing a malicious Java Naming and Directory Interface (JNDI) reference into a vulnerable application that they know will be evaluated as a command by Log4j.
At its heart, the vulnerability abuses a feature of JNDI that allows Log4j to run remotely hosted Java classes. In the hours following the vulnerability’s disclosure, attackers began abusing this look-up feature, delivering backdoors and crypto-currency miners to vulnerable servers.
What can security teams learn from this threat? Mainly that zero-days do exist, and that they most definitely can and will be exploited to deliver ransomware and other malware to any organization, big or small.
Rather than rely on traditional detection-based technologies to stop ever evolving threats, defenses are needed that are flexible in the sense that they protect without detection. That is, they isolate processes so that even if they turn out to be compromised, they are unable to execute their kill chain.
This is the underlying concept behind the micro-virtualization in Sure Click Enterprise, Wolf Pro Security, and Sure Access Enterprise.
Click here for more Log4J developments.
Jonathan Gohstand, HP director of technical marketing
