Most businesses using Apache’s open-source Log4j logging framework should already be aware of the vulnerability. Known as Log4Shell or CVE-2021-44228, this vulnerability requires urgent action. Left unaddressed, Log4j will allow cybercriminals to execute code to encrypt and delete files and hold data for ransom. Read on to learn more about the Log4j vulnerability and how organizations can protect themselves from it.
The Log4j vulnerability is a security gap found in Apache’s open-source Log4j logging library. Also known as Log4Shell, Log4j is a critical security vulnerability with the highest possible Common Vulnerability Scoring System (CVSS) score of 10. It only affects Log4j 2.x versions; users and projects using Log4j 1.x have not been affected.
This vulnerability is dangerous because it allows logged messages to contain format strings that reference information via the Java Naming and Directory Interface (JNDI). As a result, information can be remotely retrieved through a range of protocols, such as the Lightweight Directory Access Protocol (LDAP). For instance, Log4j will tell JNDI to ask the LDAP server for the “data” object if it spots this string in a log message: ${jndi:ldap://[server address]/data}
In other words, JNDI will always execute an LDAP server’s Java classes. So if the LDAP server responds with the URL http://[server address]/data, JNDI will request the data class. This is where the vulnerability comes in. Because log messages often contain sensitive data such as passwords and usernames, threat actors can insert JNDI references and third-party code into LDAP servers they control. They can then instruct malicious Java classes to steal, delete, and encrypt information as needed.
The Log4j vulnerability will have many implications for many vendors, projects, and companies. This is because the Log4j library is widely used. Log4j is widely used across open-source projects, foundation projects, frameworks, and vendors. It’s also used by Apache Software Foundation’s projects, including Apache Swift, Apache Kafka, and Apache Druid, and by popular vendors such as AWS CloudHSM, Cisco, and VMware.
Logging is a common practice. Log4j is an essential part of software development. Programmers use it to take notes about what is happening on servers and applications. As a result, Log4j contains a wealth of important information that hackers can exploit. These include:
Since the Log4j vulnerability is so easy to exploit, as of December 2021 we have already seen numerous reports of threat actors exploiting it. Although Apache has already released a patch for this security gap, we will likely still see an uptick in Log4j attacks targeting supply chains in the next few weeks. Any project or its dependencies that use Log4j are vulnerable to Log4j attacks.
As a result, organizations may be susceptible to a Log4Shell attack even if they are not using Log4j themselves. As long as one of their project’s dependencies uses Log4j, there is a chance they may be attacked. Since there isn’t a straightforward way to determine if a company is vulnerable to Log4j, supply chains will take some time to adequately defend themselves from this vulnerability.
Checking whether a cybersecurity team is using a buggy version of Log4j is not enough—companies need to employ multiple strategies to defend themselves and their supply chains against Log4Shell. This includes using tools like Kiuwan’s Code Security (SAST) to look through their dependencies and pinpoint supply chain security risks.
To defend themselves against Log4j-related attacks, organizations need to prioritize fixing the Log4j vulnerability, download Apache’s latest security patch, and, most importantly, implement an all-in-one IT solution such as Kiuwan’s Code Security (SAST) and Insights Open Source (SCA).
Every company already has a ton of security issues to address. However, that does not mean it’s safe to put off addressing and fixing the Log4j vulnerability. If a cybersecurity team does that, they will expose their organization to even more risk.
As a result, organizations and their IT teams need to prioritize fixing the Log4j vulnerability. They can do this by evaluating all of their vulnerabilities using a range of factors, including:
Using this evaluation method, organizations and their IT teams will conclude that Log4j is one of the most important security gaps to address in December 2021 and January 2022.
After prioritizing the Log4j threat, organizations need to download Apache’s latest Log4j security patch.
Apache released a patch to address the vulnerability for Log4j 2.12.2 (for Java 7) and Log4j 2.16.0 (for Java 8). In both versions, the patch disables access to JNDI by default. This means users can access JNDI only after it has been explicitly enabled. The patch has also removed the message lookups feature, although lookups in configuration still work. This update will make it more difficult for hackers to gain access to log files, but it doesn’t eliminate the risk entirely.
After downloading Apache’s latest security patch, companies and their IT teams should also implement an all-in-one IT solution to help them manage open-source risks. Since Apache’s patch doesn’t address other vulnerabilities, teams need software that helps them locate, identify, mitigate, and eliminate vulnerabilities. In particular, they should consider adopting an all-in-one cybersecurity solution, such as Kiuwan’s Code Security (SAST) and Insights Open Source (SCA). These powerful tools can scan an organization’s code, identify and remediate vulnerabilities, reduce risks from third-party components, and ensure compliance with security standards such as SANS, OWASP, PCI, CERT, and CWE.
A zero-trust culture where users are only granted access to resources when they need them
A DevOps, DevSecOps, or CI/CD approach to code security for automating security processes and development operations
The Kiuwan development team is actively working to deploy a REST API endpoint that will enable teams to search for components and application versions exposed to the Log4j vulnerability. With our team constantly working to secure your apps against the latest vulnerabilities and countless other security risks, organizations should consider using Kiuwan’s Code Security (SAST) and Insights Open Source (SCA) to ensure applications are fully secure throughout the development cycle.
These tools are full-suite, enterprise-grade security solutions that identify and remediate vulnerabilities in an IT environment. Sleek, powerful, and intuitive, they integrate right into DevOps environments to perform the following tasks and more:
Both products are aligned with the NIST database and compliant with stringent security standards such as SANS, CWE, PCI, OWASP, and CERT. As a result, organizations and their IT teams won’t have to worry about whether their applications comply with relevant laws. The software automatically does all the checking for them.
If you’re interested in experiencing the Kiuwan difference, request a demo today. Our expert team will walk you through SAST and SCA and answer questions about their functionality, features, and pricing.
