Background
Apache Log4j2 is a ubiquitous library used by millions for Java applications; the library is part of the Apache Software Foundation’s Apache Logging Services project. The vulnerability CVE-2021-44228, disclosed on December 9, 2021, allows for remote code execution against users with certain standard configurations in prior versions of Log4j 2 as of Log4j 2.0.15. Since the release of 0-day vulnerability (CVE-2021-44228) in Apache Log4j 2, and its public exploit on GitHub, it has taken the security teams by storm. This vulnerability is actively being exploited in the wild.
Many devices identified being affected by it (Apple, Vmware v sphere, logrythm, and elastic to name a few). In addition to this, security researchers all over the world are finding more and more ways to bypass the detection techniques and to successfully exploit this weakness in the Log4j library.
The default configuration of Apache Log4j supports JNDI (Java Naming and Directory Interface) lookups that can execute arbitrary code provided by remote services such as LDAP, RMI, and DNS.
What is Log4j?
Log4j is one of the many building blocks that are used in the creation of modern software. It is used by many organizations to do a common but vital job. This is called a ‘software library’.
Log4j is used by developers to keep track of what happens in their software applications or online services. It’s basically a huge journal of the activity of a system or application. This activity is called ‘logging’ and it’s used by developers to keep an eye out for problems for users.
Threat Overview:
Last week, a vulnerability was found in Log4j, an open-source logging library commonly used by apps and services across the internet. A remote, unauthenticated attacker with the ability to log specially crafted messages can cause Log4j to connect to a service controlled by the attacker to download and execute arbitrary code.
If left unfixed, attackers can break into systems, steal passwords and logins, extract data, and infect networks with malicious software.
Log4j is used worldwide across software applications and online services, and the vulnerability requires very little expertise to exploit. This makes Log4shell potentially the most severe computer vulnerability in years.
Impacted Versions:
2.0 <= Apache log4j <= 2.15.0-rc1
Log4j 1.x
Log4j 1.x mitigation: Log4j 1.x does not have Lookups so the risk is lower. Applications using Log4j 1.x are only vulnerable to this attack when they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability.
To mitigate: audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability.
log4j-core
Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
Associated CVEs and CVSS
| CVE ID | Vulnerability Type(s) | Publish Date | Update Date | Score | Access | Complexity | Authentication | Conf. | Integ. | Avail. |
|---|---|---|---|---|---|---|---|---|---|---|
| CVE-2021-45105 | DoS | 18-12-21 | 22-12-21 | 5 | Remote | Low | Not required | None | None | Partial |
| CVE-2021-45046 | Exec Code +Info | 14-12-21 | 22-12-21 | 5.1 | Remote | High | Not required | Partial | Partial | Partial |
| CVE-2021-44228 | Exec Code | 10-12-21 | 20-12-21 | 9.3 | Remote | Medium | Not required | Complete | Complete | Complete |
| CVE-2021-4104 | Exec Code | 14-12-21 | 21-12-21 | 6.8 | Remote | Medium | Not required | Partial | Partial | Partial |
Overview of Found Vulnerabilities and Updates:
Latest Update on Log4j CVEs :
On 18-Dec-2021, Apache Software Foundation provided another update to log4j (version 2.17.0) to address a new CVE-2021-45105. Contrast recommends using this most secure version.
The latest 2.17.0 update is the latest, fixing the results.
- Log4j 2.16.0 is vulnerable to CVE-2021-45105, from December 16.
- Log4j 2.15.0 is vulnerable to CVE-2021-45046, from December 14.
- Log4j 2.14 and below are CVE-20210-44228(log4shell), from December 9.
List of Vulnerable Softwares
The Log4j library is frequently used in software and the links below provide a non-exhaustive lists of vulnerable products:
- Github – CISA Log4j vulnerability guidance
- Github – NCSC-NL Log4j overview related software
- Mvnrepository – Artifacts using Apache Log4j Core
Action Plan
In Log4j 2.12.2 (for Java 7) and 2.16.0 (for Java 8 or later) the message lookups feature has been completely removed. In addition, JNDI is disabled by default and other default configuration settings are modified to mitigate CVE-2021-44228 and CVE-2021-45046.
For Log4j 1, remove the JMSAppender class or do not configure it. Log4j 1 is not supported and likely contains unfixed bugs and vulnerabilities such as CVE-2019-17571.
- To know if you are vulnerable to it or not?
The first step in your action plan is to identify how many of your assets are vulnerable to it, since you can only patch the devices/tools/software which you know are affected. Since the release of this vulnerability, different vendors have been working tirelessly to help their customers, to identify all the assets that are affected by it. Urgently conduct internal and external VAPT on all assets to detect Log4j vulnerabilities.
- Discover unknown instances of Log4j within your organization
To support the first priority action above, you also should now determine if Log4j is installed elsewhere. Java applications can include all the dependent libraries within their installation.
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, this can be searched. For example:
dpkg -l | grep log4j
There could be multiple copies of Log4j present, each copy will need to be updated or mitigated.
On Windows, this PowerShell command can identify nested Log4j:
gci ‘C:\’ -rec -force -include *.jar -ea 0 | foreach {select-string “JndiLookup.class” $_} | select -exp Path
- Pre-exploit detection:
a. Detect querying your log store or data lake
– To detect exploit attempts of this vulnerability in your environment your query should search for jndi commands such as ${jndi:*}
– Streamline the process of an investigation by running this query and remember Dec 9, 2021 was the first date this was reported
b. Detect by adding a correlation rule in SIEM
– Operationalize the query above as a correlation rule
– If your SIEM allows it, run the query in real time
c. Detect using known IOCs in your SIEM
– Download the list maintained by GreyNoise Intelligence.
– Leverage this in your Data Lake/store and get a list of successful and failed attempts by these indicators
- How to protect against this vulnerability?
a. The last step of your action plan after detecting vulnerable devices and exploit attempts is to make sure that patches are applied. There are two solutions for this, if for some reason, you can not apply the permanent solution, you can apply the temporary solution to ensure you are safe.
b. The permanent solution is to patch the library to the latest version published by Apache,
– Java 8 (or later) users should upgrade to latest release. At present latest release is 2.17.0.
– Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
– Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
If you don’t know if anything we use is using Log4j?
- Ask your in-house developers and/or third-party suppliers. Developers of affected software have been asked to communicate promptly with their customers to enable them to apply available mitigations or install updates. In turn, you should act promptly on any such communications from developers.
- In addition to this, please keep a track of the advisories shared by different vendors (such as VMware v-sphere, elastic, Paloalto, etc) regarding their components affected by this vulnerability and make sure that all the patches/signatures/rules are applied in a timely manner.
- Please make sure to constantly look/hunt for the signs of compromise in the devices affected by this vulnerability (Especially if you have SOC services).
What else you can do?
- Perform Internal and External VAPT to check your systems for the use of Log4j
- Check the list of vulnerable software
- Contact software vendors
- Set Web Application Firewall (WAF) rules
- Check for scanning activity
- Check for exploitation