Critical 'Log4J' Java flaw being used to deliver malware, crypto-miners

AppleInsider

A critical flaw in a popularly used Java library is being exploited by malicious actors to deliver malware, while security researchers are scanning for vulnerable servers.

Log4j is being used to deploy malware on vulnerable systems.

The flaw and a proof-of-concept exploit was publicly released on Friday, wreaking havoc across companies that use the popular Log4j Java platform. Impacted firms included Amazon, Apple, Steam, Minecraft, and a lot more.

According to Bleeping Computer, threat actors have been using the vulnerability to deliver crypto-miners, botnet, and penetration tools that could be used to deploy ransomware on affected systems.

There's currently no public data suggesting that ransomware gangs have used the Log4k exploit, but the deployment of the aforementioned penetration tools suggests that such attacks could be "imminent," Bleeping Computer reported.

Additionally, both threat actors and security researchers are using the exploit to scan for vulnerable servers and steal information from them. From there, scanners can determine whether a server can be used for additional attacks, research purposes, or bug bounty awards.

The flaw exists in the Log4j Java-based logging platform, which is used for web server access and application logs. Once exploited, the vulnerability could allow a remote attacker to perform code execution or otherwise take control of a vulnerable server.

Since Log4j is used in thousands of websites and enterprise apps, security researchers are concerned that it could lead to widespread malware attacks and deployments.

Apache quickly patched its systems to mitigate the vulnerability.

Who's at risk, and how to protect yourself

Although the vulnerability appears to be wreaking havoc on Friday, the effects are mostly being felt in the enterprise sector. In other words, it's not up to end users to defend themselves against the vulnerability.

Engineers working in the programming subreddit suggested that major technology companies like Amazon have been working to fix the problem since late Thursday night. AppleInsider has learned that the week continued through the weekend at Amazon and others, and some companies are still implementing patches and work-arounds.

Read on AppleInsider

maltz

AppleInsider said:

Although the vulnerability appears to be wreaking havoc on Friday, the effects are mostly being felt in the enterprise sector. In other words, it's not up to end users to defend themselves against the vulnerability.

Or perhaps more accurately, "end users are helpless to defend their data against the vulnerability" ...as is so often the case.

loopless

Please show evidence of this “wreaking havoc”. The only evidence is the freaking out of the tech media, though I’ll bet some sysadmins are having a rough weekend updating log4j installations.  Let’s see some evidence of actual successful attacks causing “havoc”.

dewme

loopless said:

Please show evidence of this “wreaking havoc”. The only evidence is the freaking out of the tech media, though I’ll bet some sysadmins are having a rough weekend updating log4j installations.  Let’s see some evidence of actual successful attacks causing “havoc”.

There's always a level of hyperbole when dealing with these issues, and especially where the attack surface is so broad and so easily exploitable. No matter how you want to describe it, the mitigation process for dealing with this particular vulnerability is going to disrupt a lot of folk's regularly scheduled activities that were already in the pipeline. They can't put this one on the back burner and get around to fixing it 3 months from now.

For people and organizations that had slack in their schedules and have a narrow exposure window, this may be a no-big-deal. For others it will mean stopping what they were previously doing, going after this issue with every available resource, and only returning to business as usual when they feel their mitigation steps have been successful. Additionally, post mitigation, they may have to do a thorough audit and inspection of their system to determine whether any unusual behaviors took place prior to the mitigation being deployed, which may also disrupt other work that was in the pipeline to be worked on.

Whether it's "havoc worthy" is subjective and depends on the cost of unplanned downtime and cost of damage to the affected businesses. For businesses that lose millions-per-minute when their systems are disrupted or suffer the loss of property, it is a really really big deal. The good news is that most of the people who are assigned to mitigate this issue are probably going to approach solving this issue in a very direct and methodical manner, regardless of the media coverage and Chicken Little gyrations of some folks. They'll work the problem rather than becoming part of the problem by panicking. The sooner they start working on it, the better.

If you want to get some non hyperbolic insight into how affected businesses are reacting this, the following website is a good place to start: https://www.cisa.gov/uscert

mystigo

My company has a lot of services to inspect, dozens at least. However our preliminary investigations show that we switched to logback a long time ago on most of them. We did find a couple that were likely exploitable but they were non-critical systems and we disabled them until we can mitigate or update.

I updated my kid's open Minecraft server on Monday.

So far no havok has been wreaked. We think!

JohnnyJackhammer

My first instinct is to think where is this installed on my system!!!
So I can remove whatever software is using it. Yet this is never mentioned in these articles.

Marvin

JohnnyJackhammer said:

My first instinct is to think where is this installed on my system!!!
So I can remove whatever software is using it. Yet this is never mentioned in these articles.

It mainly affects server software using Java. There are some tools to scan for the package:

https://www.infoworld.com/article/3644492/how-to-detect-the-log4j-vulnerability-in-your-applications.html
https://www.techrepublic.com/article/how-to-test-if-your-linux-server-is-vulnerable-to-log4j/
https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh