Log4Shell: Still out there, still dangerous, and how to protect your systems | #cloudsecurity


Barracuda researchers have noticed a steady stream of attacks attempting to exploit the Log4j vulnerability since it was found. What’s interesting is where most attacks originate.

Image: Adobe Stock/Andreas Prott

Log4Shell, an exploit directed at the commonly used Apache Log4j library, hasn’t shown any signs of slowing down as a popular target for hackers since its discovery in December, said researchers at Barracuda Networks.

Log4Shell is just about as critical as a critical vulnerability can get. It scored 10 out of 10 by the National Institute of Standards and Technology’s severity scale, and with good reason: It targets a library that nearly every Java application uses to log requests, and all it takes to trigger it is a malicious string from the attacker.

SEE: Google Chrome: Security and UI tips you need to know (TechRepublic Premium)

Since its discovery in December, said Barracuda Senior Product Marketing Manager for Applications and Cloud Security Tushar Richabadas, “the volume of attacks attempting to exploit these vulnerabilities has remained relatively constant with a few dips and spikes over the past two months.”

Here’s the strange thing: 83% of the attacks that have tried the exploit Log4Shell originated in the United States.

The anatomy of Log4Shell attacks

Barracuda said it pulled data from attacks dating back to December 10, 2021, to get a complete look at how Log4Shell has been used since its discovery. As mentioned above, the researchers found some interesting data when looking at attacker IPs: The majority come from the U.S., while the rest come from Japan (10%), Germany and the Netherlands (3%) and Russia (1%).

Richabadas noted that an attack originating from a particular IP doesn’t mean the attacker is geographically located in that place, especially since Barracuda found that half of the attacks originating in the U.S. came from AWS, Azure and other cloud data centers.

“Cloud services just provide easy access to ephemeral IP’s that have a good reputation and are not likely to be geo or reputation blocked,” Richabadas said. Additionally, he noted that actual payloads were likely delivered from other compromised sites or virtual private servers. Those IPs are usually encoded in Base64 to further obfuscate them, making it harder to determine where the payload originates.

In terms of what attackers are doing once they’ve managed to successfully use the Log4Shell exploit, Barracuda singled out four examples: A relatively harmless prank, cryptomining malware, DDoS malware and VMware-targeting malware.

The first is, depending on how you look at it, a pretty benign yet informative trick: It Rick-Rolls users when a certain set of conditions are met. As opposed to that “attack,” which could actually be considered helpful from a “thanks for letting us know” perspective, the others that Barracuda describes are decidedly less “helpful.”

SEE: Password breach: Why pop culture and passwords don’t mix (free PDF) (TechRepublic)

Monero cryptomining malware has been found, as has malware that targets VMware installations, initiates DDoS attacks and installs a variety of botnet malware, the most common of which has been the IoT device targeting Mirai botnet.

The types of attacks may provide a clue as to what’s coming in the near future of cybersecurity, too, Richabadas said. “The prevalence of DDoS botnet malware seems to suggest that threat actors are working toward building out a large botnet for future use, and there should be an expectation of large DDoS attacks in the near future.”

Protecting yourself from Log4Shell is simple, really

There’s a simple fix that could completely remove this risk from your cybersecurity calculus: Patch to the latest version of Log4j, which takes care of the problem.

That isn’t always possible in production environments, so if you’re unable to patch now there are steps you can take to determine if your systems are vulnerable to Log4Shell, as well as different things that can be done to minimize your Log4Shell exposure … until you can actually install the patch, which should be your eventual goal.



Original Source link




Leave a Reply

Your email address will not be published.

+ eighty seven = ninety five