The Log4Shell zero day vulnerability is truly one of the most significant security threats of the past decade and its effects will be felt far into 2022 and beyond. Imperva has observed over 102M exploitation attempts across thousands of sites protected by Imperva Cloud Web Application Firewall (WAF). In the days following, the team at Imperva also responded to the additional Log4j-related vulnerabilities disclosed following the initial zero day publication, to ensure the best possible protection for our customers.
There is a wealth of resources readily available online that explain what each Log4j vulnerability is and how the exploits work [1][2]. In this blog, we will demonstrate some of the interesting attack patterns, payloads, bypass techniques, and data points we have observed during our analysis of the recent Log4j related vulnerabilities. The data presented throughout this blog post is sourced from analyzing Imperva’s global network traffic and publicly-available external sources, including social media.
Imperva response to Log4shell
Although Imperva’s generic security rules provided protection against exploitation attempts, a few hours after the proof of concept (PoC) was published on December 9, Imperva security analysts deployed a dedicated mitigation and issued a manual mitigation guide for Imperva Web Application Firewall (WAF) customers.
Exploitation attempts
Imperva has blocked over 102M attack attempts since the disclosure on December 9. The following graphs illustrate how the attacks have developed.
Exploit attempts over time
The following graph shows the volume of exploit attempts against sites onboarded to Imperva Cloud WAF since the disclosure of the vulnerability. Imperva observed almost 1.3M exploit attempts per hour within the first 10 days of the exploit becoming public. Since the peak on December 23, we have observed a general declining trend in the number of exploit attempts.
Sites attacked over time
In addition to the astounding rate of exploit attempts, the number of sites targeted was also remarkable, reaching a peak of 25K sites attacked per hour. This can be explained by the preponderance of Java-based web applications and how ubiquitous the Log4j package is across these applications. Attackers appear to be using “spray and pray” and fuzzing techniques to identify vulnerable applications.
Attacked industries
The following chart shows the breakdown of exploitation sessions by industry. At the time of writing the most commonly targeted industries are Financial Services (29.6%), Food and Beverages (12.4%) and Computing and IT (10.4%). As we mentioned previously, attackers largely used a “spray and pray” approach to the exploitation of this vulnerability, and we did not detect a strong correlation between the top sites attacked in each category and their technology stack, however, the correlation becomes more observable when considering only malicious remote code execution (RCE) payloads which appear to be more targeted.
Attacking web clients
Imperva observed attacks from over 100 different types of web clients. The most prevalent of these clients we observed was the Go HTTP library, with over 10M requests and counting.
The combination of the volume of the attacks and the distribution of web clients suggests that attacks were quickly automated and that attack tools were created to make it easier for attackers to reach as many targets as possible.
Attacked countries
Imperva observed attacks targeting sites in over 160 different countries, with the most common target observed being the US with 46.5% of all exploit attempts.
Top attacking IP addresses
As mentioned previously, we have observed that many attackers are using “spray and pray” techniques to identify vulnerable applications. The following chart shows the IPs which attacked most sites since the disclosure. All of these IPs were observed sending malicious requests to thousands of sites.
We created a dynamic feed with over 10,000 IPs that are actively attempting to exploit Log4j vulnerabilities. The feed is being updated on a daily basis.
Top fuzzing IPs
Through our analysis, we observed that many IPs were using a common technique known as “fuzzing” to identify vulnerable Java web applications. This technique involved using a simple payload to send a DNS query containing the victim domain name to a server controlled by the attacker (see Payload analysis – probing section). Essentially, the attacker injects the payload into many different parameters and headers in HTTP requests to the target, hoping to find one which is logged by the vulnerable version of Log4j and trigger a DNS query. The following graph shows the top fuzzing IPs, along with the number of unique header and parameter names observed from each.
Payload analysis
We witnessed many different payloads used in the exploitation of Log4Shell. We divided the payloads into the following categories:
- Probing
- Reverse shells
- Malware deployments
- Data exfiltration
- Patching
Probing
Attackers will often probe the application before sending the actual payload and will use one of the services below, to check if the application is vulnerable. If an attacker receives a DNS query in one of the services listed below, it means that the application is vulnerable.
- interactsh.com
- dnslog.cn
- burpcollaborator.net
- ns1.distryp.com
- bipcyberdef.tk
- 1ma.xyz
- service.exfil.site
- [163].[172].[94].[82]:1234
- [134].[209].[26].[39]:4000
- [45].[66].[8].[12]:1378
- [45].[66].[8].[12]:1366
Example of probing exploits:
Reverse shell
This payload will open a communication channel between the vulnerable application and the hacker. After the hacker receives the communication, he can further explore the target system and remotely run any shell commands.
Malware deployment
Kinsing malware – RAT & Cryptominer
A malware used for crypto mining to mine Monero and a Remote Administration Tool (RAT) written in the Golang programming language.
SHA256: 6e25ad03103a1a972b78c642bac09060fa79c460011dc5748cbb433cc459938b
Decoded payload:
StealthLoader malware
A multi-stage malware that installs an XMRig cryptocurrency miner to mine Monero.
SHA256: 457b254439cdbbc167b45abc09d9531b59ac7b104e847e453e5abd016991a6e2
Powershell with instructions where to download the malware
Download and execute the malware
Mettle – Metasploit advanced backdoor
This is an implementation of a native-code Meterpreter, designed for portability, embeddability, and low resource utilization. It can run on the smallest embedded Linux targets to big iron, and targets Android, iOS, macOS, Linux, and Windows, but can be ported to almost any POSIX-compliant environment.
SHA256: 378d892c616805fbddb3d39584035b303192ddbc2a7e43e966319bb41ce6861f
Decoded payload:
Ganiw botnet – DDoS bot
Versatile DDoS trojan that targets Linux OS. It can perform multiple types of DDoS attacks including SYN Flood, DNS Amplification, UDP Flood, and more.
SHA256: a4b278170b0cb798ec930938b5bd45bbf12370a1ccb31a2bee6b2c406d881df6
Decoded payload (first time):
Decoded payload (second time):
Data exfiltration
AWS keys
An example of exfiltration of AWS keys that are stored in environment variables and sent to a DNS server.
The attacker can also append the victim’s website to the domain. This allows them to match the extracted keys to the victim
Docker information
Exfiltrating Docker and Kubernetes information
Patching
Another interesting payload, and a non-standard way to patch a vulnerable system, is a Java code that changes the configuration and disallows lookups. In other words, you can patch Log4shell vulnerability with Log4shell payload.
Bypass techniques
Generally speaking, remote code execution is considered the most severe category of vulnerability. CVE-2021-44228 was assigned the maximum severity score possible (CVSS score of 10.0) largely because of how easy it is to exploit. As is shown below, remote execution can be achieved on the target with a simple string payload in the form of a JNDI lookup:
The payload begins with a ‘${jndi:’ followed by the protocol implementation chosen to carry out the attack, and the Uniform Resource Identifier (URI) to the attacker controlled server hosting the malicious code.
To evade detection attackers began obfuscating the payloads using nested lookups such as “lower”, “upper” and “date” within the payload. This approach bypasses any mitigation that relies on detecting only the $jndi: string within HTTP requests:
This evasion method also allowed for the use of multiple sets of single quotes surrounding the “JNDI”characters:
This notation could be used in several different ways to obfuscate the payload and potentially bypass detection
Another bypass technique involving these lookups involved the use of some obscure behavior observed in Java. When the “upper” lookup keyword was used with dotless i (ı) character, it is converted to a regular i, therefore making the payload valid
Attackers could also use what is known as “default value syntax” (allows a default value in a lookup denoted by a dash) to obfuscate the payload further, this meant that so long as a nested lookup within the payload contained a colon and dash character within it: ${:-}, any character could be used within the lookup, this manifested itself in many ways:
In some instances attackers even used special characters, quotes, spaces and tabs in payloads:
Attackers could also use multiple nested lookups of various types to further obfuscate and evade detection:
In some instances Imperva also observed payloads which omitted the trailing curly brace from the payload which is required for the lookup syntax to be valid, research and experimentation showed that in some instances exploitation was still possible if a closing brace was being logged elsewhere in the same HTTP request, for example in an additional HTTP parameter/header.
Social media is on fire
When you drop a zero-day vulnerability on social media, it spreads like wildfire. Twitter mentions of key terms relating to the exploit skyrocketed – we monitored several Log4j-related keywords over the first week of the incident – the term “Log4j” had just two mentions on December 8, followed by a few more on December 9. Then suddenly, there were thousands of mentions starting on December 10. Even as we start the New Year, there are thousands of tweets about Log4j on a daily basis.
To put the level of interest in this specific CVE into context, we charted mentions of ‘CVE-2021-44228’ over its first five days of existence and compared that volume of conversation to the number of tweets mentioning other exploits over their first five days of existence. Nothing came close to the level of interest and conversation that Log4shell generated at its peak.
There is no doubt that CVE-2021-44228 is the most critical vulnerability uncovered in 2021.
Conclusion
What this means for the future
The Log4shell-related CVEs are the most significant and impactful vulnerabilities of 2021. The ubiquitous nature of Log4j means that the impact of this will be felt well into 2022 and beyond, by almost everyone who uses services on the internet. The Log4j logging services framework is utilized almost ubiquitously in Java applications, therefore organizations are currently scrambling to identify all the vulnerable Java applications within their network, and will continue to do so for the foreseeable future.
We predict that a tidal wave of breaches will be reported in the next year stemming from this vulnerability and will impact organizations of all sizes. We also predict a sharp increase in ransomware attacks and exploitative crypto mining activity. Botnets will use this vulnerability to expand, hence the volume of application and network DDoS attacks will increase.
Due to the exploit ambiguity, we highly recommend that Imperva customers upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later) and continue to be on the lookout for further patches for where new exploits are identified. We also recommend that customers evaluate Imperva RASP to protect against zero day exploits. Imperva RASP is complementary to Imperva WAF. While the latter keeps bad traffic out, RASP mitigates the risk posed by unknown exploits in first or third-party code/dependencies. By being embedded in the application, RASP has direct visibility into attacks relating to a RCE, which is an advantage for detecting and stopping a specific class of attack. Learn more about Imperva RASP here. If you’re looking for protection from the Log4j-affiliated CVEs, please contact us.
Try Imperva for Free
Protect your business for 30 days on Imperva.
