aegis4j VS ysoserial

The guys at Oracle have made this point on this forum quite often, but it never really hit home for me personally until the recent log4j vulnerability made me more interested in the topic and the available mitigation options (see https://github.com/gredler/aegis4j/).

If you've been impacted by these log4j vulnerabilities, have a look at aegis4j, a Java agent that completely disables platform features you don't use, before an attacker uses them against you (including e.g. JNDI and Java serialization).

https://github.com/gredler/aegis4j/

Yep, this is why strategically patching InitialContext when the class is initially loaded will completely disable JNDI (and mitigate future JNDI-based exploits).

The recent log4j vulnerability really piqued my interest, and I've spent the last few evenings working on a proof of concept Java agent that could mitigate similar vulnerabilities in the future, for applications that are able to completely forego platform features like JNDI, serialization or native process execution.

Link to the project: https://github.com/gredler/aegis4j

It's not a lot of code, but it uses parts of the platform that I think are a bit unusual for most devs, so it was quite interesting to implement. Happy to discuss details, ideas, and concerns.

One idea for a possible improvement is to make the feature block list adaptive, i.e. watch what the application uses in the first few minutes of execution, and then shut down all unused "dangerous" features for the remaining lifetime of the VM. Not sure how reliable this would be though, especially for services which have background jobs that might only run once a day.

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.