What is it?
CVE-2021-44228, also known as Log4Shell, is a remote code execution (RCE) vulnerability affecting Apache Log4j version 2, an open-source logging library for Java developed by the Apache Foundation.
The vulnerability allows unauthenticated remote code execution and can be triggered by threat actors from the Internet by sending specially crafted strings to various input vectors within an exposed vulnerable application, causing the application to include arbitrary Java code from an attacker-controlled system.
What’s the risk/impact?
As it is an unauthenticated remote code execution (RCE) vulnerability, successful exploitation of this vulnerability can lead any threat actor on the Internet to execute arbitrary commands on the operating system hosting the vulnerable application. The code will be run in the context of the user running the vulnerable application and in the case that it is run as a privileged user, it may lead to full system compromise.
Am I impacted?
The Log4j (version 2) library is widely used in many applications and is present in many services as a dependency. This includes enterprise applications, including custom applications developed within an organisation, as well as numerous cloud services.
It is frequently used in enterprise Java software and is included in Apache frameworks including:
- Apache Struts2
- Apache Flink
- Apache Solr
- Apache Druid
- Apache Swift
It is also used by other popular products and services from:
- Atlassian
- Citrix
- VMWare
- Cisco
- Splunk
- Okta
- Salesforce
- SolarWinds
- cPanel
- Elastic
- neo4j
At the time of writing this advisory blog there is still not a final definitive list of software being affected by CVE-2021-44228. Below is a non-comprehensive list of publicly available resources listing known vendors, applications and components that may be affected by this vulnerability.
- https://github.com/YfryTchsGD/Log4jAttackSurface
- https://github.com/authomize/log4j-log4shell-affected
- https://github.com/NCSC-NL/log4shell/tree/main/software
- https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
Any application which consumes untrusted user input and passes this to a vulnerable version of the Log4j logging library may be exploited.
How to identify?
It is essential for an organization to be able to identify if and where they might be affected by this vulnerability. Given the ubiquitous nature of the log4j library it might not be possible to identify all vulnerable instances in a short period of time.
Given the nature of the vulnerability, SureCloud would recommend to initially focusing on identifying any externally exposed product or service that might be affected by this vulnerability.
There are several ways to identify where log4j might be in use within in your environment and products. This can be performed via:
- Asset inventories
- Software build pipeline dependency manifests (e.g. Maven etc.)
- Vendor bulletins
- File system discovery:
- PowerShell: gci ‘C:\’ -rec -force -include *.jar -ea 0 | foreach {select-string “JndiLookup.class” $_} | select -exp Path
- PowerShell script: e.g., https://github.com/omrsafetyo/PowerShellSnippets/blob/master/Invoke-Log4ShellScan.ps1
- Linux command line: e.g., find / 2>/dev/null -regex “.*.jar” -type f | xargs -I{} grep JndiLookup.class “{}”
- Network scanners: e.g., Tenable Nessus, Qualys, SureCloud Platform, or custom scripts that have been made available such as https://gist.github.com/byt3bl33d3r/46661bc206d323e6770907d259e009b6
- Local scanners: e.g., https://github.com/hillu/local-log4j-vuln-scanner or https://github.com/mergebase/log4j-detector
- Nmap script: https://github.com/Diverto/nse-log4shell
- Online services: e.g., https://twitter.com/ThinkstCanary/status/1469439743905697797 or https://log4shell.huntress.com/
- Log file analytics
Please note, the external code/tools referenced above are not in-house SureCloud scripts (GitHub links) and are therefore subject to change. Therefore, organizations should exercise caution when running untrusted scripts and tools and perform a manual code review prior to use to ensure no malicious functionality has been added.
Detection
Given the vulnerability is being exploited in the wild, it is also important to verify if any affected system might have been compromised before a patch or workaround was applied.
It is recommended to begin searching for “jndi:ldap”, “jndi:dns”, IOCs in log files and audit logs. The security community has also produced a number of tools to help detect common exploitation attempts and obfuscation methods.
Please note that the SureCloud scanner will scan all known URL’s/endpoints for the Log4j vulnerability, but if a vulnerable endpoint exists that the scanner is not aware of, it will not be scanned and therefore may not be discovered. For clients with the ability to scan internally, a local authenticated scan will detect where the log4j application is present on the remote system to indicate where further investigation should be performed to assess whether it is utilized as part of the published web application.
Below is a list of useful tools and resources that can be helpful in identifying potential attacks:
- https://www.splunk.com/en_us/blog/security/log-jammin-log4j-2-rce.html (detecting log4j RCE using Splunk)
- https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
- https://github.com/Neo23x0/log4shell-detector (looking for many obfuscated combinations of potential exploitation attempts in logs)
- https://github.com/curated-intel/Log4Shell-IOCs (Big IOC collection)
- https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/Log4J_IPIOC_Dec112021.yaml
- https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b (YARA and other rules)
- https://www.elastic.co/blog/detecting-log4j2-with-elastic-security (detection using Elastic)
- https://blog.fox-it.com/2021/12/12/log4shell-reconnaissance-and-post-exploitation-network-detection/ (detection using Suricata)
- https://github.com/NCSC-NL/log4shell/tree/main/iocs (collection of Indication of Compromise IOC)
- https://github.com/NCSC-NL/log4shell/tree/main/mitigation (list of detection rules)
- https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/ (meta thread of content)
Based on Cloudflare observations, it is likely that exploitation in the wild was happening at least from 2021-12-01 04:36:50 UTC.
How to fix?
Install the latest updates as soon as practicable:
- If you are using the Log4j 2 library as a dependency within an application you have developed, ensure you update to version 2.16.0 or later.
- If you are using an affected third-party application, ensure you keep the product updated to the latest version.
For Log4j releases >= 2.10 this can be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true” or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to “true”.
For any version of Log4j version 2 removing the JndiLookup class from the classpath should also help mitigate the vulnerability.
Example command: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Need some assistance?
Our skilled and experienced cyber security team would be happy to offer advice and assistance should you require. Our Pentest-as-a-Service and Vulnerability Assessments and Scanning services can help you identify assets within your estate that may be affected by the Log4j vulnerability.
