NotSoSerial is a Java Agent designed as a mitigation effort against deserialization attacks.

NotSoSerial is a Java Agent designed as a mitigation effort against deserialization attacks.

NotSoSerial is a Java Agent designed as a mitigation effort against deserialization attacks.
Think of it as a “deserialization firewall”. It gives you complete control over which classes your application should be allowed to deserialize.
for details on this attack:

Latest Change :
– src folder :Moved configuration into a new class Options.
– pom.xml: Instrument ObjectInputStream.resolveClass instead of injecting / modifying readObject for each class.

requirements, Installation and Build NotSoSerial Class :
– Install Apache Maven
– Install Java Platform(JDK)
– git clone

Build NotSoSerial:

mvn clean install (NotSoSerial Builder)

mvn clean install (NotSoSerial Builder)

This builds an NotSoSerial jar file in target/notsoserial-1.0-SNAPSHOT.jar
Copy this as notsoserial.jar to your application, and add the following parameters to your Java startup script:

PLEASE NOTE: In this mode, NotSoSerial only does blocks a few known vulnerabilities. It does not fix the problem with deserialization attacks. It only knowns about some well known classes for which it rejects deserialization. See below how you can whitelist or completely reject any objects to be deserialized.



Which classes are rejected?
By default, NotSoSerial rejects deserialization of the following classes:
– org.apache.commons.collections.functors.InvokerTransformer
– org.apache.commons.collections4.functors.InvokerTransformer
– org.codehaus.groovy.runtime.ConvertedClosure

You can add your own classes to this list by passing a comma-separated list of classes as a system property:

Whitelisting mode
As always, it would be better if we could accept only classes we explicitly want to allow for deserialization. Rejecting based on a whitelist is better security than rejecting based on a blacklist.
To help build a whitelist file with legitimately serializable classes, a ‘dryrun’ option has been added. Together with an empty white list, this will create a list of classes which your application actually deserializes.

This can be produced by configuring the agent as follows:

Where ’empty.txt’ is an empty file and ‘is-deserialized.txt’ is a file where the names of your actually deserialized classes will be written to.
After you are confident that all deserializable classes in your application have been recorded, you may restart your app, now reusing the recorded-as-serialized file as the whitelist:

Rejecting deserialization entirely
Just use an empty whitelist. Preliminary testing with a non-trivial Java application (which does not intentionally use RMI or other serialization) seems to indicate that this might work just fine. Looks like the JDK might not need serialization for any of its internal operations.

Tracing deserialization
You might be interested not just in which classes your application deserialize, but also where in your code deserialization happens.
This can be enabled by using the ‘trace’ option, like the following:

This will produce a file deserialize-trace.txt looking something like this: