What the Log4j Vulnerability Means for Businesses
Most businesses using Apache’s open-source Log4j logging framework should already know about the vulnerability in the system. 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 what organizations need to do to 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, so users and projects using Log4j1.x versions have not been affected.
This vulnerability is dangerous because it allows logged messages to have format strings that refer to information through 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 the 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’s server responds by referencing the URL http://[server address]/data, JNDI will request the file 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 to 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 extensively 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 lot of important information that hackers can use to their advantage. These include:
Since the Log4j vulnerability is so easy to exploit, as of December 2021 we have already seen a number of reports of threat actors exploiting the Log4j vulnerability. Although Apache has already released a patch for this security gap, we will still probably see an uptick of Log4j attacks on supply chains in the next few weeks or so. Any project or project dependency that uses Log4j is 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 to see if a cybersecurity team is using a buggy version of Log4j is not enough — companies need to employ several strategies to defend themselves and their supply chains from 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 from Log4j-related attacks, organizations need to prioritize fixing the Log4j vulnerability, download Apache’s new security patch, and most importantly, implement an all-in-one IT solution like Kiuwan’s Code Security (SAST) and Insights Open Source (SCA). Here’s why:
Prioritize fixing the Log4j vulnerability
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 until later. 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:
CVSS score
Whether there is a fix for the vulnerability
Social trends
The vulnerability’s current status (i.e., how are threat actors reacting to it and taking advantage of it?)
Using this evaluation method, organizations and their IT teams will conclude that Log4j is one of the most important security gaps that need to be addressed in December 2021 and January 2022.
Download Apache’s new security patch
After prioritizing the Log4j threat, organizations need to download Apache’s latest security patch for Log4j.
Apache has recently 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 that users can only access JNDI once 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 newest security patch, companies and their IT teams should also implement an all-in-one IT solution that will help them manage open source risks. Since Apache’s patch doesn’t account for other vulnerabilities, teams need to get software that will help them locate, identify, mitigate, and eliminate vulnerabilities. In particular, they should look into getting an all-in-one cybersecurity solution like 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 comply with security standards like SANS, OWASP, PCI, CERT, and CWE.
Organizations should also consider implementing the following to make the most out of their cybersecurity solution:
A zero trust culture where users are only granted access to resources when they absolutely need it
A DevOps, DecSecOps, 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 which 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 fully secure applications 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 are compliant with stringent security standards like 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, sign up for a demo today. Our expert team will walk you through SAST and SCA and answer questions about their functionalities, features, and pricing.
