Log4j zero-day vulnerability is flooding the security updates/news everywhere. This issue has been named Log4shell and assigned CVE-2021-44228 (still awaiting analysis at writing).
CVE-2021-45105 (infinite recursion in lookup evaluation) – third and latest flaw
Severity: High / 7.5
CVSS:AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Affected versions: All versions from 2.0-beta9 to 2.16.0
CVE-2021-45046 (Log4j2 Thread Context Lookup Pattern RCE) – second flaw
Severity: CRITICAL
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Affected versions: All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2
CVE-2021-44228 (original log4shell vulnerability)
Severity: CRITICAL
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Affected versions: All versions from 2.0-beta9 to 2.14.1
This is a developing story; you must refer to direct sources for any updates (Apache advisory page). From Minecraft to Internet’s big corporations serving applications we all use daily, a lot of them are vulnerable.
Why is this a big deal?
This Java logging library (Apache log4j) is found everywhere – from big corporations to SMBs. Log4j is heavily used within products/organisations, and therefore, the attack surface available is massive as of now. If you want to read about the related topics, then head to our popular posts: impacts of data breaches, types of malware, attack vectors to help you understand and assess your attack surface.
Updates since the original bug
There has been two more flaws since the original log4j vulnerability was discovered. Apache foundation has issued patches to fix this high severity log4j vulnerability.
- CVE-2021-45105 (Third flaw) – The latest version 2.17.0 is rolled out to address a security vulnerability in the logging library that could be used to launch denial-of-service (DoS) attack. This bug affects all versions from 2.0-beta9 to 2.16.0. You can read more about DoS and DDoS attacks here.
- CVE-2021-45046 (Second flaw) – This is a second bug that was discovered from flaws in ‘fix’ of original log4shell vulnerability. This flaw could result in remote code execution due to the incomplete fix in CVE-2021-44228 (log4shell). The severity for this issue (originally a DoS bug) has been revised from 3.7 to 9.0 as the attack impact includes information leak and remote code execution in some environments and local code execution.
What’s wrong with log4j?
This 0-day in java logging library log4j2 allows anyone to launch a RCE (remote code execution) by logging a particular string.
How do I find if I am vulnerable?
The best way to figure out this vulnerability in your environment is to get started immediately. You may need assistance from your technical teams to help you identify the vulnerable instances. There are also web pages created by vendors to identify the affected instances, however, the best way is for you to run the tests on your own.
Log4j vulnerability test
Log4j vulnerability test can be conducted in a number of ways based on the underlying operating system and the asset category.
A file system search inside JAR, WAR files using this command
find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null
You can search dependencies in use using this:
dpkg -l | grep log4j
The above search may return multiple results, which means all the copies require updating/fixing.
If you found these hashes in your inventory, then YES, your systems are vulnerable
https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
Search for the presence of jar files around this pattern “log4j-core-*.jar”.
On windows, this file could be located here:
c:Program Files\log4j-core-version.jar
On Linux, you can find the apps using this jar file
lsof //log4j-core-version.jar
You should look for the output of this command in /var/log
sudo egrep -i -r '${jndi:(ldap[s]?|rmi|dns):/[^n]+' /var/logGrep/zgrep commands and YARA rules to identify exploitation attempts are detailed here:
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
Use DNS logger (dnslog.cn or webhook.site or canary tokens) and use it in your test payloads. DNS queries shall help to identify which hosts have triggered the vulnerability.
You can use a point & click canarytoken from https://t.co/WCHU95kI8v to help test for the #log4j / #Log4Shell issue.
1) visit https://t.co/WCHU95kI8v;
2) choose the Log4shell token;
3) enter the email address you wish to be notified at;
4) copy/use the returned string… pic.twitter.com/c4iT8R4sOJ— Thinkst Canary (@ThinkstCanary) December 10, 2021
Log4rce, log4shell, log4j2, log4j are the popular hashtags to search further on this topic.
How to check which products are impacted?
you can check the attack surface list combined here:
https://github.com/YfryTchsGD/Log4jAttackSurface
Cisco security advisory log4j
To address log4j vulnerability in Cisco products and services, Cisco released snort rules available here:
https://www.snort.org/advisories/talos-rules-2021-12-21
None of the Cisco products is affected by vulnerabilities CVE-2021-45105 and CVE-2021-44832.
Later cisco released an advisory available here:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd
Ubiquiti log4j vulnerability
If you are using Ubiquiti products, see this official advisory:
Log4j vulnerability is fixed in UniFi Network Version 6.5.54 and later.
Impact/Containment
It is sensible to adopt an assume breach mentality and review logs as a first step to finding impacted applications for suspicious activities in your environment.
Minecraft has come up with a timely response to this issue already.
Player safety is the top priority for us. Unfortunately, earlier today we identified a security vulnerability in Minecraft: Java Edition.
The issue is patched, but please follow these steps to secure your game client and/or servers. Please RT to amplify.https://t.co/4Ji8nsvpHf
— Minecraft (@Minecraft) December 10, 2021
Log4j vulnerability exploiting demonstrating sensitive data leakage.
Mitigation – latest fix in log4j 2.17
Log4j v2.17.0 has fixed these identified issues. There have been about three patches released in a week to mitigate against the three discovered flaws. Workarounds are also available online.
Apache advisory
https://logging.apache.org/log4j/2.x/security.html
At network level:
- Block unexpected outbound connections (LDAP, LDAPS, RMI), however, exploits can use random ports also.
- Blocking URL strings containing “jndi:ldap” at WAF/application layer.
An excellent update by NCSC has been added here.
Anti-virus detections developed by Microsoft for Defender users on windows, linux include cryptocurrency miners, cobalt strike beacons, Tsunami backdoors, PowerShell and exploitation on the attacker machine. These details along with mitigation of log4j vulnerability by Microsoft Security Response Centre is detailed here:
https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
Useful links:
An excellent write up by Lunasec
https://www.lunasec.io/docs/blog/log4j-zero-day/
CISA emergency directive
https://www.cisa.gov/emergency-directive-22-02
Ycombinator – Log4j RCE found
https://news.ycombinator.com/item?id=29504755
Logging levels in log4j
A short lesson around logging levels in log4j. Log4j has three main components:
- Loggers – Capturing logging information
- Appenders – Publishing logging info to preferred destinations
- Layouts – Formatting logging info in different styles
All the logging levels in log4j are defined in the org.apache.log4j.level class.
The following log4j logging levels are listed along with their description:
- ALL – All levels including custom level logging
- DEBUG – granular informational events to help debug an application
- INFO – Informational messages
- WARN – As it says on the tin, warning messages or potentially harmful situations
- ERROR – Error events that still allow the app to continue running
- FATAL – Severe events that may not allow the application to function normally. An example would include running out of disk space, loss of network connectivity or missing configuration info if defaults cannot be used
- OFF – Turn off logging
- TRACE – Fine-grained informational event logging, more detailed than debug
These methods can be called as:
import org.apache.log4j.Logger;
public class LogClass {
private static org.apache.log4j.Logger log = Logger.getLogger(LogClass.class);
public static void main(String[] args) {
log.trace(“Trace”);
log.debug(“Debug”);
log.info(“Info”);
log.warn(“Warn”);
log.error(“Error”);
log.fatal(“Fatal”);
}
}
Security recommendations
These are general security recommendations to help you with ongoing improvements:
- Do not forget the least privilege principle implementation and segmentation at various levels (users, network, environments, etc) across your projects.
- Assess your attack surface regularly. Consider reducing your attack surface with system hardening and layered approach to cyber security.
- If you don’t have incident response processes in your organisation. Use this opportunity to have an incident response plan in place.
- Review your patch management and get it right. Don’t chase the never-ending cycle of 100% patching.
- Adopt regular penetration testing and vulnerability scanning practices for continuous validation of your security controls.
Credits
- A vulnerability has been credited to Chen Zhaojun of Alibaba.
- The official log4shell logo displayed above is from @GossiTheDog .
Log4j meme
This ‘log4j meme’ topic in itself deserves a separate section :). Obligatory memes found in online for log4shell are:
When our vendor says they’re safe because they’re using Log4J 1.X from ProgrammerHumor
Get in touch to discuss any security concerns for your business.
