External json vulnerable because of Json.Net TypeNameHandling auto?

by

TL/DR: In the absence of any obvious object or dynamic members, you may well be safe, but you are not guaranteed to be safe. To further decrease your risk you should follow the recommendations from the Newtonsoft documentation:

TypeNameHandling should be used with caution when your application deserializes JSON from an external source. Incoming types should be validated with a custom SerializationBinder when deserializing with a value other than None.

Full Answer

The attacks described in How to configure Json.NET to create a vulnerable web API, TypeNameHandling caution in Newtonsoft Json and Alvaro Muñoz & Oleksandr Mirosh’s blackhat paper all depend on using the TypeNameHandling setting of Json.NET to trick the receiver into constructing an attack gadget – a instance of a type that when constructed, populated or disposed effects an attack on the receiving system.

Json.NET does two things that help protect against such attacks. Firstly, it ignores unknown properties. Thus simply adding an additional, unknown property to a JSON payload whose value contains a "$type" property should do no harm. Secondly, during deserialization of a polymorphic value, when resolving the "$type" property, it checks to see whether the resolved type is compatible with the expected type in JsonSerializerInternalReader.ResolveTypeName():

    if (objectType != null
#if HAVE_DYNAMIC
        && objectType != typeof(IDynamicMetaObjectProvider)
#endif
        && !objectType.IsAssignableFrom(specifiedType))
    {
        throw JsonSerializationException.Create(reader, "Type specified in JSON '{0}' is not compatible with '{1}'.".FormatWith(CultureInfo.InvariantCulture, specifiedType.AssemblyQualifiedName, objectType.AssemblyQualifiedName));
    }

If the expected type of the polymorphic value is not compatible with any attack gadget type, the attack will fail. Provided you have no serializable members of type object, dynamic or IDynamicMetaObjectProvider, this is likely to be true. But not certain!

Cases in which an attack gadget might get constructed even without any obvious untyped members in your data model include:

  • Deserialization of untyped collections. If you are deserializing any sort of untyped collection or dictionary such as ArrayList, List<object>, Dictionary<string, dynamic> or HashTable, then your system is vulnerable to attack gadgets contained in the collection’s items.

  • Deserialization of any of the dozens of collections inheriting from CollectionBase. This type predates the introduction of generics in .Net and represents a “semi-typed” collection, in which the types of the items are validated in runtime as they are added. Since the validation occurs after construction, there is a window in which an attack gadget might get constructed.

    Sample fiddle showing just this.

  • Deserialization of values that share a common base type or interface with an attack gadget other than just object. TempFileCollection implements ICollection and IDisposable. ObjectDataProvider implements INotifyPropertyChanged and ISupportInitialize. If you have any polymorphic members or values that are declared to be any of these interfaces, you are vulnerable.

  • Deserialization of types that implement ISerializable. Json.NET supports this interface by default, and it is possible that a seemingly-harmless type in some external library is deserializing untyped members inside its streaming constructor without your knowledge.

    One obvious example is Sytem.Exception (or any of its subtypes) which deserializes an untyped dictionary "Data" inside its streaming constructor which corresponds to the untyped dictionary Exception.Data. If you are deserializing an Exception (contained in a log file for example, which is very common), the following JSON should effect an attack:

    {
  "$type": "System.Exception, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089",
  "ClassName": "System.Exception",
  "Message": "naughty exception",
  "Data": {
    "$type": "System.Collections.ListDictionaryInternal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089",
    "data": {
      "$type": "System.IO.FileInfo, System.IO.FileSystem",
      "fileName": "rce-test.txt",
      "IsReadOnly": true    
    }
  },
}

    The attack can be mitigated without creation of a custom serialization binder by setting DefaultContractResolver.IgnoreSerializableInterface = true. Of course, this may cause problems with serialization of certain .Net class library types.

  • Deserializing types marked with [Serializable] can have a similar problem if you set DefaultContractResolver.IgnoreSerializableAttribute = false. However, the default is true, so you should be OK if you don’t change this setting.

  • Deserializing types with members that you think are not serialized — but will be deserialized if present. E.g. consider the following type:

    public MyType
{
    public object tempData;
    public bool ShouldSerializeTempData() { return false; }
}

    Thanks to Json.NET’s conditional serialization functionality, the tempData member will never be serialized, so you might think you’re in the clear. But it will be deserialized if present! An attacker who decompiles your code and notices such a member will be able to craft an attack gadget payload for MyType.

And that’s just what I was able to think of off the top of my head. As you can see, verifying that, in a large object graph, there is never an attempt to deserialize a polymorphic type that is compatible with some attack gadget is substantially nontrivial. Thus I’d strongly recommend the additional protection of a custom SerializationBinder that ensures that no unexpected types are deserialized.

More Related Contents:

  1. JSON.Net throws StackOverflowException when using [JsonConvert()]
  2. How to parse huge JSON file as stream in Json.NET?
  3. Deserializing JSON Object Array with Json.net
  4. Searching for a specific JToken by name in a JObject hierarchy
  5. Unexpected character encountered while parsing value
  6. How can I deserialize JSON with C#?
  7. How to use Json.NET for JSON modelbinding in an MVC5 project?
  8. Deserialize nested JSON into C# objects
  9. Serialize Property, but Do Not Deserialize Property in Json.Net
  10. How to deserialize a JSON array into an object using Json.Net?
  11. Selectively use default JSON converter
  12. Cannot deserialize JSON array into type – Json.NET
  13. Newtonsoft Json Deserialize Dictionary as Key/Value list from DataContractJsonSerializer
  14. Get the object is null using JSON in WCF Service
  15. Modify existing object with new partial JSON data using Json.NET
  16. Accessing properties with a dot in their name
  17. json deserialize from legacy property names
  18. How to deserialize a unix timestamp (μs) to a DateTime from JSON?
  19. Json.NET JSONPath query not returning expected results
  20. Newtonsoft JsonSerializer – Lower case properties and dictionary [duplicate]
  21. How to serialize static or const member variables using JSON.NET?
  22. Why does System.Text Json Serialiser not serialise this generic property but Json.NET does?
  23. how come BinaryFormatter can serialize an Action but Json.net cannot
  24. How do I get formatted and indented JSON in .NET using C#?
  25. How to deserialize a property with a dash (“-”) in its name with NewtonSoft JsonConvert?
  26. Web API: Configure JSON serializer settings on action or controller level
  27. Serializing/Deserializing Dictionary of objects with JSON.NET
  28. Generate JSON object with NewtonSoft in a single line
  29. parsing an enumeration in JSON.net
  30. Json.Net deserialize out of memory issue

Leave a Comment