The security vulnerability known as Log4Shell sent shockwaves through the global cybersecurity community in late 2021.
Discovered and first reported by a Chinese security researcher working for Alibaba Cloud, the Log4Shell exploit was described as the ‘most serious vulnerability ever’ by the Cybersecurity and Infrastructure Security Agency's leadership and a ‘mega-vulnerability’ by Risk Based Security. It was even assigned a severity rating of 10 by Apache, the highest rating available in its scoring of critical vulnerabilities.
Essentially, Log4Shell takes advantage of a contextual logging and message substitution feature that is present in the Java Naming and Directory Interface, or JNDI, of the Log4j logging tool. Attackers can submit a specially-crafted network lookup request that causes the system to execute code that it (the system) assumes has originated from a trustworthy source.
Once the request input is executed using the ${} syntax, the attacker gains full remote control over the entire system where it can steal data, trigger ransomware, or conduct espionage.
While security teams rushed to disseminate patches to correct this flaw, the fallout is still being felt across the industry: thousands of the most popular apps have been put at risk since the vulnerability in question affects a logging library – Apache Log4 — that is widely present in enterprise web applications.
And recent studies show that hundreds of companies may still be vulnerable despite patches being available: a scan conducted in March 2022 revealed that 30% of applications contained instances of Log4j vulnerabilities, more than 80% of which were open source. A Joint Cybersecurity Advisory issued in June 2022 from CISA and U.S. Coast Guard Cyber confirmed the presence of continued Log4Shell exploits in unpatched VMWare Horizon systems.
“Our research shows that, even after four months, most of the libraries remain unpatched,” said Muhammad Akhtar, a researcher at the University of California, Berkeley, in May 2022. “Developers need better visibility tools that provide software bills of material to better understand the supply chain and identify indirect dependencies in their application.”
With roughly 3 billion devices that run Java and use the Log4j logging library, experts that spoke to SC Media have estimated it could take months, and even years, to pinpoint and address all new instances of the vulnerability.
"This is now a permanent part of the landscape," said Chris Wysopal, co-founder and chief technology officer of Veracode.
Security concerns highlighted by Log4Shell
As Log4Shell penetrated the security atmosphere, many questions about the exploit began to develop:
- How could a vulnerability of this magnitude happen in the first place?
- Where were the safeguards that could have detected and resolved the issue before it became a fixed feature in the Apache Log4 library?
- How many similar critical vulnerabilities might be out there, just waiting to be exploited by a sophisticated attacker?
The growing consensus is that Log4Shell was a product of faulty application security, specifically tracing back to weaknesses in the software supply chain. Indeed, the Log4Shell exploit illustrates the importance of security across the software lifecycle.
Log4Shell: Lessons learned
Thanks to a wealth of recent literature around effective AppSec best practices, there are clear lessons to be learned from the failure of Log4Shell related to secure design, organizational culture, threat visibility, and continuous integration:
#1: It all starts with secure design principles
Shift-left security is good and right, but Log4Shell demonstrated that more security attention is needed even prior to introducing code in the pipeline. The nonprofit Open Web Application Security Project, or OWASP, calls for the developer community to focus on addressing pre-code activities that are arguably just as critical for ensuring its concept of secure design. Secure design is a methodology that aims to “constantly evaluate threats and ensure that code is robustly designed and tested to prevent known attack methods.”
Organizations can put secure design into practice by first identifying the business requirements for an application — questions around confidentiality, availability, privacy, and technical specs – based on the goals that app is intended to achieve. Once requirements and goals are identified, organizations can integrate the right threat modeling to analyze assumptions and conditions, hypothesize flow and fail states, and determine possible validations. This sort of pre-code scrutiny could have eliminated the Log4Shell vulnerability by giving developers a chance to spot the conditions under which it could be exploited. Organizations should not only identify and vet pre-code requirements, but also document everything they see and, when possible, only pull from secure design-approved libraries.
#2: Put developers and security on the same page
AppSec can’t be the responsibility of security teams alone. Log4Shell is a prime example of what happens when development is divorced from security: developers work against deadlines to get out a new feature, and — fingers crossed – hope that it passes final inspection of the security gatekeepers. This approach is outdated and demonstrably broken. Instead, security and development personnel need to be on the same page, operating from the same playbook, fully aware of the same threats, and responding collectively to flagged vulnerabilities. Organizations can align these teams effectively by creating shared objectives, providing security training to developers, equipping teams with automated tools, and embedding remediation and threat response policies into developer workflows.
#3: What you can’t see, you can’t fix
Network visibility isn’t just important for snuffing out live threats. It’s also critical to observing how code interacts with new or hidden assets in the software development lifecycle. Even several months after Log4Shell was discovered and patches were made available, an investigation found that ‘fewer than five percent of open source library versions’ on Maven Central, a repository of Java open source libraries, were using the fixed version of the Log4j library. The researchers suspected that developers were less likely to patch as a result of limited visibility into their application, which also meant they were unaware of vulnerabilities in the app libraries.
Fortunately, organizations are spoiled for help when it comes to addressing the matter. The use of automated web app scanning tools like Dynamic Application Security Testing (or DAST) and Interactive Application Security Testing (or IAST) are capable of scanning across all endpoints and technologies, regardless of languages or frameworks being used. These automated scanners boost visibility and add welcome levels of precision to vulnerability hunts. Organizations using a combination of DAST and IAST can significantly reduce false positive alerts, uncover vulnerable assets that are hidden, and accelerate remediation.
