What is Log4Shell?
On December 10, 2021, a vulnerability known as Log4Shell (CVE-2021-44228) was disclosed, related to a popular Java logging library (log4j). Log4Shell gained a lot of attention due to how simple it is to exploit, how pervasive Log4j is, and the potential level of access it can provide. Within a few days of being released, many companies discovered vulnerabilities in their services and rushed to patch the log4j library. Exploitation can be achieved by simply tricking a server into logging the following text snippet:
This text snippet can be submitted as a text field, added to a HTTP request, or through any other method that may get logged by a hosting server using a vulnerable Log4j version. Once the payload is logged, the server will make a request to the attacking machine via the Java Naming and Directory Interface (JNDI) where a malicious payload can be staged/injected into the server process. This exploit is quite simple relative to other previous attacks and can easily lead to Remote Code Execution (RCE), therefore development and security teams around the world are scrambling to identify and patch affected systems. For information mitigating issues with log4j please refer to Log4J “Log4Shell” Zero-Day Vulnerability: Impact and Fixes.
Applications written in Java are not the only products at risk when considering the impact of Log4Shell. Any application/service that relies on a framework or product should consider the risk of such dependencies. There are a variety of ongoing lists that detail affected products including but certainly not limited to Elasticsearch, Hadoop and Kafka while products such as Dropwizard, Spring Framework and Tomcat can be vulnerable as well, given a particular configuration.
Right now, hundreds of volunteers are feverishly working on compiling lists of affected products/software. We are lucky to see such goodwill from so many trying to help the community, but this won’t account for every product/software packaged used by every company. Unfortunately, there will be gaps.
SBOM to the rescue
Software Bill of Materials (SBOM) as defined by NTIA is a “nested inventory for software.” Historically, SBOMs have materialized in the form of a monolithic spreadsheet created in the earliest stages of a product and never to be touched again. With the emergence of Continuous Integration/Continuous Delivery (CI/CD) practices, this legacy approach to SBOM does not have to be the case. There are a variety of tools, both licensed and open-source, such as OWASP Dependency Track that streamline the process for conducting an inventory of software and corresponding versions that are in use by your applications. While few of these SBOM tools fit all the needs of many organizations, they are rapidly evolving to be more complete solutions. In addition to identifying software components and versions, most SBOM tools will cross-reference components with known vulnerability databases such as the National Vulnerability Database (NVD) or SonaType OSS Index. This allows an organization to use the SBOM tool to review all their indexed software for newly disclosed vulnerabilities.
While this situation continues to evolve, there are some things we know for sure: actively maintaining a list of software components and versions that an application requires is imperative to rapidly respond to threats as they are discovered in the future – application asset inventory. Equipping development and security teams with the information necessary to track down affected software/systems more effectively can shorten the time frame of being unsure/vulnerable, quicker patches to products/services, and a more secure internet overall. Furthermore, SBOM frameworks are often designed to cater to CI/CD pipelines by providing a mechanism for updating the dependencies during the build process and later using the results to implement security gates to prevent vulnerabilities from being deployed to production.
The Executive Order on Improving the Nation’s Cybersecurity (May 2021) also highlighted the importance of SBOMs to enhance software security. Section 4 specifies how an SBOM will be used and alluded to further requirements around minimum elements for an SBOM. This emphasis on SBOM can directly affect companies today while also providing insight into best practices and potential future regulations in this space. Check out the replay of this recent Protiviti webinar, Securing the IoT Wild, Wild West, to learn more.
How Protiviti can help
Keeping track of all the software, build process, third-party dependencies, and security testing results is a daunting task for any IT/security team. Protiviti offers a variety of services that aid in assessing the state of these considerations including:
- SBOM
- Point-in-time assessment
- Implementation/integration into CI/CD
- DevSecOps
- Current state evaluation
- Implementation
- Security testing
- Web applications
- Mobile applications
- APIs
- Thick client applications
- Embedded firmware
Log4Shell is only the latest unfortunate instance of a cybersecurity vulnerability that needs to be addressed rapidly. There are certainly going to be vulnerabilities in the future that will require similar attention. When that time comes, rely on an up-to-date SBOM to respond to the threat effectively.
Readers may also be interested in our blog, Log4Shell Frequently Asked Questions.
To learn more about our emerging technology and cybersecurity consulting services, contact us.
