SharePoint CVE-2019-0604 RCE Detection

Introduction

I decided to write this post as I did not notice any significant detection methods published publicly. In this post, a quick PoC will be demonstrated and analysis of the generated logs by the exploit will be discussed to provide detection methods for the initial stages of the attack.

If you want to read more about the exploit and how it works, I advise to read the below articles:

• https://www.zerodayinitiative.com/blog/2019/3/13/cve-2019-0604-details-of-a-microsoft-sharepoint-rce-vulnerability
• https://www.zerodayinitiative.com/blog/2019/3/13/cve-2019-0604-details-of-a-microsoft-sharepoint-rce-vulnerability

PoC Demonstration

In the above video you will see the exploit and executing remote command creating new process towards target server by sending a crafted HTTP POST request with particular URL path and payload parameter and value.

Network Analysis And Detection

As shown in the PoC video, the exploit is done through sending a crafted HTTP POST request to SharePoint web app. The following picture details the request structure. Exploit packet capture

The crafted HTTP POST packet capture has the following characteristics which also will be used for a detection:

• URI: /_layouts/15/Picker.aspx
• URI query (two URIs):
  • • PickerDialogType=Microsoft.SharePoint.WebControls.ItemPickerDialog
  • • PickerDialogType=Microsoft.SharePoint.Portal.WebControls.ItemPickerDialog
• POST payload parameter: ctl00$PlaceHolderDialogBodySection$ctl05$hiddenSpanData

The POST parameter value should contain an encoded/serialized .Net XML payload that will be loaded and might executed in target SharePoint server side depending in the value context. A malicious payload should start with double underscores “__” to get the exploit work and to force the payload reaching to XML deserialization function in SharePoint internal code, which ultimately causes remote command execution. Following figure shows SharePoint internal code to match double underscores “__” and reaching XML deserialization function.

SharePoint vulnerable code

We can detect an exploit attempt with such IDS snort rule:

alert tcp $EXTERNAL_NET any -> $SHAREPOINT_SERVERS >[80,443] (msg:"SharePoint CVE-2019-0604 RCE Exploit Attempt"; flow:established,to_server; content:"POST"; >http_method; content:"Picker.aspx?PickerDialogType=Microsoft.SharePoint"; http_uri; nocase; content:"ctl00|25|24PlaceHolderDialogBodySection|25|24ctl05|25|24hiddenSpanData|3d5f5f|";http_client_body; nocase; fast_pattern; reference:adraft.page/index.php/2019/09/14/cve-2019-0604-sharepoint-rce-forensics-analysis-and-detection-methods; sid:3000001; rev:1;)

This created IDS rule is looking for any POST request with the URI, URI query mentioned earlier above, and a “ctl00$PlaceHolderDialogBodySection$ctl05$hiddenSpanData” parameter value starts with “__”.

Testing created Snort rule against captured PCAP

You can detect the exploit attempt also through monitoring IIS or WAF logs looking for the mentioned URI and URI query as I didn’t observe any legitimate POST request with such characteristics.

Host-Based Detection

As illustrated in demonstration PoC video, a new child process created from parent processes w3wp.exe (IIS web service worker). Following figure shows process hierarchy caused by the PoC exploit (w3wp.exe > cmd.exe > calc.exe).

PoC processes hierarchy

This is caused by the instruction included within the passed encoded XML payload, which includes .NET “Process.Start” function. XML payload will loaded and interpreted by SharePoint responsible IIS worker process (w3wp.exe) and execute the intended code. The following XML example is provided.

<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="LaunchCalch" ObjectType="{x:Type Diag:Process}" MethodName="Start">
        <ObjectDataProvider.MethodParameters>
            <System:String>cmd.exe</System:String>
            <System:String>/c calc.exe</System:String>
        </ObjectDataProvider.MethodParameters>
    </ObjectDataProvider>
</ResourceDictionary>

Below figure shows Sysmon generated log by the exploit, we can use this type of Sysmon log to look for any child process created under w3wp.exe.

Exploit Sysmon log

a Sigma rule is provided for such child process detetction

title: CVE-2019-0604 RCE
status: experimental
description: Detects any child process created by IIS web service worker - CVE-2019-0604
references:
    - https://www.zerodayinitiative.com/blog/2019/3/13/cve-2019-0604-details-of-a-microsoft-sharepoint-rce-vulnerability
tags:
    - attack.initial_access 
    - attack.t1190
    - attack.t1100
author: "Mansour (@m_50)"
logsource:
    product: windows
    service: sysmon
detection:
    selection:
        EventID: 1
        ParentImage: '*\System32\inetsrv\w3wp.exe'
    condition: selection

If the above Sigma rules outputting false positive, you can focus on PowerShell and CMD as a child process as an attacker most likely will use them to execute his code. In addition, you can focus on parent process command line that contains SharePoint application pool to eliminate unrelated IIS worker processes. Below is an example for tuned Sigma rule:

title: CVE-2019-0604 RCE 2
status: experimental
description: Detects PS or CMD child process created by SharePoint IIS web service worker - CVE-2019-0604
references:
    - https://www.zerodayinitiative.com/blog/2019/3/13/cve-2019-0604-details-of-a-microsoft-sharepoint-rce-vulnerability
tags:
    - attack.initial_access 
    - attack.t1190
    - attack.t1100
author: "Mansour (@m_50)"
logsource:
    product: windows
    service: sysmon
detection:
    selection:
        EventID: 1
        ParentImage: '*\System32\inetsrv\w3wp.exe'
        ParentCommandLine: '*\system32\inetsrv\w3wp.exe -ap "SharePoint*'
        Image: 
            - '*\powershell.exe'
            - '*\cmd.exe'
    condition: selection

falsepositives:
    - not tested in production SharePoint Server, you should filter out the false postives.
level: high

Decoding And Testing XML Payload

If you acquired PCAPs and you would like to analyze the exploit payload, one way do that and test the exploit is through importing SharePoint DLL code (Microsoft.SharePoint.dll) into visual studio, to import the code you need .Net decompiler to dig into DLL code. I use dotPeek which is free and easy to install decompiler.

You need only to import the below class code of the DLL which will be used to decode the serialized XML:

SharePoint DLL (Microsoft.SharePoint.dll)

You can find that DLL after installing SharePoint server in the following path:

Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\ISAPI

After importing the class in your visual studio project, you can invoke the decode method as below:

using  Microsoft.SharePoint.BusinessData.Infrastructure;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
             EntityInstanceIdEncoder.DecodeEntityInstanceId("encoded_payload");
        }
    }
}

However, be careful as the encoded payload code will be executed in your machine. To avoid that and to look in the code I set a breakpoint in the line shown in following figure:

Debugging vulnerable code

You will find the decoded command in local variables.

You can find a sample exploit PCAP, Snort, and Sigma rules in my Github