Log4Shell is the worst security issue of the decade: what you should do
Last week, we discussed the Log4Shell and other Log4j-related vulnerabilities, implications, and recommended mitigation actions. I see that the Log4Shell vulnerability, which has transformed into multiple vulnerabilities, is going to stay with us for a while. Just yesterday, December 28th, yet another remote code execution vulnerability was discovered again in all Log4j versions, with a new fix now available in v2.17.1.
So, here is an update of what we know so far, with the latest information.
Log4shell summary overview
December 10, 2021 – The original Log4Shell vulnerability was disclosed under CVE-2021-44228 with the possibility for an attacker to execute injected code using the message lookup functionality. Affected versions were Log4j v2.0-2.14.1.
December 13, 2021 – The second vulnerability disclosed under CVE-2021-45046 could allow attackers to craft malicious input data that could cause an information leak, remote code execution, and denial-of-service (DoS).
December 16, 2021 – The third vulnerability disclosed under CVE-2021-45105 could allow an attacker to initiate a denial-of-service (DoS) attack by causing an infinite recursion loop on self-referential lookups.
December 28, 2021 – The fourth vulnerability disclosed under CVE-2021-44832 could allow an attacker with permission to modify the logging configuration file to construct a malicious configuration using a JDBC Appended with a data source referencing a JNDI URI that can execute remote code.
What should you do?
Identify – Identifying assets affected by Log4Shell and other Log4j-related vulnerabilities.
Patch – Upgrading Log4j assets and affected products to the latest available version.
Hunt – Initiating hunt and incident response procedures to detect possible Log4Shell exploitation.
Log4j scanner to find vulnerable apps
On December 21st, the Cybersecurity and Infrastructure Security Agency (CISA) announced the release of a scanner for identifying web services impacted by two Apache Log4j remote code execution vulnerabilities, tracked as CVE-2021-44228 and CVE-2021-45046.
According to the agency, “log4j-scanner is a project derived from other members of the open-source community by CISA’s Rapid Action Force team to help organizations identify potentially vulnerable web services affected by the log4j vulnerabilities.”
It’s highly recommended to use the scanning tool to identify services affected by Log4j vulnerabilities and to patch them to the latest Log4j version, which is 2.17.1.
Other mitigation recommendations you can consider when updating Log4j isn’t an option:
- Deploy detection and prevention, Web Application Firewall (WAF) and Intrusion Prevention Systems (IPS) rules. While threat actors will be able to bypass this mitigation, the reduction in alerting will allow the organizational Security Operations Center (SOC) to focus on a smaller set of alerts.
- Reducing the attack surface by blocking the standard ports for LDAP, LDAPS, and RMI (389, 636, 1099, 1389). Although this isn’t bulletproof, as the ports can be randomized, this can still reduce the attack surface.
- Disable the Log4j library. Disabling software using the Log4j library is an effective measure, favoring controlled downtime over adversary-caused issues. This option, however, could have operational impacts and limit visibility into other issues.
- Disable JNDI lookups or disable remote codebases. This option, while effective, may involve developer work and could impact functionality.
- Disconnect affected stacks. Solution stacks not connected to the organizational networks pose a dramatically lower risk from attack. Consider temporarily disconnecting the stack from networks, if possible.
- Isolate the system. Create a “vulnerable network” VLAN and segment the solution stack from the rest of the enterprise network.
Source: https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/
The Allot Traffic Intelligence solution can provide detection and prevention of Log4Shell attacks attempts over HTTP. Note that the attack can be executed over different protocols and services, such as LDAP, DNS, RMI, and CORBA, so it’s highly recommended to implement detection and prevention rules in the IPS and WAF security systems, as well.
A signature that detects such attacks is already available within Allot’s protocol pack ERT-PP 3.153.90, as well as the official protocol pack 3.154. With the new signature, Allot provides one detection marked as “Log4j RCE vulnerability” with a high confidence level on the Log4j attack pattern. It is recommended to set up a policy to block such traffic. Additionally, there is another signature (with low confidence) marked as “Log4j RCE vulnerability II,” which can be used for detections only, with further analysis to be done by SOC teams.
For Allot customers with a deployed ClearSee analytics system, you can easily create a report that will show attempts to exploit Log4Shell. More information on how to create the report is available here.
Last week, I saw a nice anecdote about Log4j. China’s internet regulator, the Ministry of Industry and Information Technology (MIIT), suspended a partnership with Alibaba Cloud, the cloud computing subsidiary of e-commerce giant Alibaba Group, for six months on account of the fact that it failed to promptly inform the government about a critical security vulnerability affecting the broadly used Log4j logging library.
Chinese companies are obliged to report their own software vulnerabilities to the MIIT through its National Vulnerability Database website, according to a new regulation passed this year. However, the Internet Product Security Loophole Management Regulation, which went into effect in September, only “encourages” companies to report bugs found in other’s software.
More information can be found here and, as always, you can contact us to continue the conversation.
