Warning : Active exploitation of a 0-day RCE in Log4j

Reference:
Advisory #2021-21

Version:
1.3

Affected software:
Log4J versions >= 2.0-beta9 & Log4J versions = 2.14.1
Mainstream software using Log4j as an utility

Type:
Remote Code Execution (RCE)

CVE/CVSS:
Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:HSeverity of the Risk: High
Information trustworthiness: High

Attack vector: Network
Attack complexity: Low
Privileges required: None
User Interaction: None
Impact: Confidentiality: High, Integrity: High, Availability: High

Sources

• NVD NIST
• Apache website

Risks

The objective of this alert is to raise awareness about a vulnerability in Log4j that is actively scanned and exploited by threat actors to compromise systems that are publicly connected to the internet.

Log4j is developed by the Apache Foundation and is widely used by both enterprise apps and cloud services. Successful exploitation could lead to a fully compromised environment.

The Centre for Cyber security Belgium recommends system administrators to patch vulnerable systems as soon as possible and to analyse system and network logs for any suspicious activity.

If you have already identified an intrusion or incident, please report it via: https://ccb.belgium.be/cert/report-incident

Description

The vulnerability, catalogued as CVE-2021-44228, is an unauthenticated Remote Code Execution (RCE) vulnerability in the widely used Log4j framework. This vulnerability also has an impact on default configurations of multiple Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, Apache Flink, etc.

Furthermore, other mainstream organisations confirmed that their software is vulnerable to the Log4j vulnerability: Apple, Amazon, Twitter, Steam, Baidu, NetEase, Tencent, Elastic, etc.

Update 15-12-2021

The fix to address CVE-2021-44228 in Apache log4j 2.15.0 is incomplete in specific non-default configurations, allowing attackers to craft malicious input data using a JNDI Lookup pattern that could result in a DoS attack.
The description of the new vulnerability in Apache Log4j (CVE-2021-4506) can be found under NVD summary.

- NVD: https://nvd.nist.gov/vuln/detail/CVE-2021-45046

Update 20-12-2021

The CCB urges organisations to update Log4j version to version 2.17.0 or later.

The CCB wants to emphasize on:

1. The current massive exploitation of these vulnerabilities by threat actors in external network environments on a global scale.
2. The prevalence of the affected software in the private & public sector possibly impacts all industry verticals.
3. The risk of a potential compromise is high, the potential impact of a successful compromise is critical.   

Recommended Actions

1)Scope

Vulnerable software: All Log4j versions from 2.0 up to and including 2.14.1

Create an inventory that includes all the software from your organisation and check per entry if Log4j
is implemented.

Please note that this vulnerability may also occur in custom developed software within your organisation, and software suites from mainstream vendors such as Apache, Atlassian, Amazon, Cisco, Elastic, Fortinet, Oracle, Splunk, VMware.

Please consult the following GitHub page maintained by NCSC-NL for a more comprehensive list of possible impacted software vendors.

• NCSC-NL: https://github.com/NCSC-NL/log4shell/blob/main/software/README.md

Update 15-12-2021

NCSC-UK disclosed a technique to discover unknown instances of Log4j within your organisation.
A file system search for log4j can be undertaken. This should include searching inside EAR, JAR and WAR files. For example:

find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null

If a dependency or package manager is used:

dpkg -l | grep log4j

Remark: There could be multiple copies of Log4j present, each copy will need to be updated or mitigated.

- NCSC-UK: https://www.ncsc.gov.uk/news/apache-log4j-vulnerability

2)Mitigate

Update 20-12-2021

The mitigation method formatMsgNoLookups=True flag is ineffective at stopping certain attacks.

Organisations must update to 2.17.0 or use the JNDI patches for temporary mitigation.

If you are using a version older than 2.10.0 and cannot upgrade, your temporary mitigation choice is:

Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application's or stack's classloading documentation to understand this behavior.

3)Patch

Update 20-12-2021

To prevent the library from being exploited, it's urgently recommended that Log4j versions are upgraded to Log4j 2.12.2 for Java 7 and 2.17.0 for Java 8 and up.

- Java 8 V2.17.0: https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.17.0
- Java 7 V2.12.2: https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.12.2

Please consult the following GitHub page maintained by NCSC-NL for a more comprehensive list of possible impacted software vendors and specific information regarding which version contains the security fixes, and which software still requires mitigation.

•  NCSC-NL: https://github.com/NCSC-NL/log4shell/blob/main/software/README.md

4)Monitor/Detect

The CCB advises organisations to upscale monitoring and detection capabilities, to detect any related suspicious activity, ensuring a fast response in case of an intrusion.
Organisations can identify if they're targeted by examining the log files for any services using affected Log4j versions.
The recommended date to start your investigation is from December, 1st 2021. There are detection rules available that could detect a possible intrusion attempt:

General detection regex

\${(\${(.*?:.*?:.*?:-)('"`)*(?1)}*[jndi:lapsrm]('"`)*}*){9,11}

Network-based detection

• Diverto Nmap NSE scripts to check against log4shell: https://github.com/Diverto/nse-log4shell
• NCC Group Log4Shell: Reconnaissance and post exploitation network detection: https://research.nccgroup.com/2021/12/12/log4shell-reconnaissance-and-post-exploitation- network-detection/

Snort and Suricata rules

These are ET Open free community detections to alert on current exploit activity.

• SID range 2034647-2034652: https://rules.emergingthreatspro.com/open/

Host based detection

• Florian Roth Grep/YARA rule for Log4j2 exploitation: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
• Florian Roth Log4j2 detection script: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
• Florian Roth Sigma rule to detect an exploitation attempt against Log4j RCE vulnerability fields: https://github.com/SigmaHQ/sigma/blob/master/rules/web/web_cve_2021_44228_log4j_fields.yml
• Florian Roth Sigma rule to Detect an exploitation attempt against Log4j RCE vulnerability: https://github.com/SigmaHQ/sigma/blob/master/rules/web/web_cve_2021_44228_log4j.yml
• Powershell script to detect Log4Shell: https://github.com/sp4ir/incidentresponse/blob/35a2faae8512884bcd753f0de3fa1adc6ec326ed/Get-Log4shellVuln.ps1
• Powershell script to perform a scan to see if it's vulnerable: https://github.com/crypt0jan/log4j-powershell-checker
• NCCgroup Version hashes (MD5, SHA1 and SHA256) for Log4j2 versions: https://github.com/nccgroup/Cyber-Defence/tree/master/Intelligence/CVE-2021-44228
• Huntress Online Log4Shell Vulnerability Tester: https://log4shell.huntress.com/

References

https://www.lunasec.io/docs/blog/log4j-zero-day/

https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/