The gravest cyber threat of modern times is upon us in the form of CVE-2021-44228. Here are some key resources:
In order to quickly find and prioritize how at risk you are of a Log4j 2 exploit, you can focus on enumerating the virtual machines and pods which are directly and indirectly exposed to the internet. We used ThreatMapper to detect our own exposure caused by Elasticsearch (which has since been fixed) as follows. Dogfooding much!
If you’re not yet familiar with ThreatMapper, it is a 100% open source cloud native security observability platform that hunts for vulnerabilities in your production platforms, and ranks these vulnerabilities based on their risk-of-exploit at runtime. This means that you can then prioritize and fix the issues that present the greatest risk to the security of your applications. You can find everything you need to get started with ThreatMapper on GitHub.
Continuing with our Log4j2 example where we used ThreatMapper to detect our own exposure, you can clearly see a virtual machine named deepfence-log4j-poc is exposed to the internet and the Log4j2 vulnerability is listed as a top attack vector. This is our most critical issue to fix right now because of its proven risk of exploit.
The node deepfence-log4j-poc was scanned for vulnerabilities and has 3 exploitable vulnerabilities, top amongst them is log4j vulnerability. Looking deeper at the most exploitable vulnerability report, we can see the attack paths, attack vector and port details.
(Note: There could be other virtual machines that have the vulnerability but are not directly or indirectly connected to the internet. This means that their risk of exploitation is lower and, therefore, don’t need our most immediate attention.)
Digging deeper into your critical vulnerabilities and attack paths, you can prioritize fixing your exposure by looking at the nodes which are actively connected to the internet and seal off the connections or deploy continuous traffic filtering on these attack paths.
Essentially you can narrow down from potentially hundreds of nodes to be patched to a handful which might be one or two hops away from the internet and need fixing immediately. It is much easier to find directly internet facing vulnerable services looking at VPC and security groups, but much harder to find vulnerable services that are further downstream, behind proxies and getting potentially malicious traffic indirectly. Log4j vulnerabilities in these deeply downstream services are equally exploitable and catastrophic. ThreatMapper precisely helps find all these hidden attack paths by continuously correlating vulnerabilities with network traffic.
And here are the CVE details:
The industry reacted to the Log4j2 issue promptly. Rules and signatures have been released by WAF, CDN, IPS, and Public Cloud vendors, it is a broader consensus across the industry that these rules and signatures can block simpler known variants of the payloads coming via HTTP but can be easily bypassed (some WAF evasion payloads here). It is recommended to deploy the WAF/IPS rules as it will provide the necessary time to do a Log4j upgrade.
Log4j2 vulnerabilities continue to evolve. On December 18 2021, this mitigation tip was published by The Hacker News regarding a new local attack vector:
"While the issue can be resolved by updating all local development and internet-facing environments to Log4j 2.16.0, Apache on Friday rolled out version 2.17.0, which remediates a denial-of-service (DoS) vulnerability tracked as CVE-2021-45105 (CVSS score: 7.5), making it the third Log 4j2 flaw to come to light after CVE-2021-45046 and CVE-2021-44228."
Specifically related to CVE-2021-44228, the Apache Software Foundation recently reported:
"It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability.
Mitigation
Log4j 1.x mitigation: Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation: Implement one of the mitigation techniques below.
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."
The Log4j2 vulnerability is very serious and the internet is under attack right now. To protect yourself, one thing you can do is to install and use open source ThreatMapper to quickly find and prioritize how at risk you are of a Log4j2 exploit in your environment, so you can focus on enumerating the resources which are directly and indirectly exposed to the internet, and therefore present the greatest risk to your applications and services, and fix them first.
Here are some helpful resources to get you started with ThreatMapper:
Here are some additional resources we have found to be super helpful:
.png)