Doubly-Linked-List-VST VS ysoserial

So I've finished the unified box in stage 2 of the starting point and have tons of questions about the box. In the box they use veracode-research/rogue-jndi to exploit the log4j vulnerability. But when I test it with deserialize payload generated by frohoff/ysoserial it's not running. I've try to look at the java log in the challenge container but can't find anything that java complain or error out. Is it because the ysoserial payload too complex that it running but fail at some point and don't throw error or maybe the author just hard code so that only the payload from rogue-jndi work? can it's because of the java version/framework/library/weirdness? Do I need to test both kind of payload if I want to exploit log4j in the future or just stick with pimps/JNDI-Expoit-Kit or cckuailong/JNDI-Injection_Exploit-Plus (my senior recommendation when exploiting log4j).

GitHub - Ysoserial

A gadget lets you run load a different class upon serialization. This will fail later when we downcast but during the read process we can load a different class where we can do arbitrary code execution. HashMap is a class that overrides the readObject and can be used as part of an exploit chain. ysoserial helps us create a chain of serialization to produce an exploit based on known serialization weaknesses. You can run this project and generate payload ser files that you can pass to exploit potential vulnerabilities.

gadget chain attack: is a type of exploit where an attacker uses a series of "gadgets" — small pieces of code that perform a specific function — to execute a larger, more complex attack. By chaining together these gadgets, an attacker can gain control of a target system or perform other malicious actions. You can use ysoserial to create a serialize payload java -jar path/to/ysoserial.jar CommonsCollections4 'whoami'

> A similar issue has occurred with Java (and other languages, see https://frohoff.github.io/appseccali-marshalling-pickles/). Java provided a suberbly user-friendly way of serializing any object to disk and recovering it back in its original form. The only unfortunate problem was that there was no way to say which object you are expecting! This allows attackers to send you objects that, upon deserialization in your program, become nasties that wreak havoc and steal data.

Not correct. You can certainly inspect before instantiation:

https://docs.oracle.com/javase/7/docs/platform/serialization...

Mmh, I don't think so. Beside logging most other libraries will already sanitize user input since it is a more commonly known attack vector for those kind of libraries. I would compare the vulnerability to https://github.com/frohoff/ysoserial.

Exactly. eg. https://github.com/frohoff/ysoserial#usage

Note the classes aren't at fault or doing anything wrong (even though you could imagine other mitigations they could use), they are just conveniently there to use if you have a vulnerability that lets you de-serialize untrusted data.

This has been known for a zillion years and has caused a zillion CBEs, so at this point there are off-the-shelf tools like ysoserial that take your payload and wrap it into an object that kabooms when deserialized, with like 20 different choices of methods depending on what dangerous objects are available on the target's classpath for deserialization.