Question on assessment - Value cannot be null.Parameter name: type about ysoserial.net HOT 6 CLOSED

You need to be able to control the object type in this case. Please have a look at https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf

from ysoserial.net.

Hello, thanks for the response - I think that is the problem, how can I determine whether or not that is the case without access to the source code? I have used payloads and tried all sorts of intelligent fuzzing to try and determine that. Are there any additional detection methods I can use to see if I can control the object type? I have reviewed that document previously and any other documentation I can find related to the JavaScriptSerializer as shown above.

from ysoserial.net.

Reading the stacktrace it seems you are dealing with a JavaScriptSerializer here. Not much you can do other than trying some payloads to see whether you can get a DNS request back for example. It is probably not vulnerable as you have tried it all.

Here are my notes on this one based on reading the articles:

This should not be vulnerable by default. However, it can become vulnerable when a resolver is used that can allow dangerous types. An example of this resolver is SimpleTypeResolver that can be seen in: https://referencesource.microsoft.com/#System.Web.Extensions/Script/Serialization/SimpleTypeResolver.cs,7b048d54a7d79e87

The following code therefore will be vulnerable:

JavaScriptSerializer jss = new JavaScriptSerializer(new SimpleTypeResolver());
var json_req = jss.Deserialize<int>(payload);

The following code will not be vulnerable:

JavaScriptSerializer jss = new JavaScriptSerializer();
var json_req = jss.Deserialize<int>(payload);

This feature can make JavaScriptSerializer without a resolver an ideal choice as a secure serialiser.

from ysoserial.net.

@Himself132 what is the payload you are using? by the stacktrace it seems you are sending a null __type

from ysoserial.net.

@pwntester - hey just wanted to give an update, I actually got remote code execution. They are using LINQ which is dynamic. The following payload worked, interestingly enough it still just shows a generic error message and gives no indication of exploit other than the out of band feedback dns call.

So i guess the question is, would there have been a detection payload that would've worked here? In case there is a dictionary for deserialization issues i could add a payload to? Or are we stuck with the out of band detection which can be problematic from a false positive perspective?

The original payload was FREDDY just sending

{"__type":""}

the exploit for RCE was

as referenced in this link

https://insinuator.net/2016/10/linq-injection-from-attacking-filters-to-code-execution/

from ysoserial.net.

Thank you for showing the PoC and how it works. This is very interesting but it is not related to serialization as far as I can see.

We will need another extension to find this kind of issues - perhaps it should be added to Burp Suite scanner engine itself.

from ysoserial.net.