Aggravating Circumstances for an RCE Vulnerability: A Log4j Retrospective and Risk Landscape Evaluation

Author: Justin Henkel, Head of CISO Center for Excellence, OneTrust
Date Published: 7 February 2022

Editor’s note: The following is a sponsored blog post from OneTrust:

Information security teams were forced to respond over the holiday as an Apache Log4j zero-day vulnerability was discovered and socialized across the infosec community. The key to being well-positioned for this event is having the right programs in place before it ever happens. In this blog, we’ll dissect the unique challenges of an RCE vulnerability and potential attack, as well as the current risk landscape that further complicates how developers and information security professionals can respond.

The nature of the Log4j vulnerability and exploitation
The threat of unpatched remote code execution (RCE) vulnerable systems is substantial because it allows attackers to remotely execute arbitrary commands on a victimized machine to exploit data seamlessly. An RCE exploitation could culminate in copying user credentials, accessing the intellectual property (IP), or deleting critical files with valuable business information. The Log4j RCE event was further compounded because it was also a zero-day vulnerability, a vulnerability in a system or device without a patch. Zero-days are most often found by external parties, not the software developer. In the best-case scenario, the vulnerability is found by a white hat penetration tester performing an authorized test or other IT risk mitigation activities who then reports the issue to the authoring organization, allowing time to fix its software or application. Log4j was a worst-case scenario; it was found in the wild by a third-party organization that had to alert Apache to its existence. The opportunity for threat actors to search and exploit skyrockets as the RCE vulnerability was socialized publicly after the bug was discovered but not patched by the software owners.

Given the global install base of the Log4j and the nature of the zero-day RCE, this recent event continues to have a broad, large-scale impact beyond the initial response. The audience for the recent Log4j is expansive, as Apache is a popular open-source code logging database. Organizations continue to search their networks and IT environments for any instance where unpatched Apache systems may reside.

The stakes continue to escalate
As we reflect on this recent exploitation, several aggravating factors stand out, making the current risk landscape harder to navigate.

  • Shrinking Left of Boom – The left of boom is a popular term in the cybersecurity space referring to the time between when a vulnerability is first identified and subsequently exploited. This time, once measured in days, has diminished to hours. The shrinking timeframe overshadows rapid turnaround and response patches produced by impacted software development teams. Even unsophisticated agents can acquire the means to streamline their attack, using automated scanners to identify vulnerabilities and exploit businesses that are either unaware or have not yet addressed vulnerabilities in their IT ecosystem.
  • Sprawling and Complex IT Ecosystem - IT asset scans can be labor-intensive, and even with automated scanning tools, certain technicalities can create opportunities for instances of the identified vulnerability to be missed in your remediation efforts. SC Media recently publicized a new study by jFrog where they found hundreds of exposed Lo4j systems uncovered in Maven Central.
  • Rising Accountability for Cyber-Negligence - Enforcement agencies such as the Federal Trade Commission (FTC) have made statements recognizing the cascading impact to the general public of vulnerabilities such as Log4j. Organizations that fail to take action on publicly documented vulnerabilities may be found negligent soon under expanding cybersecurity regulations. Vulnerabilities of this nature can hinder the business and the public if an attack compromises personal data on a known vulnerability.

Refining your IT and security risk management strategy is an ongoing requirement at any stage of program maturity. Regardless of the current circumstances, people, processes, and technology are three focus areas of operationalizing any strategy. When looking to invest or implement a change to any of these areas, consider how the change will help you:

  • Reduce your response time
  • Simplify your tech stack
  • Streamline reporting

Identifying and selecting technology that can fit and adapt with your business's changing landscape is essential to enabling the organization and gaining visibility to your security and risk posture. A flexible and integrated GRC solution can help bring these pieces together in a measurable way, with a foundation to build automation and operationalize a proactive IT & security strategy.

About the author: Justin Henkel is an information security thought leader, subject-matter expert, and Head of OneTrust's Security Center of Excellence. Justin has a proven track record planning, developing, building and monitoring portfolios of work to secure IT infrastructure to meet federal and state cyber security standards, guidelines, and best practices. He has extensive experience communicating to senior leadership on business-aligned cyber security and incident response operations. In addition, Justin has 15 years of experience in vulnerability management, cyber intelligence and risk remediation in government, the intelligence community and financial sectors.