Zeroday in ubiquitous Log4j tool poses a grave threat to the Internet

[Lightwreather]

Summary

Exploit code has been released for a serious code-execution vulnerability in Log4j, an open-source logging utility that's used in countless apps, including those used by large enterprise organizations, several websites reported on last Thursday.

 

Quotes

Quote

Word of the vulnerability first came to light on sites catering to users of Minecraft, the best-selling game of all time. The sites warned that hackers could execute malicious code on servers or clients running the Java version of Minecraft by manipulating log messages, including from things typed in chat messages. The picture became more dire still as Log4j was identified as the source of the vulnerability and exploit code was discovered posted online.

“The Minecraft side seems like a perfect storm, but I suspect we are going to see affected applications and devices continue to be identified for a long time,” HD Moore, founder and CTO of network discovery platform Rumble, said. “This is a big deal for environments tied to older Java runtimes: Web front ends for various network appliances, older application environments using legacy APIs, and Minecraft servers, due to their dependency on older versions for mod compatibility.”

Log4j is incorporated into a host of popular frameworks, including Apache Struts2, Apache Solr, Apache Druid, and Apache Flink. That means that a dizzying number of third-party apps may also be vulnerable to exploits that carry the same high severity as those threatening Minecraft users.

At the time this post went live, there wasn’t much known about the vulnerability. One of the few early sources providing a tracking number for the vulnerability was Github, which said it's CVE-2021-44228. Security firm Cyber Kendra on late Thursday reported a Log4j RCE Zero day being dropped on the Internet and concurred with Moore that “there are currently many popular systems on the market that are affected.”

The Apache Foundation has yet to disclose the vulnerability, and representatives there didn't respond to an email. This Apache page does acknowledge the recent fixing of a serious vulnerability. Moore and other researchers said the Java deserialization bug stems from Log4j making network requests through the JNDI to an LDAP server and executing any code that's returned. The bug is triggered inside of log messages with use of the ${} syntax.

Additional reporting from security firm LunaSec said that Java versions greater than 6u211, 7u201, 8u191, and 11.0.1 aren't affected by this attack vector. In these versions the JNDI can't load a remote codebase using LDAP.LunaSec went on to say that cloud services from Steam and Apple iCloud have also been found to be affected. Company researchers also pointed out that a different high-severity vulnerability in struts led to the 2017 compromise of Equifax, which spilled sensitive details for more than 143 million US consumers.

Cyber Kendra said that in November the Alibaba Cloud security team disclosed a vulnerability in Log4j2—the successor to Log4j—that stemmed from recursive analysis functions, which attackers could exploit by constructing malicious requests that triggered remote code execution. The firm strongly urged people to use the latest version of Log4j2 available here.

 

My thoughts

I'll preface this by saying, I don't know much whenit comes to code and much less when it pertains to Java. But anyway, this seems to be a major issue for Java versions below 6u211, 7u201, 8u191, and 11.0.1 . Well, I suppose turn off your Minecraft servers (or actually just block all network access) until a patch is issued and then update. That's literally all I can tell. But I will ask, Devs who know and can understand this, please do enlighten us. Thanks. 

Sources

ArsTechnica

Other Primary sources within said article that rn I just can't be bothered to type and to

[DexterSmythe]

Just updated Java on all my computers. Thanks for the post.

Edit: Read Eigenvektor's post for more information. Just updating your Java install isn't enough.

[StDragon]

Hate java. Patch it, and legacy apps break. Grrrr.... There's going to be a lot of pain for IT admins out there.

[Eigenvektor]

5 hours ago, DexterSmythe said:

Just updated Java on all my computers. Thanks for the post.

Updating Java is not enough. You need to update Java applications that are using a vulnerable version of Log4j. It's not a Java bug as such, but rather a bug in a popular logging framework used by many many Java applications.

 

If a server application (like Minecraft) writes stuff into its logs that can be influenced by a user (e.g. "User Eigenvektor signed in") then a hacker could exploit it by creating a user with a name that triggers this exploit.

 

The actual fix is for developers of vulnerable applications to update the Log4j version used in their code to version 2.15, and then to release a new version of their application. Users then need to update these affected applications to the one that contains the fixed Log4j library.

 

Here's some more background info: https://blog.sonatype.com/a-new-0-day-log4j-vulnerability-discovered-in-the-wild

