- Table of contents
The author
Highly motivated, problem solver, dot connector, energetic multi-dimensional & professional management with commercially oriented, customer service skills & PMO abilities in high-growth, fast-paced organizations.
Table of contents
Related Articles
Log4j Incident Update – Dramatic Turn of Events
Introduction
Following December 9th, 2021, the news of a Log4j Remote Code Execution (RCE) vulnerability began to grow (Figure 1). In addition to various malware families that already have utilized this vulnerability and added it to their delivery methods arsenal, more vulnerabilities related to this case were published, making Log4j, once simple Java-based logging utility, “the talk of the internet” these days.
In Cyberint’s last Research team blog post, CVE-2021-44228: Log4J2 Remote Code Execution, released last week, we discussed this vulnerability in detail. All these threats and more, which we will cover in this blog.
Quick Recap
If you were stuck on a desert island over the last week-or-so, without internet access, since this is talked about at pretty much any media out there, here is a quick recap of the initial vulnerability, describing two scenarios that a threat actor can use to run malicious code, or run a command, on a compromised server.
The most used method to deliver this vulnerability was via HTTP request, as the LDAP protocol payload is stored in any HTTP header in many variations.
While HTTP requests do typically not contain any LDAP requests within their headers (Figure 2), When it comes to this vulnerability, a threat actor will craft an HTTP request with the LDAP command stored in one of the requests headers (Figure 3).
As the first use-case is the most common, other use-cases have emerged, and commands can be sent to the vulnerable server without using the LDAP protocol, as shown in the example below (Figure 4).
What have we found so far?
Using Cyberint’s Research Team honeypots, we were able to find several ways in which threat actors were using to obfuscate payload within their HTTP requests.
The evasion techniques applied came in Base64 encoded payload (Figure 5), leading to malicious payload downloads such as Mirai Botnet (Figure 6).
We have also witnessed string manipulation Techniques (Figure 7) as part of WAF-avoidance attempts.
These WAF-avoidance techniques mentioned above will translate to the desired “{jndi:” string. While this has appeared in many different HTTP Headers, most used was User-Agent, Authorization header (Figure 8), and the HTTP path itself (Figure 9). Although the LDAP protocol is the most used in this context, we have also noticed DNS protocol use, but on a much smaller scale.
Malware Families
As predicted, in a matter of hours, malware families have already started using this vulnerability as part of their campaigns. While the first ones were Mirai and Muhstik, crypto miners, trojan and ransomware were not too late to join. Although these are merely a couple of examples and cases we have found, it is pretty evident that other malware families will join the trend of using sophisticated stealers, such as RedLineStealer or AgentTesla.
MIRAI & MUHSTIK
Mirai and Muhstik are both Linux-based malware targeting IoTs networks creating major botnets around the globe. While both Mirai and Muhstik are monetized via DDoS attack services, Muhstik was also observed deploying crypto miners in its campaigns.
XMRIG & KINSING
Other mining campaigns that we have witnessed rapidly after the publication of the CVE were XMRIG and Kinsing miners. Both are ELF malware targeting UNIX systems and are often being loaded via other malware abusing the new vulnerability.
Ransomware
It is no surprise that ransomware groups have already started weaponizing their campaigns and tools with exploits for this vulnerability. While some new families such as Khonsari have emerged and introduced into the industry, old school families such as Conti and TellYouThePass that have returned from some ‘time off’ have already exploited this vulnerability in several campaigns.
It is safe to assume that Lokbit, one of Conti’s main competitors, will also exploit this vulnerability to their campaign very soon as both compete for the most successful ransomware family this year.
Log4j CVE Updates
Since our last report about CVE-2021-44228 (dubbed ‘Log4Shell’), interest rose over the talked logging package.
A few days after the published patch (Log4j v2.15.0), we came to realize that this fix was ‘incomplete’ and can still be vulnerable and used in a limited Denial of service (dos) attack for both new patched version 2.15.0, and for older Log4j releases (after applying the configuration changes, ‘formatMsgNoLookups=True’).
Version 2.16.0 was released on December 13th to address the mentioned Dos vulnerabilities by completely disabling JNDI by default and removing message lookups.
On December 14th, the “new” Dos vulnerability was officially given a separate CVE (CVE-2021-45046) with a limited CVSS 3.7.
A few days later (Dec 17), Apache updated the severity of this vulnerability to 9.0, indicating it can be used to gain Remote Code Execution (RCE) under certain circumstances.
On that same day, a new update was released, Log4j v2.17.0, to patch a new CVE-2021-45105 that appeared in the patch published just a few days ago (Log4j 2.16.0), which researchers found out as not protecting from recursion within JNDI lookups. This CVE has a lower score and ‘only’ cause Denial of service (Dos) and may crash the running Java application.
While more vulnerabilities around Log4j start to rise, the first CVE-2021-44228 is the easiest to exploit and used in-the-wild. The other CVE’s mentioned above are yet to be seen in the wild, and we can assume that the likelihood of exploitation for these cases is lowered compared to CVE-2021-44228 (‘Log4Shell’) since these require non-default configurations of Log4j setup.
Recommendations
- It is highly recommended to our clients to read carefully the previous Research team blog post CVE-2021-44228: Log4J2 Remote Code Execution for a better understanding of the vulnerability itself, its impact, and further actions that are needed to be done.
- Version control remains the primary and most effective step for organizations to control the Log4j wildfire. While two more CVEs were discovered from the fixed versions, updating to 2.17.0 is the recommendation.
- Verifying IPS/IDS products used by the organization security protect this vulnerability.
- Mapping all services within the organizations that are JAVA-based might help mitigate and understand the weak leaks within the organization or product infrastructure.
