SBN

Log4j: One Year Later

One year ago, the Log4j remote code execution vulnerability known as Log4Shell (CVE-2021-44228) was announced. The critical severity level vulnerability in a logging framework used across virtually all Java environments quickly set the internet on fire when it was released and exploited. It’s considered one of the most critical vulnerabilities ever, due to the prevalence of Log4j, a popular Java library for logging error messages in applications, and how easy Log4Shell is to exploit. Just by sending plaintext messages, the attacker can trick the application into sending malicious code to gain remote control over the system.

It’s been a year since this vulnerability was released, and although patched versions of Log4j were released soon after the vulnerability was disclosed, many systems remain unprotected. A recent study found that as of October, 72% of organizations remained vulnerable to Log4Shell. Even if it’s fixed, many instances become vulnerable again after remediation as new assets are added.

A Year On

Although Imperva has seen the volume of attacks fall since Log4Shell was released last December, customers are still hit by an average of 500,000 attack requests per day. About 7% of those requests are successful. Collectively, 12% of all CVE requests since December 2021 are related to Log4Shell.

Log4Shell Requests

Log4Shell exploit requests were high daily until late February, and slowly decreased until hitting a baseline for most of 2022. On December 3, however, Imperva observed attack requests skyrocket to higher daily request numbers than we had seen when this vulnerability was originally released. Although this spike was a targeted attack, attacks have been increasing across the board since the beginning of November, likely due to the anniversary of the CVE.

Requests by day

Although Log4Shell is a huge, newsworthy CVE, requests in 2022 have settled to a baseline of about 500K per day. On the other hand, Shellshock (CVE-2014-6271) has maintained an average of about 3M requests per day, despite being almost a decade old. Log4Shell is massively impactful, but its popularity has already waned compared to other CVEs like Shellshock.

Shellshock Log4j

Log4Shell is most commonly exploited by bots and the Chrome browser, although requests also come from cURL, PhantomJS, Nessus Cloud, the Go HTTP library, and Node.js. It’s also included in the Qualys, Nessus, Whitehat, and Detectify vulnerability scanners.

Payloads

One year ago, Imperva Threat Research observed payloads attempting probing, reverse shells, malware deployment, data exfiltration, and patching. One year later, payloads are generally the same.

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. 

Reverse Shell: This payload will open a communication channel between the vulnerable application and the hacker. After the hacker receives the communication, they can further explore the target system and remotely run any shell commands.

Malware deployment: Attackers will attempt to deploy malware on vulnerable systems.

Data exfiltration: Payloads that attempt to exfiltrate information, especially AWS keys or Docker and Kubernetes info.

Patching: Interestingly, Log4Shell can be used to deploy Java code that changes the configuration and disallows lookups. In other words, you can patch the Log4shell vulnerability with a Log4shell payload.

The Future

Log4Shell had a tangible impact over the last year, and it will undoubtedly continue to affect countless systems for a long time. Ensure you’re using a patched version of Log4j, and consider tools like Imperva Runtime Application Self-Protection (RASP) to protect against unknown exploits.

The post Log4j: One Year Later appeared first on Blog.

*** This is a Security Bloggers Network syndicated blog from Blog authored by Gabi Stapel. Read the original post at: https://www.imperva.com/blog/log4j-one-year-later/