**12/20/2021 Update: Apache has released Log4j 2.17.1, which resolves a Denial of Service and potential Remote Code Execution vulnerability captured in CVE-2021-45105. We recommend organizations update to 2.17.1 as soon as possible, with additional valid recommendations listed below.**
A critical vulnerability has been recently discovered in the Apache Log4j Java logging library (CVE-2021-44228), a library used in many client and server applications. The Log4j library is commonly included in Java based software including multiple Apache frameworks such as Struts2, Solr, Druid and Fink. The library provides enhanced logging functionality for Java applications and is widely used.
This vulnerability is the result of an Apache system design error involving the Java Naming and Directory Interface (JNDI). JNDI is a part of how applications speak to each other, and in the case of this vulnerability, has left the application server utilizing the library vulnerable. JNDI handing in log4j (and all applications that use it) was susceptible to a variable injection attack, which can be used to trick the application into leaking sensitive information, or executing attacker provided code. As a result of this vulnerability, threat actors can ultimately exfiltrate sensitive information or execute malicious payloads on vulnerable victim application servers, potentially allowing complete access to your network.
Incident Response Around Log4J
Kroll alerted clients to the threat on Friday, December 10 and shortly thereafter Kroll was engaged by several impacted customers and is continuing to be engaged on new related work as of this article’s posting. Our Kroll Responder team has been continuing to refine telemetry searches to identify potentially impacted instances of log4j in association with external connections to identify applications and hosts that need the most urgent attention.
Our team has observed that scanning of an organization’s perimeter networks to identify and prioritize issues requiring immediate focus and time is a crucial initial step. It is also important to review available alerts from any existing security products, most of which have already implemented rules to help identify log4j exposures, as well as reviewing and responding to log4j scanning events.
How We’re Detecting Log4J
One initial indicator of compromise (IOC) would be specially crafted incoming requests to a victim network. These requests contain special strings in the format “${jndi://[...]}” and may be obfuscated to avoid detection. This could indicate that a network is being scouted by potential threat actors or through their mass scanning automations to hone in on vulnerable applications or networks, and that proactive solutions should be engaged to ensure that a network is not subject to attack or that sensitive data is not being queried and leaving the network.
A more critical indicator of compromise would be detection of any outbound LDAP requests from the network to unknown IPs. This should be immediate cause for concern, as the most likely explanation is that your network has been affected by the Log4j vulnerability.
At this stage, we’ve instituted detections across a variety of integrations, from endpoints, firewalls and webservers running on Linux, Windows and macOs.
Kroll has observed that this vulnerability is actively being exploited in the wild, and is being used to install botnets, crypto mining malware and in the initial stages of intrusions. Our investigations are largely identifying that by the time Kroll is being engaged, the Threat Actor has already moved into stages three (3) or four (4) of the Kroll Intrusion Lifecycle and information is still being gained and reviewed to determine separate threat actor’s and their ultimate goals, whether Ransomware, Financial Fraud, or Data Exfiltration (stages 7 and 8).
Detecting intrusions in the early phases before they move to steps 5 or later.
Helpful Resources
The infosec community has rallied around CVE-2021-44228 due to its wide-ranging impact. Below is a small list of resources compiled by security researchers and agencies worldwide:
- The U.S. Cybersecurity and Infrastructure Agency (CISA) is maintaining a list of publicly available vendor advisories regarding the Log4J vulnerability in this repository
- Security researcher SwitHak compiled a list of security advisories, organized by alphabetical order: see repository
- The National Cyber Security Center in Netherlands (NCSC-NL) created an overview of any related software potentially impacted by the Log4j vulnerability: see repository
Recommendations
Kroll recommends organizations take the following steps:
- All users are recommended to upgrade to Log4j 2.17.1 for full mitigation. [APACHE]
- Review impacted systems and apply recommended vendor patches. If patches are not available, isolate or disable the affected system or service until patching is available.
- Enumerate external facing devices that have Log4j installed. [CISA]
- Make sure that your security operations center is actioning every single alert on the devices that fall into the category above. [CISA]
- Install a web application firewall (WAF) with rules that automatically update so that your SOC can concentrate on fewer alerts. [CISA]
- If you use a Snort or Suricata based (or compatible) network-based intrusion detection system, you may want to use rules to detect exploitation attempts. [Swiss CERT]
- Check vulnerable systems very carefully for any sign of exploitation as the scanning is very intense and we believe that vulnerable systems got exploited quickly. [Swiss CERT]
- If you are using a WAF, deploy log4j specific rules. These exist for many commercial solutions such as Cloud Armor6, Cloudflare WAF7, Signal Sciences WAF8. [Swiss CERT]
How Kroll Can Help With Log4J / Log4Shell
- External Vulnerability Scanning
Kroll can be engaged to conduct rapid and actionable Log4j specific scans of external IP address ranges to identify issues requiring focus and potential further investigation. - Security Recommendations and Advisement
In terms of a proactive response to the Log4j vulnerability, Kroll can assist in inventorying various systems, applications and software using Log4j in the environment. Kroll has capacity and is experienced in providing guidance on how to apply the relevant security patching or security changes for affected systems, applications, software, etc. If patching is not yet available or possible, Kroll can provide guidance on isolating the affected systems or applications from the Internet and can assist in recommending alternate mitigation measures. - Log Analysis
Kroll can assist in firewall, application, and network traffic log analysis, checking for exploitation attempts, both successful and unsuccessful. Kroll can search for the presence of known indicators of compromise (IOC) that are being actively collected by our threat intelligence, incident response findings, and managed detection services. - Incident Response
In terms of digital forensics and incident response, Kroll can be engaged to investigate and contain network compromises and active maliciousness, as well as investigate network intrusions and threat actors who have successfully exploited the Log4j vulnerability to compromise a victim network.
Let’s Not Forget
Even though CISA Director Jen Easterly told industry leaders in a phone briefing Monday that the Log4j vulnerability “is one of the most serious I’ve seen in my entire career, if not the most serious.” and thousands of information security professionals have had very little sleep over the past few days, it’s important to keep a level head. Yes, patch as soon as possible, but also consider existing detections and your ability to respond should something suspicious happen.
For internal teams burdened with a host of other priorities and a remote workforce, support from dedicated experts who have the frontline expertise, resources and technical skills to assess your exposure can greatly reduce your risk profile. Talk to a Kroll expert today via our 24x7 hotlines or contact form.
Contributors to this article: Josh Karanouh-Schuler, Keith Wojcieszek
