Attending InfoSec?

Log4j Incident Update – Dramatic Turn of Events

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.

 

Watch on-demand webinar: Log4Shell Explained

 

Figure 1: Log4j related topics and items found on Telegram channels, the dark web and other resources pre and after the publication
Figure 1: Log4j related topics and items found on Telegram channels, the dark web and other resources pre and after the publication

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).

Figure 2: Normal HTTP request to a web-server
Figure 2: Normal HTTP request to a web-server
Figure 3: A malicious payload gets executed on the vulnerable server. These can vary from Malware infection, Reverse-shell, Open a backdoor, Crypto miners, and more.
Figure 3: A malicious payload gets executed on the vulnerable server. These can vary from Malware infection, Reverse-shell, Open a backdoor, Crypto miners, and more.

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).

Figure 4: example of fetching AWS credentials using a crafted HTTP request
Figure 4: example of fetching AWS credentials using a crafted HTTP request

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).

Figure 5: Obfuscated Base64 payload within the User-Agent header
Figure 6: Decoded payload into ‘wget’ request downloading Mirai payload
Figure 6: Decoded payload into ‘wget’ request downloading Mirai payload

We have also witnessed string manipulation Techniques (Figure 7) as part of WAF-avoidance attempts.

Figure 7: WAF-avoidance techniques applied in User-Agent header
Figure 7: WAF-avoidance techniques applied in User-Agent header

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.

Figure 8: Exploitation attempt spraying both User-Agent and Authorization headers
Figure 8: Exploitation attempt spraying both User-Agent and Authorization headers
Figure 9: Exploitation attempt within the URL
Figure 9: Exploitation attempt within the URL

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.

 

Have any questions left unanswered?
Contact us!

 

Uncover your compromised credentials from the deep and dark web

Fill in your business email to start