Everyone has heard of Log4Shell vulnerability, which affects vulnerable Log4j versions and allows attackers to gain remote code execution (RCE) capabilities.
After working with our customers to mitigate the vulnerability in their networks we’d like to provide you with complete information and action items that will help you understand the situation and take the appropriate steps.
Although Log4Shell was discovered a week and a half ago, multiple related attacks still take place. Just a few days ago, the Belgian Defense Ministry office was attacked using Log4Shell. Multiple ransomware events targeting enterprises also used Log4Shell as the initial vulnerability that enabled attackers to breach perimeter defenses.
In addition, a few days after Log4Shell became public, additional vulnerabilities related to Log4j and the similar Logback library were discovered. All vulnerabilities were assigned with CVEs:
- Log4Shell – CVE-2021-44228 (CVSS score: 10.0) | A remote code execution vulnerability affecting Log4j versions from 2.0-beta9 to 2.14.1 (Fixed in version 2.15.0)
- CVE-2021-45046 (CVSS score: 9.0) | An information leak and remote code execution vulnerability affecting Log4j versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 (Fixed in version 2.16.0)
- CVE-2021-45105 (CVSS score: 7.5) | A denial-of-service vulnerability affecting Log4j versions from 2.0-beta9 to 2.16.0 (Fixed in version 2.17.0)
- CVE-2021-4104 (CVSS score: 8.1) | An untrusted deserialization flaw affecting Log4j version 1.2 (No fix available; Upgrade to version 2.17.1)
- CVE-2021-42550 (CVSS score: 6.6) | Malicious configuration leads to remote code execution vulnerability, affecting Logback version 1.2.7 and prior (fixed in version 1.2.9)
- CVE-2021-44832 (CVSS score: 6.6) | Malicious configuration leads to remote code execution vulnerability, affecting Node4j version 2.17 and prior (fixed in version 2.17.1)
7 steps to stay safe from Log4Shell attacks
CYE team shares the seven most important actions CISOs and security teams should take to keep their organizations safe.
1. Update software products
First and foremost, update all vulnerable software.
Updating lists of vulnerable software, versions, and current status can be found here and here.
All software using Log4j should be upgraded to use Log4j version 2.17.1 (for Java 8 and later), 2.12.4 (for Java 7), or 2.3.2 (for Java 6).
All software using Logback should be upgraded to use Logback version 1.2.9 or above.
2. Scan Java software files
Java packages (JAR, WAR, etc.) can be scanned and fixed using automated dedicated scanners.
CYE examined this scanner and its’ frequent updates and found it effective for discovering and fixing Log4Shell related vulnerabilities.
Note that upgrading Log4j and Logback to the latest versions is still the preferred mitigation.
3. Update inbound communication policy
Defensive products such as WAFs and in some cases IPS (Intrusion Prevention Systems) can protect web interfaces against Log4Shell. It is recommended to update all defensive products’ policies, and specifically WAFs’. WAFs policy and incoming HTTP traffic inspection products should search and block all requests that contain the following payloads:
- ${jndi:
- ${::-j}${
- %24%7bjndi:
- ${${lower:j
- $%7Bjndi:
- {${env:
- %2524%257Bjndi
- ${::-l}${
- %2F%252524%25257Bjndi%3A
- ${base64:JHtqbmRp
Please mind that these payloads are strict and should only be used if JNDI is never used.
Live testing and modifications (if needed) of these payloads should be made in order to prevent false positives.
These payloads can also be used for monitoring and for past log analysis, to detect past and current Log4Shell exploitation attempts.
4. Update outbound communication policy
Log4Shell is often detected using outbound DNS requests that interact with attacker-controlled DNS servers,
using out-of-band services. If these services are not used for legitimate purposes, the following domains can be blocked:
- interactsh.com
- interact.sh
- dnslog.cn
- burpcollaborator.net
- canarytokens.org
In addition, the most common exploitation techniques of Log4Shell are using several protocols: LDAP, LDAPS, RMI, CORBA and IIOP.
Therefore, if these protocols are not needed for regular usage (for example for Azure Active Directory which uses LDAP),
it is recommended to block these protocols in products that support stateful Inspection, and to block the following outgoing communication ports:
- 389, 1389 and 636 TCP (LDAP and LDAPS)
- 1099 TCP (RMI)
- 3702 UDP (CORBA)
- 900 TCP (IIOP)
5. Vulnerability scanning
Most known scanners, such as Nessus for example, can detect vulnerable servers.
If an internal scanner exists, it is recommended to initiate a thorough scan of internal and external assets
to detect vulnerable servers. In addition, free dedicated utilities can be found here.
CYE is using, among others, the recommended Nuclei vulnerability scanning utility:
alongside its Log4Shell template
6. Source code scanning
Vulnerable Log4Shell software as well as related vulnerabilities can be found using static source code analysis. Proprietary source code should be scanned using SAST (static application security testing)
utilities such as Checkmarx, Snyk, Github’s built-in scanner, and other SAST utilities. Free dedicated utilities can be found in the links above.
7. Web scanning
Different Java systems and software use Log4j in different ways. If a system logs an internal HTTP parameter value using a vulnerable log4j library, the system might be vulnerable.
Therefore, it is recommended to scan all software using DAST (dynamic application security testing) tools such as Acunetix, Netsparker, and other DAST utilities. The free OWASP ZAP DAST utility contains an experimental log4shell detection rule.
How can we help?
At CYE we believe that the best security decisions are driven by real-world data and business impact. We can help you scan your assets, both internal and internet-facing, in order to find servers that are vulnerable to the Log4Shell vulnerability and create a risk-based and effective mitigation plan.
Additional useful information and links
- Detailed explanations of the Log4shell vulnerability:
Lunasec Log4j Zero Day
Lunasec Log4j Zero Day Update on CVE-2021-45046
Google Blog on Apache Log4j - A detailed explanation about all Log4j and Logback vulnerabilities
- An app vulnerable to Log4Shell that can be used to test scanning utilities
- Actual Log4shell payloads captured in the wild
- Log4shell Cheat Sheet
