hunting-dotnet-deserialization-type-injection

Hunting .NET deserialization and type injection: when the payload picks the type

.NET deserialization is dangerous for a specific reason: several formatters read the concrete type to instantiate from the serialized data, not from the declared target. When BinaryFormatter, SoapFormatter, NetDataContractSerializer, the ViewState formatters, or a JSON serializer with type-name handling turned on processes attacker data, the attacker chooses which class gets constructed. That lets them instantiate a gadget type whose property setters, deserialization callbacks, or type converters perform a side effect, chaining to a process start, a command, or a file operation. The fix is almost always to stop resolving types from the data. You find these by locating every formatter that honors an embedded or annotated type and asking whether untrusted bytes reach it.

When to use

• A service reads serialized .NET objects from a request, ViewState, a cookie, a queue, or a cache.
• A formatter in use resolves the type from the payload or has type-name handling enabled.
• Reachable assemblies carry a gadget type whose construction or callback has an exploitable side effect.

Scope check

Test deserialization only against services you own or are authorized to assess, on non-production infrastructure. A confirming payload constructs an attacker-chosen type and can run code, so treat every proof as a live intrusion inside the authorized scope. If you can't name the authorization, stop.

The loop

1. Establish the type-resolving sinks first. Inventory every formatter that reads the type from the data: BinaryFormatter, SoapFormatter, NetDataContractSerializer, LosFormatter and ObjectStateFormatter behind ViewState, and any JSON or XML serializer configured with type-name handling or a permissive binder. This is the false-positive killer: a formatter that deserializes to a fixed known type with no type resolution is not injectable. Name the resolving sinks first.