Log4shell summary overview
“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. Is log4shell really the worst security issue of the decade?
So, here is the latest update of what we know so far, at the time of writing, with the latest information.
Is Log4Shell the worst security issue in decades?
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 can you do against the Log4shell vulnerability?
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 Log4Shell 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/
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.
I've had an avid interest in Computers, Technology and Security since my early teens. 20 years on, and, it's a whole lot more complicated...
I've assisted Governments, Individuals and Organizations throughout the world. Including; US DOJ, NHS UK, GOV UK.
I'll often reblog infosec-related articles that I find interesting. On the RiSec website, You'll also find a variety of write-ups, tutorials and much more!
- WH Smith Announces Cyber-Attack: Employee Data Stolen - 2 March 2023
- What distinguishes Application Security from API Security? - 28 February 2023
- The Top 5 Cybersecurity threats facing Businesses Today - 28 February 2023
3 thoughts on “Is Log4Shell the worst security issue of the decade?”