NetWitness Community

Will_G · ‎2021-12-11

Apache Log4j (‘Log4Shell’): Background and Detection Rules

What We Know

It is important to recognize and understand that this vulnerability and the circumstances related to is exploitation globally are dynamic. As the NetWitness Threat Intelligence Team learns more about the threat(s) associate with Log4Shell, we shall update and share recommendations with our customer here, on this blog. Special thanks go out to our peer organization, the NetWitness Incident Response Team for their perseverance and dedication in serving our customers and sharing their insights with us as work toward providing the best recommendations and content for our customers worldwide.

On December 09, a new vulnerability was disclosed and written about extensively by Apache that impacted the projects Log4j offering. MITRE created and published CVE-2021-44228 (the vulnerability was elevated to zero-day status and has a CVSS Score of 10 or ‘CRITICAL’), and the world waited with bated breath as reports of exploitation and attacks began appearing online. Credit for the discovery of the vulnerability in question was given to Chen Zhaojan, of the Alibaba Cloud Security Team. At the of initial publication, the vulnerability was thought to impact at least two versions of the code set – 2.0beta9 and 2.14.1, respectively. When exploited successfully, an attacker may succeed in achieving remote code execution (RCE)[i] thus enabling them to begin advance their efforts within the target and its environment. Post publication of the CVE by MITRE, Apache acted appropriately in addressing the vulnerability through publishing a patch in version 2.15.0 of Log4j. And despite the efforts of the Apache Project team work to mitigate the threats posed by the vulnerability, reports began flowing online within the threat research and incident response community, in addition to the press and world began mustering in order to brace itself and address threats known and unknown moving forward.

Global Impact

At the time of this update, we simply do not know just how many organizations worldwide, applications, packages, or platforms are at risk. However, we do know that due to the nature of the vulnerability (recall that the execution of arbitrary remote code is possible by an attacker is possible they successfully exploit the vulnerability), and the myriad number of interdependencies associated with, and related to log4j, the threat is real, and the gravity will likely not be fully realized for some time to come. Many are comparing this to the infamous ‘Heartbleed’ vulnerability (CVE-2014-0160) from April 7, 2014 (which maintains a base CVSS Score of 7.5 or ‘High’). However, it would appear that given the number of well known and heavily utilized applications and platforms impacted by Log4Shell, this is not a fair comparison and Log4Shell may be far worse in the long run. Here is a concise list of impacted applications, platforms, and vendors to illustrate that point:

Various Apache projects (e.g., Druid, Dubbo, Flink, Flume, Hadoop, Kafka, Solr, Spark, Struts, Tapestry, Wicket)
Elastic Search and LogStash
GrayLog2
Neo4j
Various VMWare products
Minecraft client and server
And many more

What You Can and Should Do to Address and Mitigate Threats Related to CVE-2021-44228

The first place to begin with respect to addressing CVE-2021-44228 involves identifying any/all assets within your organization that may be susceptible to exploitation of this vulnerability. Begin by expediting the identification and analysis of all assets while making a concerted effort to identify shadow IT that may be susceptible to exploitation but not accounted for in traditional asset inventories and CMDBs. Once organizations who believe they may be impacted by the Log4j vulnerability have identified their assets, they should initiate the patching cycle. This should be done in observance of industry and organizational best practices for patching while adhering to guidance provided by vendors who produce applications and platforms impacted by the Log4j vulnerability. Additional attention should be given to communications from the Apache Project about updates to the Log4j project.

Furthermore, impacted organizations may wish to pursue the following courses of action in respect to their defensive strategies:

Update Firewall rules
Update IDS/IPS rules
Update any/all host-based endpoint protection platform solutions where appropriate
Block outbound connections from public facing servers, including DNS resolution of public domain names. This recommendation is a best practice that applies to this threat and other future threats. If there is a business need for these servers to communicate outbound it should be done via a whitelist of destinations.

How NetWitness Can Help You Detect for the Presence of the Log4j vulnerability and Log4Shell

NetWitness Network for Detection and Response Packets User Environments

The NetWitness Threat Intelligence and Product teams crafted and published three (3) application rules on Saturday, December 11, 2021. For customers using NetWitness Network for Packets, the following rules were designed to detect outbound communications associated exploitation of the Log4j vulnerability, especially when complimented with SSL interception technology for inbound/outbound traffic.

Application Rules

Rule Number 1: Application Rule for Detection of Outbound LDAP (Lightweight Directory Access Protocol) Communications
- direction='outbound' && service=389

