LAST UPDATED: December 17, 2021
This guide is intended to provide a brief overview of the recently disclosed Log4Shell vulnerability and recommended remediation actions. For real-time updates, insights, and access to our cybersecurity experts, please visit Focal Point and CDW’s Log4Shell Resource Hub at its.cdw.com/log4j.
Late last week, a critical zero-day vulnerability in the Java-based Apache Log4j library was disclosed.
The exploit proof-of-concept was officially announced on Dec. 10, 2021, but there is evidence that it was being exploited as early as Dec. 1. The vulnerability was initially reported by Alibaba Cloud’s Security Team to Apache in late November.
The vulnerability is called Log4Shell or LogJam and is being tracked as CVE-2021-44228 with a CVSS score of 10 (Critical). The Apache Log4j2 version 2.14.1 is an open-source library designed to provide application debug logging. The vulnerability is an improper input validation flaw that allows the user to submit the format and content to be logged. Not only does this pose an issue where confidential information could be leaked to logs, but it also allows users to perform Remote Code Execution (RCE). The Java Naming and Directory Interface (JNDI) module of Log4j allows for “lookups,” which can make network connections to external servers that send back base64 encoded scripts in the User-Agent or URI fields instead of appropriately formatted log data. The encoded scripts are then inadvertently run when the server decodes the fields. Payloads can vary, but they typically download a malicious file on the target system, which can be used to establish a reverse shell, exfiltrate data, launch ransomware, or execute other malicious actions.
It is, without question, one of the most serious vulnerabilities in recent years, and its impact could stretch on for months, if not years.
The vulnerability is being actively exploited and is mutating to include obfuscation tactics. The flaw is extremely easy to exploit, and the exploit has multiple proof-of-concept versions spreading online. Some researchers estimate that more than 40% of corporate networks globally have already seen exploit attempts, and that number is poised to climb quickly.
All versions of Apache Log4j from 2.0.1 to 2.14.1 are susceptible to the Log4Shell attack. The Apache Log4j project released a version 2.15.0 update that patched and removed default settings for JNDI and lookup. Version 2.15.0 didn’t, however, address the use of Thread Context Maps (TCM) and Context lookups, so it is recommended that you update all Apache Log4j instances to the latest 2.16.0 version.
While the patch exists, performing the update will be immensely difficult for organizations due to the widespread nature of the vulnerability. The Log4j open-source library is used by countless applications, packages, frameworks, open-source projects, and software products, including those from most major vendors.
Because of the far-reaching nature of the vulnerability, enumerating every device, service, and application that contains the vulnerability will be an ongoing effort for network, systems, and security teams for some time. There are several lists circulating, including this one, that attempt to catalog the hundreds of known vulnerable products and services, though it may take weeks to have a full inventory. There are also open-source tools you can use to scan your applications for packaged dependencies that contain the vulnerability, including those that generate software bill of materials (SBOMs). While these tools are widely available, if you need guidance on selecting the right tools to support investigations at your organization, Focal Point and CDW are equipped to help. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has also created a Log4j guidance page and crowdsourced GitHub repo.
If you are struggling to discover and enumerate the affected systems within your environment, Focal Point and CDW can help you leverage analytics to speed and scale your efforts.
There are a set of workarounds published by Microsoft for legacy implementations of Log4j that cannot be patched. It is possible to set the system properties log4j2.formatMsgNoLookups or LOG4J_ FORMAT_MSG_NO_LOOKUPS within older versions of Log4j. This workaround, however, will only address the basic lookup vulnerability and not the TCM and Context lookups fixed by the version 2.16 update.
You should also bake package dependency and vulnerability scanning into the CI/CD pipeline for your apps. It may be necessary to rearchitect or modernize your applications to accommodate rapid vulnerability detection and package upgrades going forward. The best mitigation options at this point are to layer protections and detection.
Focal Point and CDW offer application hardening services for organizations needing assistance rearchitecting applications, restructuring dependences, deploying workarounds, or securing APIs.
For the protection layer, we recommend placing vulnerable systems behind a NextGen firewall and segmenting them from the Internet and user systems, wherever possible. You should also block outbound LDAP traffic wherever possible. It should also be noted that Log4Shell is an application layer exploit and you may need to enable SSL decryption for your NextGen firewall to detect all attempts. For systems that require a web-facing presence, a Web Application Firewall (WAF) and/or Runtime Application Self-Protection (RASP) can prevent attack traffic from reaching applications and APIs.
If you need assistance architecting, deploying, or tuning Log4Shell protections, Focal Point and CDW can engage at any level or phase to help you deliver reliable controls.
In addition to protection, strong detection will be required. To begin, create a prioritized asset inventory that lists any external-facing devices that have Log4j installed. The SOC will then need to prioritize and scrutinize any alerts related to the systems and continue to keep those systems under heightened surveillance for foreseeable future. Organizations will need to ensure that their SIEM is tuned with rules that will detect, correlate, and alert on Log4j RCE detections, lateral movement, data exfiltration, EDR alerts, and configuration changes. The best way to accomplish this is to map SIEM rules to the MITRE ATT&CK framework.
For this type of attack, the focus should include:
Tactics: Initial Access, Privilege Escalation, Execution & Impact
Techniques: Command and Scripting Interpreter (T1059) for Cobalt strike and Powershell, PowerShell (T1086), Service Execution (T1035), Drive-by Compromise (T1189), Data Encrypted for Impact (T1486), Data Exfiltration (T1020).
We recommend building rules that monitor outbound LDAP traffic, Log4j input strings in LDAP and DNS, and HTTP information in input fields like User Agent. The SOC Prime threat detection marketplace has a repo of rules available for those getting started. This exchange is updated weekly and already has several Log4Shell rules that can be replicated in a SIEM.
CDW and Focal Point offer a full suite of training, assessment, remediation, and managed services to strengthen your SOC capabilities, hardening your defenses against vulnerabilities like Log4Shell.
CDW and Focal Point stand ready to help our customers and the industry at large navigate the Log4Shell vulnerability.
If you think you have been compromised or need assistance hunting indicators of compromise (IOCs), our Incident Response Team can conduct breach discovery activities, assist with investigations, and guide remediation efforts.
For general consulting, support, and guidance related to Log4Shell, please contact your Focal Point or CDW account representative or visit https://its.cdw.com/log4j for access to resources and support personnel.
Subscribe to Focal Point's Risk Rundown below - a once-a-month newsletter with templates, webinars, interesting white papers, and news you may have missed. Thousands of your colleagues and competitors have signed up! You can unsubscribe at any time.