The last week has been a wild ride for just about everyone in the technology world due to the public disclosure of the Log4Shell vulnerability. As a developer security company, Snyk has built our business around proactive automation to identify and fix security issues in applications. To say we’ve been busy this week would be an understatement.
The notorious Log4Shell vulnerability CVE-2021-45046, has put Log4j in the spotlight, and grabbed the entire Java community’s attention over the last couple of weeks. Maintainers of Java projects that use Log4j have most probably addressed the issue. Meanwhile, non-java developers are enjoying relative peace of mind, knowing that they are unaffected by one of the major vulnerabilities found in recent years. Unfortunately, this is an incorrect assumption.
If you have access to the internet, it’s likely that you have already heard of the critical vulnerability in the Log4j library. A zero-day vulnerability in the Java library Log4j, with the assigned CVE code of CVE-2021-44228, has been disclosed by Chen Zhaojun, a security researcher in the Alibaba Cloud Security team. It’s got people worried—and with good reason.
Most enterprises, as well as small organizations globally are now painfully familiar with the Log4j2 vulnerability (CVE-2021-44228). It has taken over the lives of all cybersecurity professionals and it appears it is here to stay for a while. Most enterprises are scrambling for solutions, applying patches if they can find the vulnerability, and trying to implement mitigation strategies. But unfortunately what security teams are doing to tackle the Log4j beast is not always enough.
It’s not just about the big name companies who are vulnerable to the Apache Log4j2 vulnerability (CVE-2021-44228). Tech small businesses – which offer customers digital products but which often have tight budgets and understaffed security teams – are an important story when it comes to the implications for Log4j exploits. Research now finds that almost all environments have vulnerable Log4j libraries.
At many organizations, the surprise discovery that the widely used Apache log4j open source software has harbored a longtime critical vulnerability was as if Scrooge and the Grinch had teamed up for the biggest holiday heist of all. Incident response teams across the globe have scrambled to remediate thousands, if not millions of applications. “For cybercriminals this is Christmas come early,” explained Theresa Payton, former White House CIO and current CEO of Fortalice Solutions.
The recently discovered Log4j vulnerability has serious potential to expose organizations across the globe to a new wave of cybersecurity risks as threat actors look to exploit this latest vulnerability to execute their malicious payloads using remote code execution (RCE). An immediate challenge that every organization faces is simply trying to understand exactly where you have applications that are using this very popular Java library — but you are not facing this challenge alone.
Ever since the public exploit of the Log4Shell remote code execution (RCE) vulnerability became known on December 10, 2021, security teams have been scrambling to understand the risk to their environments. Part of that scramble has been to ascertain which tools are best positioned to help detect the vulnerability. Which approaches are most effective and where do they fall short?
The world of cybersecurity has been constantly challenged since the pandemic started. With the dust still settling, a new concern has taken the entire cyber landscape by storm. A flaw in Log4j, a widely used Java-based logging library, allows hackers unbridled access to computer systems. The vulnerability (CVE-2021-44228) affects everything from the cloud to security devices. Attackers have come up with worms that can spread independently from one vulnerable system to another.
