Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

What has the Log4shell vulnerability taught us about application security?

A week ago, we had no idea what Log4shell was. Today, we have the global developer community coming together to keep itself safe from a vulnerability that ranks the highest in terms of risk. We need technical solutions, but what does it mean for the landscape of application security, and what have we learned from this situation?

LOG4J security vulnerability (Log4Shell)

On Nov. 24th 2021 a severe security vulnerability, called “Log4Shell”, has been reported in the JAVA framework “Log4J” 2.x which is widely used for event logging in JAVA applications worldwide. The vulnerability allows cyber-attackers to execute arbitrary code by injecting it into a logging process implemented in Log4J. The “Log4Shell” vulnerability allows complete server takeover by the attackers.

Exploiting and Mitigating CVE-2021-44228: Log4j Remote Code Execution (RCE)

A new critical vulnerability has been found in log4j, a widely-used open-source utility used to generate logs inside java applications. The vulnerability CVE-2021-44228, also known as Log4Shell, permits a Remote Code Execution (RCE) allowing the attackers to execute arbitrary code on the host. The log4j utility is popular and used by a huge number of applications and companies, including the famous game Minecraft. It is also used in various Apache frameworks like Struts2, Kafka, Druid, Flink, and many commercial products.

Understanding the Log4j Log4Shell Vulnerability

A zero-day threat is creating waves through the cybersecurity industry more than any other in years. On Thursday, December 9, security researchers published a proof-of-concept exploit code for CVE-2021-44228, a remote code execution vulnerability in Log4j, a Java logging library used in a significant number of internet applications. In the week since its discovery businesses worldwide are frantically trying to identify and mitigate the exploit, while security pros and experts are desperately attempting to release patches and guide organizations as new information becomes known.

Security in context: When is a CVE not a CVE?

At Snyk we have some general points of principle that we use to help guide our security thinking and decision making. Firstly, it is always important to understand from whom we are protecting, as it has implications for how we need to act. As an example of this, if our artefact is a web server, then we need to protect it against untrusted users. Whilst if our artefact is encryption software, then we clearly need to protect it even from users with physical access to the system.

Log4j Vulnerability CVE-2021-45046 Explained

As security and development teams rushed to assess the now-notorious Log4Shell vulnerability published December 10 (CVE-2021-44228), another, more minor vulnerability was discovered in Log4j — CVE-2021-45046. To understand the newly-discovered vulnerability, it is important to get the full picture and background on the original Log4j issue.