We strongly encourage our customers to update their version of Log4j. The fact this vulnerability is not exploitable in newer JVM is not enough. This just highlights the need to get rid of infrastructure and speed to the cloud.
Summary
On December 10th, 2021, the National Vulnerability Database (NVD) published the CVE-2021-44228 documenting a vulnerability in the Apache log4j library Java Naming and Directory Interface (JNDI) lookup feature allowing for remote code execution by an attacker who is able to manipulate log messages. A proof of concept was released on December 9th, 2021, and active scanning and exploitation attempts have increased through the time of the publishing of this brief.
An important note - this vulnerability was around before December 9th, 2021, and readers should look for possible exploitation attempts in their environment in time frames prior to the disclosure and CVE published date.
Activity Overview
The vulnerability in the JNDI lookup feature allows for variables to be retrieved and resolved via JNDI, causing the vulnerable implementation of log4j to connect to remote resources and possibly execute malicious code.
Image from the Swiss Government Computer Emergency Response Team (GovCERT.ch) here
Example: a crafted event, like a HTTP request with a malicious User Agent String, can be processed by the vulnerable log4j library to create a new event log, by processing the malicious event information with the JNDI variable, the application will go to the resource in order to retrieve the required variable.
HTTP Request example with a crafted HTTP User Agent String:
user_agent: ${jndi:ldap://127.0.0.1/a}
This would be processed by log4j and request the resource /a from 127.0.0.1.
The JNDI lookup feature is associated with multiple protocols, for example: ldap, rmi, ldaps, dns, etc. In the Hunting Opportunities section below, Sumo Logic SpecOps recommends searching the jndi: string to identify more than just the listed examples of protocols used, in addition to URLs and other important elements of this attack.
Hunting Opportunities
Hunting for this activity in your environment is greatly benefited by visibility into web, application, and network traffic. Given the various places an attacker can place a JNDI reference in said traffic, we recommend taking a more open approach in looking for this activity.
The following queries have been crafted to identify various forms of possible exploitation of this vulnerability, and have been written for the Sumo Logic Continuous Intelligence Platform: first, formatted for the Cloud SIEM Enterprise (CSE) records; and second, for the broader Continuous Intelligence Platform user base. (There is little variation between the two, other than specifying the view/index the queries will run in).
Sumo Logic customers with Cloud SIEM Enterprise:
Log4Shell Base search across all CSE records looking for possible attempted exploitation:
_index=sec_record_* ("jndi:" or "{lower:j" or "{upper:j" or "-j}" or ":-j%7")
| parse regex "(?<jndi_string>\$\{(?:\$\{[^\}]*)?j\}?(?:\$\{[^\}]*)?n\}?(?:\$\{[^\}]*)?d\}?(?:\$\{[^\}]*)?i.*?:}?[^,;\"\\]+}?)[\\\";,]" nodrop
This search utilizes key terms associated with the ASCII representation of the Log4Shell exploit, including obfuscation, of the jdni: construct at the heart of this vulnerability. Upon successful matching of the regular expression, the search will parse or extract a new field called “jndi_string”.
The newly created “jndi_string” field can be used to hunt for outbound traffic denoting possible compromise or successful exploitation by parsing additional information out of the available exploit string.
Log4Shell parsing of possible exploit URL, IP/FQDN, and URI:
_index=sec_record_* ("jndi:" or "{lower:j" or "{upper:j" or "-j}" or ":-j%7")
| parse regex "(?<jndi_string>\$\{(?:\$\{[^\}]*)?j\}?(?:\$\{[^\}]*)?n\}?(?:\$\{[^\}]*)?d\}?(?:\$\{[^\}]*)?i.*?:}?[^,;\"\\]+}?)[\\\";,]" nodrop
| parse regex field=jndi_string "//(?<jndi_url>[^\"]+)}" nodrop
| parse regex field=jndi_string "//(?<jndi_host>[^/]+?):?(?::(?<jndi_port>\d+))?(?<jndi_uri>(?:/[^/]+){1,})\}" nodrop
| count by jndi_string,jndi_url,jndi_host,jndi_port,jndi_uri
Extending the base search, this parses and extracts the following key fields:
jndi_url - the resource an exploited system would attempt to retrieve if successful
jndi_host - the IP address or fully qualified domain name (FQDN) where the referenced resource is hosted
jndi_port - the port, if available, associated with the resource
jndi_uri - the resource the identified by the URL
These newly parsed fields can be put to use hunting for network connections, including DNS traffic, outbound to the URLs, IP addresses, and domains. This is an important part of closing the loop of determining impact and necessary response.
Sumo Logic customers:
Due to the variable nature of how you access your logs, SpecOps highly recommends the use of a scoping statement that allows the platform to search for keywords.
Log4Shell base search scope:
("jndi:" or "{lower:j" or "{upper:j" or "-j}" or ":-j%7")
| parse regex "(?<jndi_string>\$\{(?:\$\{[^\}]*)?j\}?(?:\$\{[^\}]*)?n\}?(?:\$\{[^\}]*)?d\}?(?:\$\{[^\}]*)?i.*?:}?[^,;\"\\]+}?)[\\\";,]" nodrop
As with the Cloud SIEM Enterprise queries above, the first line narrows the scope to key terms related to the Log4Shell vulnerability. The parse regex construct matches on known versions of the exploitation attempt to parse a new field called jndi_string for further processing.
The newly created “jndi_string” field can be used to hunt for outbound traffic denoting possible compromise or successful exploitation by parsing additional information out of the available exploit string.
Log4Shell parsing of possible exploit URL, IP/FQDN, and URI:
("jndi:" or "{lower:j" or "{upper:j" or "-j}" or ":-j%7")
| parse regex "(?<jndi_string>\$\{(?:\$\{[^\}]*)?j\}?(?:\$\{[^\}]*)?n\}?(?:\$\{[^\}]*)?d\}?(?:\$\{[^\}]*)?i.*?:}?[^,;\"\\]+}?)[\\\";,]" nodrop
| parse regex field=jndi_string "//(?<jndi_url>[^\"]+)}" nodrop
| parse regex field=jndi_string "//(?<jndi_host>[^/]+?):?(?::(?<jndi_port>\d+))?(?<jndi_uri>(?:/[^/]+){1,})\}" nodrop
| count by jndi_string,jndi_url,jndi_host,jndi_port,jndi_uri
Extending the base search, this parses and extracts the following key fields:
jndi_url - the resource an exploited system would attempt to retrieve if successful
jndi_host - the IP address or fully qualified domain name (FQDN) where the referenced resource is hosted
jndi_port - the port, if available, associated with the resource
jndi_uri - the resource the identified by the URL
These newly parsed fields can be put to use hunting for network connections, including DNS traffic, to the URLs, IP addresses, and domains. This is an important part of closing the loop of determining impact and necessary response.
Advanced Hunting:
Sumo Logic SpecOps has observed attackers utilizing Java variables to obfuscate both the JNDI reference and attempt to exfiltrate system information in the URL payloads. The following search utilizes regular expressions to parse multiple fields from the jndi_string for the purpose of analyzing possible Java variables in the exploitation attempts.
Java Variable Parsing*:
_index=sec_record_* ("jndi:" or "{lower:j" or "{upper:j" or "-j}" or ":-j%7")
| parse regex "(?<jndi_string>\$\{(?:\$\{[^\}]*)?j\}?(?:\$\{[^\}]*)?n\}?(?:\$\{[^\}]*)?d\}?(?:\$\{[^\}]*)?i.*?:}?[^,;\"\\]+}?)[\\\";,]" nodrop
| parse regex field=jndi_string "(?<java_variable>\$\{[^\}]+\})" multi nodrop
| parse regex field=jndi_string "//(?<jndi_url>[^\"]+)}" nodrop
| parse regex field=jndi_string "//(?<jndi_host>[^/]+?):?(?::(?<jndi_port>\d+))?(?<jndi_uri>(?:/[^/]+){1,})\}" nodrop
| values(java_variable) as java_variables, count by jndi_string,jndi_url
This search parses out most variables matching the ${...} pattern including the obfuscation examples shared above, like ${::-j}. An important observation: the values() operator does not sort the parsed output.
Java URL Variable Parsing*:
_index=sec_record_* ("jndi:" or "{lower:j" or "{upper:j" or "-j}" or ":-j%7")
| parse regex "(?<jndi_string>\$\{(?:\$\{[^\}]*)?j\}?(?:\$\{[^\}]*)?n\}?(?:\$\{[^\}]*)?d\}?(?:\$\{[^\}]*)?i.*?:}?[^,;\"\\]+}?)[\\\";,]" nodrop
| parse regex field=jndi_string "(?<java_variable>\$\{[^\}]+\})" multi nodrop
| parse regex field=jndi_string "//(?<jndi_url>[^\"]+)}" nodrop
| parse regex field=jndi_string "//(?<jndi_host>[^/]+?):?(?::(?<jndi_port>\d+))?(?<jndi_uri>(?:/[^/]+){1,})\}" nodrop
| parse regex field=jndi_url "(?<java_url_variable>\$\{[^\}]+\})" multi nodrop
| values(java_url_variable) as java_variables, count by jndi_string,jndi_url
Utilizing the same multiple field parsing as the Java Variable Parsing above, this search applies the parsing to specifically the jndi_url field, extracting Java variables used for possible exfiltration of victim information.
SpecOps has observed variables ranging from java version, host, hostname, user, and user.name to more sensitive information such as environmental variables, database name, database password, and sensitive AWS information.
*Sumo Logic Customers can remove the “_index=sec_record_*” portion of the search for use in their environments.
An important caveat with these queries: not all of the parsed fields may contain information, as the parsing will only work on data matching the parsing pattern.
On Friday December 10th, 2021, the rule MATCH-S00209 CVE-2021-44228 Log4j2 Java Library 0-Day Attempt was deployed and set to Prototype for Sumo Logic CSE customers. This rule looks for attempts and does not indicate successful attacks.
Recommendation: Patch now
Sumo Logic SpecOps recommends identifying any applications that rely on the log4j library and immediately applying the appropriate patch that can be found here. Also, please keep in mind that vendor-affected products may require a patch that will need to be pushed downstream and may not be immediately available. A list of affected products can be found here.
Broadened visibility is key. As such, SpecOps recommends collecting a variety of log sources such as weblogs, application server logs, and network sensor logs to help identify attempted exploitation of this vulnerability. As vulnerabilities continue to surface in widely adopted software, ensuring proper visibility into every aspect of the environment is becoming a top priority.