These two rules have been deprecated and are no longer recommended for use (please see the sentence directly below them for more information):

Rule Number 2: Application Rule for Detection of Outbound LDAPS (Lightweight Directory Access Protocol over SSL) Communications
- direction='outbound' && service=636
Rule Number 3: Application Rule for Detection of Outbound RMI Registry Service Provider Communication
- direction='outbound' && service=1099

As of today, Monday, December 13, 2021 rules 2 and 3 have been deprecated and are no longer being recommended due to questions related to their efficacy and potential performance.

In addition to these rules, we are attaching SNORT signatures and YARA rules developed by the team SOC PRIME team (SIGMA Rules Repository). These signatures will aid in detecting scans used by attackers in order to identify assets that are susceptible to the exploitation of the Log4j vulnerability using the original Proof of Concept.

Moreover, we recommend that impacted organizations look for and pay attention to suspicious behavior associated with impacted servers if a successful exploitation has occurred. Behaviors to look for include but are not limited to the following:

Suspicious outbound connections from servers
Usual patterns of behavior associated with lateral movement including:
- Reconnaissance
- Credential Dumping and Privilege Escalation
- Gaining Access

Additionally, two legacy NetWitness Packet Parsers have been augmented in order to provide our customers with broader detection capabilities related to the Log4j vulnerability/ Log4Shell exploits while a third new Packet Parser has been added to aid our customers in their hunts, detections & responses:

DynDNS
- Additional domains were included that have been associated with beaconing from compromised hosts/systems
LDAP
- Add ports commonly used by Oracle to hopefully detect more LDAP sessions: 1389, 1636, 4444, and 8989. Prior to this change, this parser only looked for sessions on ports 389 and 636.
RMI (Java Remote Method Invocation)
- Identifies Java Remote Method Invocation protocol

NetWitness Endpoint for Detection and Response User Environments

The NetWitness Threat Intelligence team recommends the application of the following endpoint rules for organizations impacted by the Log4j vulnerability:

HTTP Daemon Runs Reconnaissance Tool
HTTP Daemon Writes Executable
HTTP Daemon Runs Command Prompt
HTTP Daemon Runs PowerShell
Suspicious running processes on the affected servers

As we learn more, we will update this blog and share more insight and content with the community. If you have further questions, please feel to reach out to william.gragido@netwitness.com.

Update(s):

Addition of a list of pointers to SNORT IDS Signatures that address CVE-2021-4428
Attachment of three (3) packet parsers - two of which are legacy and have been augmented to address Log4j exploitation and one that is net new to address JRMI
Addition of a new app rule to useful in the detection of log4j exploit attempt that can lead to RCE(CVE-2021-44228) available in the 'Community' section of RSA NetWitness LIVE

Endnote(s):

[1] this occurs when an attacker who has control of log messages or log parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. According to Apache this behavior is now disabled by default in version 2.15.0)

TheWanderingWu · ‎2021-12-13

It should be noted that all three of the rules have improper syntax and won't work as written. Direction requires the values to be in quotes since it's a text field.

Outbound LDAP
direction='outbound' && service=389

Outbound LDAPS
direction='outbound' && service=636

Outbound RMI Registry Service Provider Communication
direction='outbound' && service=1099

Will_G · ‎2021-12-13

Thanks for the catch @TheWanderingWu. We're addressing the syntax error now.

bhatsunita · ‎2021-12-15

Hi,

We are Secure ID Governance & Lifecycle customer with version 7.2.1P6. What patch do we need to apply ?

Rgds

Sunita

Will_G · ‎2021-12-16

Hi @bhatsunita,

Thanks for the comment. I am not sure what patch(es) are applicable to the Secure ID Governance & Lifecycle offering. I recommend contacting Secure ID at the following link: https://www.securid.com/en-us/customers/technical-support.

They should be able to point you in the right direction.

Good luck!

Best,

Will_G

RichardB · ‎2021-12-17

What do we need to do/configure to make NetWitness set service to 1099 for JRMI traffic? We always get service=0, see screenshot.

JRMI example

Same question for service=636 / LDAPS.

NajeebPeracha · ‎2021-12-17

Hi @bhatsunita - Please refer to the following advisory about the impact of Apache Log4j2 vulnerability CVE-2021-44228 on SecurID Governance & Lifecycle product:

https://community.rsa.com/t5/general-security-advisories-and/rsa-customer-advisory-apache-vulnerability-log4j2-cve-2021-44228/ta-p/660501