A Java-specific issue
Why Log4j is difficult to remediate
Log4j exploits rely on interactions between the Java Class Libraries, the ClassLoader, and the JVM. Without existing in the runtime, security platforms have issues detecting & preventing these exploits as they move throughout these complex systems.
Like all Java applications, Log4j is compiled into bytecode before it's executed. That said, signature-based security solutions can still theoretically detect and prevent Log4j vulnerabilities at the bytecode level.
The nuance is in the fact that the code executed by Log4j is often generated dynamically at runtime based on input received or files being processed. This means that code executed by Log4j is not static, and can vary depending on the specific input or files being processed.
As a result, signature-based security solutions that rely on a database of known signatures or patterns of malicious code may not be able to effectively detect and prevent all possible variations of the vulnerability. This is because the code executed by Log4j is often unique and not included in the security solutions’ database of known signatures.
“The Log4j vulnerability is the most serious vulnerability that I've seen in my decades-long career. This is not something that will be patched and finished. This is something that we are likely going to be working on for months, if not years, given the ubiquity of the software and ease of exploitation.”
2,500 apps with Log4j vulnerabilities fully remediated in under 4 hours
When a long-term Waratek customer expressed Log4j vulnerability concerns, estimates to resolve the issues were in the hundreds of hours. Fast-forward 4 hours, and 2,500 of their applications were fully remediated of Log4j vulnerabilities without code changes or application redeployments.
This is possible due to Waratek's Java Security Platform which is purpose-built for Java to protect applications and APIs against generic and JVM-specific attacks. This unique domain-specific approach to Application Security provides turnkey Log4j remediation that combines the expertise of an accomplished Java software engineer and the knowledge of a seasoned security engineer.
Zero
Code changes or reboots
Protection is applied in the runtime, fixing bytecode as it's executed.
2,500 apps
From a single organization fully remediated of all Log4j issues
Waratek's Java Security Platform is the only enterprise-ready security solution that deploys at scale in minutes with no tuning for out-of-the-box impact.
4 hours
Time-to-Remediation
Waratek's Java Security Platform rules are extremely precise, enabling organizations the flexibility to protect their unique business logic.
Still running vulnerable Log4j in production?
Waratek's Java Security Platform remediates Log4j exploits at the runtime layer — no code changes, no redeploys, no downtime.
See Waratek's runtime protection →More information
What is CVE-2021-44228?
CVE-2021-44228, also known as Log4Shell, is a critical vulnerability in the popular Java logging library Apache Log4j version 2.0-beta9 to 2.14.1. The vulnerability is caused by the way Log4j processes input containing a specific JNDI (Java Naming and Directory Interface) expression.
Attackers can exploit this vulnerability by sending a crafted log message containing the malicious JNDI expression to a system using a vulnerable Log4j version. This allows the attacker to execute arbitrary code on the target system, potentially leading to unauthorized access, data breaches, and other security risks.
The vulnerability has a CVSS (Common Vulnerability Scoring System) score of 10.0, the highest possible, indicating its severe impact. It is essential to update the affected software to Log4j version 2.15.0 or later or apply the recommended mitigations to protect your systems and data.
Can this tool detect other Log4j-related vulnerabilities?
This tool is specifically designed to detect the CVE-2021-44228 vulnerability in Log4j. While it may provide some insight into potential issues related to this particular vulnerability, it is not intended to detect all possible Log4j-related vulnerabilities. It is essential to conduct thorough security assessments and follow best practices to ensure the overall security of your systems and applications.
How does this tool work?
This Log4j Scanner tool helps you identify if your system is vulnerable to the Log4j vulnerability (CVE-2021-44228) by simulating the exploit without causing any harm. Here's a simplified explanation of how the tool works:
- The tool generates a unique ID for your test and provides you with a specially crafted text, which is a JNDI expression that triggers the vulnerability.
- You copy and paste this text into places where you suspect it might be processed by the vulnerable Log4j library, such as search boxes, form fields, or HTTP headers in your applications.
- If your system is using a vulnerable Log4j version, it will perform a DNS lookup to the domain specified in the crafted text. This indicates that your system is susceptible to information leakage.
- Next, the vulnerable system will attempt an LDAP search request to the specified address. If this happens, the tool responds with a Java class description and a URL for obtaining it.
- In the final step, the vulnerable Log4j library may attempt to fetch the Java class file from the provided URL. Instead of providing the actual payload, the tool returns a 404 error, concluding the test without causing any harm.
By monitoring these interactions, the tool can identify whether your system is vulnerable to the Log4j exploit. Keep in mind that this is a rough assessment, and it is essential to apply patches and follow recommended mitigations to ensure your systems are secure.
How does this tool ensure that it doesn't cause any harm to my system during testing?
Our Log4j scanner is designed to be non-invasive and safe for testing purposes. It performs the exploit steps up to the point where your system requests the remote code execution (RCE) payload but stops there, returning a 404 error and concluding the test. This approach ensures that no harmful code is executed on your system while still providing valuable insight into potential vulnerabilities.
How can I remediate the Log4j vulnerability?
To remediate the Log4j vulnerability, you should update the affected software to a version with the security patch or apply the recommended mitigations provided by Apache and other vendors. These may include disabling JNDI lookups, setting the log4j2.formatMsgNoLookups system property to "true," or using alternative logging libraries. Always consult the official documentation and guidelines of the affected software for the most appropriate remediation steps.
What are the potential consequences of not addressing the Log4j vulnerability?
If the Log4j vulnerability is left unaddressed, attackers could exploit it to execute remote code on your system, which could lead to unauthorized access, data breaches, malware infections, and other potential risks. This vulnerability has a significant impact on organizations across various industries, so it is crucial to take appropriate measures to protect your systems and data.
Is releasing this tool to the public dangerous?
Releasing this Log4j Scanner tool to the public is not inherently dangerous because it aims to help users identify their systems' vulnerabilities and take necessary actions to patch them. The tool does not execute any harmful code or exploit the vulnerability for malicious purposes. While bad actors might already have access to more advanced tools, providing this scanner to the public levels the playing field, allowing anyone to assess their vulnerability to the Log4j exploit. The goal is to promote awareness and encourage users to apply patches and secure their systems.
How does this tool handle privacy?
The tool prioritizes privacy by retaining test results of the servers that interact with it for a limited time. All test data and associated information are automatically and permanently deleted after 24 hours. The tool does not share any information with third parties and your email is only used to verify that you're not a bad actor. To ensure the privacy of your test results, it is important not to share your unique test ID with anyone else. This way, you can confidently use the tool without compromising the security of your systems or revealing sensitive information.