[DexterSmythe]

13 minutes ago, Eigenvektor said:

Updating Java is not enough. You need to update Java applications that are using a vulnerable version of Log4j. It's not a Java bug as such, but rather a bug in a popular logging framework used by many many Java applications.

 

If a server application (like Minecraft) writes stuff into its logs that can be influenced by a user (e.g. "User Eigenvektor signed in") then a hacker could exploit it by creating a user with a name that triggers this exploit.

 

The actual fix is for developers of vulnerable applications to update the Log4j version used in their code to version 2.15, and then to release a new version of their application. Users then need to update these affected applications to the one that contains the fixed Log4j library.

 

Here's some more background info: https://blog.sonatype.com/a-new-0-day-log4j-vulnerability-discovered-in-the-wild

Thanks for correction, I'll edit my post.

[Sir Humphrey Appleby]

As from logs on my own server I can confirm that Russian bots have already tried to exploit it...

[Sir Humphrey Appleby]

Hm, all my current ips are from russia

 

[Sir Humphrey Appleby]

I also found the script they were trying to execute.
Renamed to txt so someone does not accidentally run it.

lh.txt

[duncannah]

Just got an email from Cloudflare about this:

[Fasterthannothing]

Crap this is bad! I need to turn crap off on my systems now! I can't even imagine how bad this is going to get so many people who don't know a darn thing about this stuff and it's so easy. 

 

Edit: Got lucky and appears the version I haven't isn't affected so far and logs look clean so I'll keep an eagle eye on it. 

[williamcll]

big oof for all the legacy minecraft servers.

[Fasterthannothing]

6 hours ago, williamcll said:

big oof for all the legacy minecraft servers.

It appears if your log4j version is old enough then it's ok. Anything less than version 2.0 beta9 and above 2.15 seems fine from what I understand. 

 

Edit: Now I'm somewhat confused what is affected. Some places say everything but Apache says anything greater than 2.0 beta 9. Apache also said anything 1.x is not checked but I also would assume 2.0 beta 8 would have gotten checked therefore I would assume even though it wasn't checked all the way if its below 2.0 beta 9 but still a 2.0 base it would have been checked therefore probably ok to conclude it's not actually all versions.

[Fasterthannothing]

Ok I was able to find confirmation 1.x is not affected only 2.0 beta 9 and up. So this should be a saving grace for those that have to run old software at least in this case. Also for anyone wondering the authenticity of that confirmation it's direct from the guy who developed log4j. 

 

https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126

 

 

[WolframaticAlpha]

We just swapped out a bunch of components that would be affect by this vulnerability

[jagdtigger]

Seems like scans already going for this, good thing suricata already has signatures:

[Fasterthannothing]

1 hour ago, jagdtigger said:

Seems like scans already going for this, good thing suricata already has signatures:

Snort also has an update for this just an FYI for anyone using that instead

[Craftyawesome]

On 12/10/2021 at 4:24 PM, Eigenvektor said:

Updating Java is not enough. You need to update Java applications that are using a vulnerable version of Log4j. It's not a Java bug as such, but rather a bug in a popular logging framework used by many many Java applications.

 

If a server application (like Minecraft) writes stuff into its logs that can be influenced by a user (e.g. "User Eigenvektor signed in") then a hacker could exploit it by creating a user with a name that triggers this exploit.

 

The actual fix is for developers of vulnerable applications to update the Log4j version used in their code to version 2.15, and then to release a new version of their application. Users then need to update these affected applications to the one that contains the fixed Log4j library.

 

Here's some more background info: https://blog.sonatype.com/a-new-0-day-log4j-vulnerability-discovered-in-the-wild

To add a little more info, AFAIK the versions listed in the OP fix the LDAP attack vector. Unfortunately, this isn't enough.

[Mark Kaine]

So how do i check if i have this particular "java" installed? 

 

Spoiler

i mean, i don't have a "server" but the attackers probably just see "unupdated windows 1809, probably ltsc, it must be the main server..." :x

 

[Shreyas1]

I don't own a minecraft server, do I need to update my client as well?

Also heard steam is affected.

[LAwLz]

Holy crap this is so much bigger than I imagined...

Has anyone found a good way of remotely scanning for vulnerable servers? I am asking because I want to run this on myself. I don't want to run some third party script I found on Github locally on a production server.

