On January 4, 2022, the Federal Trade Commission (FTC) warned that “It is critical that companies and their vendors relying on Log4j act now, in order to reduce the likelihood of harm to consumers, and to avoid FTC legal action.” Additionally, the FTC has expressed a desire to further evaluate the dependency on open-source services and the potential impact on customers.
What We Know
On December 10, 2021, Apache released an advisory for a critical vulnerability in the Log4j version 2.x application. Log4j is a Java-based logging system commonly used in commercial and proprietary Java and other web and server applications. The Log4j vulnerability was assigned CVE-2021-44228 and has a CVSS rating of 10 (critical) for three primary reasons:
- Log4j is very commonly deployed in Java applications.
- The Log4j vulnerability is trivial to exploit.
- The result of successful Log4j vulnerability exploitation is remote code execution, allowing a malicious actor to control a computer and use it in support of ransomware campaigns, data exfiltration, creating a backdoor for later use, or any other number of nefarious activities.
Since the December 10, 2021 advisory, there have been additional vulnerabilities discovered that affect the Log4j application. These vulnerabilities (CVE-2021-45046, CVE-2021-45105, and CVE-2021-4104) have varying levels of severity and impact that range from remote code execution to denial of service. As the cybersecurity community progresses in their response, the situation has continued to rapidly evolve. The vulnerabilities themselves have been reassessed based on new findings as well as the software versions affected. The situation illustrates the importance of close monitoring in order to ensure your organization’s remediation efforts are sufficient and appropriately prioritized.
Due to Log4j’s use as a component in building software, it is difficult to determine whether you are impacted. Since the announcement of the vulnerability, there have been publications by agencies such as the Cybersecurity and Infrastructure Security Agency (CISA), the Dutch National Cyber Security Centre (NCSC), and others regarding identifying vulnerable applications and necessary mitigating actions to prevent exposure.
CISA Director Jen Easterly stated that the ubiquity of Log4j allows for a myriad of malicious actors to carry out a variety of criminal activities. Threat actors exploiting Log4j have been known to conduct malicious activity including crypto-mining, ransomware, and data theft in the past. Easterly cautioned that the situation “presents an urgent challenge to network defenders.” In the rapidly evolving threat actor landscape, these are some noteworthy observations:
- Ransomware gangs are known to take advantage of the latest vulnerabilities, especially when they are as prolific as those associated with Log4j. Within two days of the public disclosure of the Log4j vulnerability, the infamous Conti ransomware group had already begun planning to exploit Log4j to gain initial access to their victims as well as to traverse the network once inside.
- Access brokers, malicious actors who gain access to a network then often sell the access to ransomware operators, have been observed incorporating exploitation of vulnerable Log4j versions into their operations.
- Both Microsoft and Mandiant have observed nation-state actors leveraging the Log4j vulnerabilities in their attacks, and expect use among nation-state actors to grow.
- Akamai, a cybersecurity services company, reports that the United States is the most commonly observed target of malicious activity with more than 10 million observed exploitation attempts. Furthermore, Cloudflare has seen approximately 25,000 exploit attempts per minute for users of their service.
- On January 4, 2022, the Federal Trade Commission (FTC) warned that “It is critical that companies and their vendors relying on Log4j act now, in order to reduce the likelihood of harm to consumers, and to avoid FTC legal action.” Additionally, the FTC has expressed a desire to further evaluate the dependency on open-source services and the potential impact on customers.
What is RiskRecon Doing?
RiskRecon’s proprietary software does not use the Log4j facility. RiskRecon hosts its systems with Amazon, which does use Log4j. Amazon is actively addressing the Log4j issue.
RiskRecon is helping customers understand their exposure to Log4j. While RiskRecon is not directly identifying internet exposure to Log4j (because doing so requires invasive scanning), the RiskRecon portal Data Search module provides some visibility into exposure. Customers can use the Data Search function to search for the known affected software. There are several reputable sources maintaining active lists of known impacted software, such as CISA and NCSC.
In addition to the Data Search capabilities within the RiskRecon portal, RiskRecon is conducting a deep analysis to generate a data file for each customer portfolio that enumerates the systems of each company running Java application server technology. RiskRecon is identifying systems running Java application servers based on indicators such as file extensions (.action, .do, .jsp, etc), cookies (jsessionid and others), and HTTP headers (java, jsp, etc). Contact RiskRecon Customer Support at support@riskrecon.com for the file that enumerates companies and related servers in your portfolio running Java server technology.
What is RiskRecon Seeing?
RiskRecon monitors millions of organizations through our proprietary passive scanning technology. In our evaluation of large organizations (those with more than 100 hosts detected by RiskRecon), we found that, on average, 74% of large organizations had at least one instance of an external-facing Java application server in their environment. When evaluating medium-sized (those with 10-100 hosts) and small-sized organizations (those with fewer than ten hosts), we saw a significant decrease in externally detectable instances of Java. RiskRecon observed at least one instance of a Java application server in 30% of medium-sized organizations and 5% of small-sized organizations.
While Java appeared to be significantly more prevalent among large organizations, our observations demonstrated the ubiquity of Java across all enterprises, regardless of their size. Our research also indicated that the utilization of Java varied by industry in addition to organizational size. These findings reinforced the importance of reviewing your asset inventory of both internet and internal-facing assets for the Log4j vulnerabilities. The chart below demonstrates the range of Java detected externally across large companies spanning various industries.
Best Practices and Lessons Learned
Vulnerabilities like Log4j are an important reminder of how important it is to continuously maintain strong cyber hygiene and implement proven best practices throughout your organization. Organizations that build and maintain an asset inventory of their own systems, servers, and versioning information, are in a much better position to immediately react to vulnerability disclosures and understand exposure.
The Log4j vulnerability also reinforces the importance of not only understanding your own asset inventory but also having a Strong Third-Party Risk Management program that allows you to understand the asset inventories and cyber posture of your vendors. With tools like RiskRecon, organizations are in a better position to respond faster to identify and mitigate vulnerabilities amongst internet-facing assets.
Asset inventory is just one of many important practices necessary to be more proactive in defending against vulnerabilities like Log4j. Other important practices include:
- Patch vulnerable systems: Maintaining the latest versions of software in your environment is a critical step in securing your ecosystem. Start by patching your most critical systems first; many times, these are your internet-facing assets. Then move on to address any other vulnerable software. RiskRecon’s Risk Priority Matrix and Software Patching security domain are tools that can help you identify and prioritize risky internet facing systems requiring patching.
- Use a Web Application Firewall: A web application firewall (WAF) can be used to block attackers attempts at inserting the malicious code into vulnerable servers (which could lead to the execution of the malicious code). WAF providers have been developing rules which attempt to address the Log4j vulnerabilities, therefore it is important to ensure that you are utilizing the latest methods made available. Due to the dynamic situation, it remains important to address the patching of vulnerable systems as well as other mitigating steps.
- Manage outbound network traffic: Ensure that your systems are appropriately configured and that outbound traffic is only allowed when necessary, and if possible, to trusted sources. Furthermore, the use of protocol enforcement can help prevent suspicious activity or alert system administrators for closer monitoring.
- Be constantly aware: Stay up to date on the vulnerabilities impacting your organization so that you can be ready to respond immediately. There are many resources out there to do this, you just need to make sure you subscribe to these notifications and that you read and respond to them. Examples include the list of mitigating measures published by CISA in “ED 22-02: Apache Log4j Recommended Mitigation Measures.”
- Report any suspicious activity to Law Enforcement: With the Log4j situation quickly evolving, it is still very early to determine the impact of the vulnerability in terms of the number of systems exploited. Many experts believe that Log4j will have years of impact. We know already that the vulnerability is actively being exploited. To that end, it is important to monitor and scan your systems for activity associated with Log4j exploits. We also strongly encourage reporting any unusual activity to Law Enforcement:
- United States: The FBI and CISA are seeking victims of Log4j to report malicious activity to the Internet Crime Complaint Center (IC3)
- Australia: Go to gov.au or call 1300 292 371 (1300 CYBER 1)
- Canada: Email CCCS at contact@cyber.gc.ca
- New Zealand: Visit govt.nz
- United Kingdom: Visit gov.uk/report-an-incident or, for urgent assistance, call 03000 200 973
Additional Guidance: For additional guidance regarding mitigations, we recommend referring to trusted sources such as CISA’s joint Cybersecurity Advisory on “Mitigating Log4Shell and Other Log4j-Related Vulnerabilities.”
About RiskRecon, A Mastercard Company
RiskRecon provides a SaaS platform that helps organizations more effectively manage the risk reality of increasingly interconnected IT ecosystems by delivering frequent, comprehensive and actionable security performance measurements. Using proprietary data gathering techniques, RiskRecon creates a 360-degree risk profile of an enterprise’s public IT footprint. Based on that footprint and detailed analysis, a RiskRecon rating and report are generated providing detailed, actionable information with context. No additional analysis is required.
Clients rely on RiskRecon to bring greater transparency, accountability and productivity to their vulnerability and third-party risk management processes. And, they trust that RiskRecon’s continuous monitoring solution employs only ethical techniques – no proprietary vendor data, no permissions and no invasive scans.
