On 8 December 2020, FireEye announced they were a victim to a nation-state attack and several days later they discovered evidence that attackers had a backdoor in SolarWinds software and dubbed the attack as “SUNBURST”. 

Almost a year later to the day a new 0-day vulnerability crashed onto the scene on 9 December called Log4Shell. The vulnerabilities in this library are exposing some of the world's most popular applications and services to attack. Basically, ransomware operators who were hoping to catch enterprise teams by surprise during the holidays, along with crypto coin miners, just received the perfect gift from Santa.

Steve Springett, who leads software security for ServiceNow in their product security team, is an open-source software (OSS) advocate and is also passionate about helping organizations reduce risk introduced from the use of third-party and OSS components. In this week’s Reimagining Cyber podcast episode, “Log4j vulnerabilities: All you need to know and how to protect yourself,” Springett explains the Log4j vulnerabilities and their potential exploit. He also shares the process enterprises need to take to respond to OSS incidents and how some of the OWASP projects he is involved in can be used to mitigate risks. 

Log4J vulnerabilities have everyone scrambling

Log4Shell is officially being tracked as CVE-2021-44228. This vulnerability has received the highest possible CVSS score of 10. The CVE impacts default configurations of Apache frameworks. It is a remote code execution (RCE) vulnerability that quickly got system administrators, security professionals, and software vendors scrambling to assess exposures and deploy remediations to minimize potential exploits that started almost immediately. 

The fix to CVE-2021-44228 does not always protect against infinite recursion in lookup evaluation making it susceptible to a denial-of-service vulnerability, CVE-2021-45105. Springett shared that the recommended mitigation is to apply the 2.17.0 patch to the Log4j library (note, detailed instructions for patching Micro Focus products can be found on the Micro Focus log4j updates page, with the CyberRes products called out on this page). Springett also noted that these vulnerabilities apply to Log4j-core and not to other Log4j functions like API. 

Modern software applications and products are assembled from dozens if not hundreds of components, many of which nowadays are open-source projects because everyone agreed long ago that it doesn’t make sense to reinvent the basic plumbing all software needs to work every time a new application is created. Springett noted that since Java is one of the most popular enterprise software languages AND Log4J being one of the most popular logging tools used in Java applications, the impact is widespread. 

Applying best practices from OWASP projects

Springett has been a long-time advocate for OSS and leads several OWASP projects that can help mitigate associated risks. Springett leads the OWASP Dependency-Track project, the OWASP Software Component Verification Standard (SCVS), and is the Chair of the OWASP CycloneDX working group that’s defined a lightweight Software Bill of Materials (SBOM) standard. The standard captures an accurate inventory of all components, thus enabling organizations to identify risk, allowing for greater transparency and rapid impact analysis. 

Springett shared the value of Software Composition Analysis (SCA) and have SBOMs available during incident responses like the one we are experiencing with the Log4j vulnerabilities. Some SCA vendors, like Sonatype, support the CycloneDX SBOM standard. Steve also mentioned how vendors can use the NTIA Vulnerability Exploitability eXchange (VEX) as a way of communicating the exploitability of some of vulnerable components. Steve recommends that to be most helpful, vendors should provide both an SBOM and a VEX to consumers. 

As for the broader issue of software supply chain risks, the OWASP SCVS establishes a common set of activities, controls, and best practices that organizations can apply to reduce these risks. Like other OWASP verification standards, the CSVS defines three levels of maturity, with most organizations likely needing to target level 2. Springett recommends starting by targeting a few controls and developing a roadmap to progress to target maturity over time. 

Are you taking advantage of OWASP best practices? Share in the comments below!  

You can find the latest episode of Reimagining Cyber on Apple, Soundcloud, Stitcher, Google Play, and Spotify. Give it a listen, and let me know what you think. 

CyberRes is a Micro Focus line of business focused on helping companies protect, detect, and evolve their security framework and helping organizations become more cyber resilient. To learn more, visit CyberRes.com. For more on CyberRes’ response to the Log4j vulnerability, visit the CyberRes blog. This blog article is being updated daily and contains links to Security Bulletins that are specific to the Log4j compromise.