There are plugins for Burp that can do it, but I don't have the paid version.

[leadeater]

42 minutes ago, LAwLz said:

Has anyone found a good way of remotely scanning for vulnerable servers? I am asking because I want to run this on myself. I don't want to run some third party script

If you have a configuration management and inventory scanning product you can just infer this by checking if the affect software version is installed. We have Tenable, Microsoft ATP, Red Hat Satellite, SCCM, JAMF Pro and Lansweeper so haven't really needed to go out looking for anything as all have inbuilt scanning for this specific vulnerability or all software and versions catalogued for every server and desktop/laptop.

 

The bigger problem we have found is more closed vendor/OEM systems like storage arrays that you cannot install any of the above software or scan easily since they can often rename packages to their own naming but actually be something else, like Log4J or SAMBA etc.

 

I'd give a list of all the software and vendor products that we know are affected but since not all have complete mitigations or patches yet that would be a massive "LOL please find and attack me".

[LAwLz]

5 minutes ago, leadeater said:

If you have a configuration management and inventory scanning product you can just infer this by checking if the affect software version is installed. We have Tenable, Microsoft ATP, Red Hat Satellite, SCCM, JAMF Pro and Lansweeper so haven't really needed to go out looking for anything as all have inbuilt scanning for this specific vulnerability or all software and versions catalogued for every server and desktop/laptop.

 

The bigger problem we have found is more closed vendor/OEM systems like storage arrays that you cannot install any of the above software or scan easily since they can often rename packages to their own naming but actually be something else, like Log4J or SAMBA etc.

 

I'd give a list of all the software and vendor products that we know are affected but since not all have complete mitigations or patches yet that would be a massive "LOL please find and attack me".

Yeah, we can easily check some stuff if it runs a vulnerable program or not, but as you said the problem we got is that we don't know what software is affected. I would like a way to check that.

Not sure if you have seen Cisco's list but it's basically just "we have no idea what's affected, might be pretty much everything and we have no fix yet".

 

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd

 

 

What I would like is a program that:

1) Scans a given IP range for open ports.

2) Runs the ldap query against every open port.

3) The ldap query exploits this vulnerability and if it works, it executes a harmless payload that informs me about it in some way. Like write a message to a server with its IP.

 

I haven't been able to find a (free) program that does this yet, and I am not good enough to write it myself.

[leadeater]

28 minutes ago, LAwLz said:

Yeah, we can easily check some stuff if it runs a vulnerable program or not, but as you said the problem we got is that we don't know what software is affected. I would like a way to check that.

We've been able to get it for software by looking at the included libraries, Linux is quite easy for that and for Windows SCCM catalogues every file if you tell it to so just initiate a one off scan then search for any jar files, xml config files etc that could be it. Lansweeper has the same functionality I think, not sure, we try and limit the number of systems that literally do the same thing so we don't scan stuff many times for no reason.

 

Had a quick look and there seems to be a few good ones. python scripts that you point to urls, and the deployed payload is a DNS callback so if you get a hit then the payload was run.

 

Just a note however, running a script like this is flawed because it relies on an accessible url to scan and send the payload to, not every application that utilizes Log4J can be interacted with in such a way or it's utilized in a way where you simply cannot do that as it wouldn't work, not how they are trying anyway. That's not to say these are not vulnerable because they are it's just a matter of figuring out how to get the software/system to send a log message to Log4J that is engineered to exploit it.

 

So unfortunately finding all affected systems just isn't a simple matter and you may have to rely on a vendor telling you your system is vulnerable, which is extremely sub-optimal.

[igormp]

Something that no one mentioned here, adding the following parameter onto your JVM should workaround this "issue":

-Dlog4j2.formatMsgNoLookups=true

That's not really a "bug", just a stupid default that apparently no one thought about the consequences when it comes to string formatting/parsing.

 

Here's a nice overview about this issue: https://www.lunasec.io/docs/blog/log4j-zero-day/

 

And some memes, of course:

 

 

 

[arcanekand]

here is a list of (possibly) affected devices/applications and security bulitins: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

 

check the list to see if you have any affected devices/apps

 

Note: some of the programs/sytems on the list are affected some are where the developer has replied to state their programs are not affected but its best to check to make sure.