Thread by @aaditya_purani

How to attack any JDK version for log4j "without" guessing classpath on server?

Try to exfiltrate the class path using ${sys:java.class.path} or ${env:CLASSPATH}.

What if it fails? Don't forget java. net.URL is serializable! You can bruteforce ClassName

github.com/BishopFox/Gadg…

So, the idea is to retrieve the remote Java ClassPaths using GadgetProbe.

It is trivial to create a serializable payload by iterating through commonly used classname signatures and use github.com/pimps/JNDI-Exp… to serve it.

This way you will know libraries used on classpath

But what if the remote server uses a library on classpath whose gadget chain is not present on YSOSerial?

Two things are possible
1.) Manual audit the library to find Gadget (Refer: synacktiv.com/publications/f… )

2.) Automate Gadget Discovery - github.com/JackOfMostTrad…

#log4shell

Also, a deserialization gadget in latest JRE version or log4j-core cannot be taken out of the equation.

That'd make this universal.

Similar to gist.github.com/frohoff/24af79…

github.com/frohoff/ysoser…

For those who are catching up - GadgetProbe utilizes this same fact as the tweet below. Also, this has been known to be weaponized since a long time. There is also a URLDNS payload in YSOSerial.

This can be also used to brute-leak remote classpath used for log4j.

#log4shell

https://twitter.com/ncweaver/status/1470453024870912000