Security Countless Servers Are Vulnerable to Apache Log4j Zero-Day Exploit (Log4Shell)

The scope is changing... evolving.

 

I asked fellow companies, colleagues I know through various steering committees.
Because this is and will continue to be a critical CVE.
But little activity. There is some scan activity but no (semi) successful crack.
It doesn't seem targeted but just via a script kiddie scan all ips in a class kind of.

Yeaah hurrah yeeeaah yooo, attemps, targeting, trivial to and attempts.
But you don't hear of more successful attacks.

The press tries to score time and time again with clickbait garbage.
There are many knowledgeable system administrators who have long solved this problem.

Same song with every critical CVE.
Or like Christmas and New Year's Eve (aside from corona) every year the same nonsense in the press about more break-in attempts.

But of more actual successful break-ins, you don't hear anything.
After all, just like with ICT infrastructure, homeowners are better secured by ICT (smart cameras etc) and better prepared, nowadays.

 

In fact I am pretty sure they figured it out, without mentioning specific names.
These have a service contract and are contacted by their account manager.
There are too many interests at play and a supplier does not want to lose a major customer.

There are also security service providers who are continuous monitoring your infrastructure as service. Sometimes this is even required by law. You see this kind of service more and more often. SP respond within a max of a few hours after the CVE is released, contractually defined.

Not only respondin on CVE's, but for example also when many files are suddenly accessed over the network by night (For no reason).
Which could indicate ransomware which is running to encrypt all the files.

In short I am repeating myself but if your business is in good order there is no reason to panic.
In fact, internet-criminals want panic to occur because panic causes people to make mistakes.

And then that pesky press can write about it again. Because cucumber time and clicks.

 

Log4j Vulnerability: Attackers Shift Focus From LDAP to RMI
https://blogs.juniper.net/en-us/thr...bility-attackers-shift-focus-from-ldap-to-rmi

Log4j Attack Payloads In The Wild
https://blogs.juniper.net/en-us/security/in-the-wild-log4j-attack-payloads

Keeping up with log4shell aka CVE-2021-44228 aka the log4j version 2
Keeping up with log4shell aka CVE-2021-44228 | CSA

 

Nice!

Ouch. That got spicy.

At what point do people start calling all the patches... a quilt?

 

When i use:

Code:

yum update --disableplugin=priorities --setopt=deltarpm=0 --enablerepo=remi,city-fan.org

I can update to: 6.8.21-1

After updating i can see using:

Code:

curl -XGET 'localhost:9200'

"number" : "6.8.20", - Don't know why this older version....

At Elastic site i can see as latest version the 6.8.22 but i can't get it when updating

Release Notes | Elasticsearch Guide [6.8] | Elastic

Any ideas why?

Thanks

 

Thanks for the update, patched my servers accordingly.

 

Google Online Security Blog: Understanding the Impact of Apache Log4j Vulnerability