Abusing Insecure WCF Endpoints

During this presentation, Fabius Watson, VerSprite’s Security Research Manager, will provide a high-level overview of the Windows Communication Foundation (WCF) terminals and provide a practical analysis.

Fabius will share some useful techniques and tools to identify vulnerable WCF services. In addition, he will share what to look for when analyzing decomposed .NET assemblies, including those that have been obfuscated. Lastly, Fabius will explain the exploitation of vulnerable WCF services and conclude with a demonstration of attacks against real software.

Learn more about our security research at https://versprite.com/security-offerings/research/

Transcript

1. Abusing Insecure
   WCF Endpoints
   

   View Slide

2. # whoami
   • Fabius Watson (@FabiusArtrel)
   • Security Research Manager @VerSprite
   • Interested in reverse engineering, vulnerability research,
   exploit development, and post-exploitation tactics.
   • Former SOC Analyst
   • Super 1337 #certified h4x0r OSCP, OSCE, GXPN
   

   View Slide

3. Agenda
   • High-level overview of WCF architecture
   • Exploring WCF target enumeration
   • WCF endpoint analysis workflow
   • Abuse cases for insecure WCF endpoints
   • DEMOS!
   This Photo by Unknown Author is licensed under CC BY-SA
   

   View Slide

4. Motivation
   • During an audit of Windows VPN software, VerSprite learned that
   several VPN solutions included .NET services.
   • We noticed a trend among these services of dangerous method
   exposure through insecure WCF endpoints.
   • Most of these services were started automatically as “LocalSystem”,
   which is the highest user privilege level available
   • Therefore, we investigated the possible abuse of insecure WCF
   endpoints through the use of privileged service methods.
   

   View Slide

5. What is WCF?
   • Windows Communication Foundation (WCF) is a framework created
   by Microsoft for building service-oriented applications.
   • Previously codenamed “Indigo” (2000 – 2005)
   • A set of .NET Framework APIs that simplify inter-process
   communication for developers
   • Supports TCP, HTTP, HTTPS, named pipes, PNRP, MSMQ, and Custom
   Protocols
   • WCF clients connect to WCF services via Endpoints
   • WCF services perform operations on behalf of WCF clients
   

   View Slide

6. The of WCF
   

   View Slide

7. The ABC of WCF
   •Address
   •Binding
   •Contract
   

   View Slide

8. The ABC of WCF
   •Address - An endpoint address is a unique URI used to represent
   the address of a WCF service.
   • Example:
   http://www.fabrikam.com:322/mathservice.svc/secureEndpoint
   • Scheme: http:
   • Machine: www.fabrikam.com
   • Port: 322
   • Path: /mathservice.svc/secureEndpoint
   https://docs.microsoft.com/en-us/dotnet/framework/wcf/specifying-an-endpoint-address
   

   View Slide

9. The ABC of WCF
   •Binding – Endpoint bindings define the accepted transport
   protocol and encoding scheme, and may be used to configure
   transport security.
   • System-provided Bindings:
   ,,,ationHttpBinding>,,,ng>,,,ng>,,,ContextBinding>,,,nding>
   https://docs.microsoft.com/en-us/dotnet/framework/wcf/system-provided-bindings
   

   View Slide

10. The ABC of WCF
    •Contract – Service and Operation Contracts define the services and
    methods exposed by an endpoint.
    • Service Contracts are identifiable by the ServiceContractAttribute
    attribute, and Operation Contracts by the OperationContractAttribute
    attribute.
    Example:
    [ServiceContractAttribute]
    public interface IMyContract
    {
    [OperationContractAttribute]
    public void PopulateData(ref CustomDataType data);
    }
    https://docs.microsoft.com/en-us/dotnet/framework/wcf/designing-service-contracts
    

    View Slide

11. WCF Target Enumerati n
    

    View Slide

12. Local WCF Target Enumeration
    ➢ Identifying .NET services that start as “LocalSystem”
    • The Service Control utility, “Sc.exe”, may be used to query service
    information and configuration details
    This may reveal services that
    start as “LocalSystem”, but
    there is a better way!
    

    View Slide

13. Local WCF Target Enumeration
    ➢ Identifying .NET services that start as “LocalSystem”
    • The WMI command-line (WMIC) utility may be used to query for all
    running services that start as “LocalSystem”
    • We may filter out “svchost.exe”, as it is not used by .NET services
    This approach still fails to
    confirm that results are
    .NET assemblies ☹
    

    View Slide

14. Local WCF Target Enumeration
    ➢ Identifying .NET services that start as “LocalSystem”
    • The Microsoft Common Object Runtime Execution Engine,
    “mscoree.dll”, is a key dependency for .NET applications
    • We can search the string “mscoree.dll” in service binaries using
    “wmic”, “findstr”, and a FOR loop.
    This quick and dirty
    approach is still prone to
    false positives ☹
    

    View Slide

15. Local WCF Target Enumeration
    ➢ Identifying .NET services that start as “LocalSystem”
    • We wrote a Python script uses “pefile” to check the import table of
    each service binary for “mscoree.dll”.
    This approach successfully
    identifies .NET services that
    start as “LocalSystem”
    https://github.com/VerSprite/research/blob/master/projects/wcf/dotNetServiceHunter.py
    

    View Slide

16. Local WCF Target Enumeration
    ➢ Identifying .NET services that start as “LocalSystem”
    • The Sysinternals tool “Process Explorer” may be used to visually
    identify privileged .NET applications.
    • The “Configure Color” option may be used to identify .NET
    processes. This is useful for finding potential targets at a glance.
    • The yellow background indicates
    that this is a .NET process.
    • SYSTEM .NET processes are
    usually Windows services.
    

    View Slide

17. Searching Online for WCF Targets
    • Search for applications similar to those known to use WCF
    • Search for “.NET service” or “.NET agent” and analyze results
    • Search for applications associated with WCF error messages
    
    There was no endpoint listening at {0} that could accept the message. This is often caused by
    an incorrect address or SOAP action. See InnerException, if present, for more details.
    
    

    View Slide

18. Analyzing “VulnWCFService”
    

    View Slide

19. VulnWCFService
    • VulnWCFService is a very simple WCF service that we wrote to
    demonstrate the analysis and exploitation of an insecure endpoint.
    • It’s implementation is modeled after several WCF services that
    we’ve come across in our research.
    •
    https://github.com/VerSprite/research/tree/
    master/projects/wcf/VulnWCFService
    

    View Slide

20. .NET Decompilation
    • We begin by decompiling
    VulnWCFService with “dnSpy”.
    • dnSpy is an open-source
    debugger and .NET assembly
    editor that leverages
    the “ILSpy” decompiler engine.
    

    View Slide

21. System.ServiceModel
    • References refers to the
    application’s dependencies.
    • The “System.ServiceModel”
    reference is required to build
    WCF applications.
    ➢ If a .NET service or one of it’s
    references does not include
    System.ServiceModel, it does
    not use WCF.
    

    View Slide

22. VulnWCFService Components
    • This node refers to the
    “VulnWCFService” namespace.
    • This node references an
    interface named “IVulnService”
    • This node references a class
    named “VulnService”. This class
    implements IVulnService.
    • This node references a class
    named “VulnWCFService”. This
    contains the “Main” method.
    

    View Slide

23. The Service Contract – IVulnService
    The Service Contract attribute
    exposes the IVulnService
    interface as a service contract.
    The Operation Contract attribute
    exposes “RunMe” as a contract
    method.
    

    View Slide

24. Contract Implementation – VulnService
    • VulnService implements the IVulnService service contract.
    • The “RunMe” method appends a client-supplied string to a
    command line argument for “CMD.exe”
    

    View Slide

25. VulnWCFService - Main class
    The “System.ServiceProcess”
    namespace is used to
    implement a Windows service.
    The service name is defined as
    “VulnWCFService”.
    When a Windows service is
    started, the OnStart method is
    called.
    

    View Slide

26. VulnWCFService - Main class
    • baseAddress defines the
    service’s endpoint address.
    • Scheme: “net.pipe”
    • Machine Name: localhost
    • Port: N/A
    • Path: “/vulnservice/runme”
    • A ServiceHost is created using
    our Contract and Address.
    • binding is defined as a
    NetNamedPipeBinding.
    

    View Slide

27. VulnWCFService - Main class
    • The AddServiceEndpoint method is used to prepare the WCF
    endpoint for deployment.
    • The endpoint Address, endpoint Binding, and Service Contract are
    consumed to deploy the endpoint.
    • Identify calls to this method when analyzing WCF services!
    

    View Slide

28. Building a WCF Client
    

    View Slide

29. Leveraging Proxy Libraries
    • WCF clients often reference one or more Proxy Libraries that
    includes Service Contract definitions and all required types.
    • It may be possible to reference this shared assembly in order to
    easily communicate with the associated WCF service.
    • This may greatly reduce the amount of time required to build a
    client application!
    

    View Slide

30. ServiceModel Metadata Utility Tool
    • Code for a WCF proxy may be created automatically using the
    ServiceModel Metadata Utility Tool (Svcutil.exe)
    • Metadata is consumed to generate code for a WCF proxy.
    • Services do not publish metadata by default, however “svcutil.exe”
    may generate metadata from service binaries
    

    View Slide

31. Building “EvilWCFClient”
    • It remains possible to build a WCF client without a proxy library or
    metadata.
    • We may use the information disclosed through static code analysis
    to communicate to “VulnWCFService”.
    • Very little C# knowledge is required to develop a simple WCF client.
    (Thanks Microsoft!)
    

    View Slide

32. “EvilWCFClient” - Requirements
    • As with WCF services, our client must reference “System.ServiceModel”
    • If no proxy library is available for us to reference, then we must define
    our Service Contract within the client code.
    

    View Slide

33. “EvilWCFClient” – WCF Channels
    • Channels are used to send and receive Message objects through
    the WCF channel stack, which is like a pipeline for WCF messages.
    • A Channel Factory is built using the endpoint Address, endpoint
    Binding, and Service Contract of the target service.
    • A ServiceChannelProxy is created by calling CreateChannel. This
    may be used to call the remote operations defined within the
    service contract.
    

    View Slide

34. “EvilWCFClient” – Abusing “RunMe”
    • Using our ServiceChannelProxy named “client”, we may call the
    service’s “RunMe” method. We use this to execute “calc.exe”.
    • Using Process Explorer, we can see that “calc.exe” is spawned as
    “NT Authority\SYSTEM”.
    That’s it! Now lets look at real software
    

    View Slide

35. Real W rld Vulnerabilities
    

    View Slide

36. CVE-2018-10169 (ProtonVPN)
    • ProtonVPN 1.3.3 for Windows suffers from a SYSTEM privilege
    escalation vulnerability through the “ProtonVPN Service” service.
    • This service establishes an NetNamedPipe endpoint that allows
    clients to connect and call publicly exposed methods.
    • The Connect method accepts a class instance argument that
    provides attacker control of the OpenVPN command line.
    • An attacker can specify a DLL plugin that should run for every new
    VPN connection attempt. This plugin will execute code in the
    context of the SYSTEM user.
    CVSS Score: 9.8
    

    View Slide

37. CVE-2018-10169 – Discovery
    • ProtonVPN offers a “Free limited” subscription to their VPN service.
    • After installing ProtonVPN, we were able to identify the service
    binary using “sc.exe”.
    

    View Slide

38. CVE-2018-10169 - Analysis
    • We begin our analysis by
    decompiling the service binary.
    • The “ServiceProxy” reference is
    likely to be a proxy library.
    • The “System.ServiceModel”
    reference suggests the use of WCF.
    

    View Slide

39. CVE-2018-10169 - Analysis
    • Using dnSpy’s Analyzer, we can find each use of
    System.ServiceModel.ServiceHost.AddServiceEndpoint.
    • The ProtonVPN.Service.ServiceHosts namespace of
    “ProtonVPNService.exe” uses this method in two classes.
    

    View Slide

40. CVE-2018-10169 - Analysis
    • VpnConnectionManagerProxyHostFactory.Create() calls
    AddServiceEndpoint with the following configuration:
    • Address: net.pipe://localhost/protonvpn-service/ConnectionManager
    • Binding: NetNamedPipeBinding
    • Contract: “IVpnConnectionManagerProxy”
    

    View Slide

41. CVE-2018-10169 - Analysis
    • IVpnConnectionManagerProxy is
    defined in the ServiceProxy
    reference.
    • A DuplexChannel is required, as
    this Service Contract includes a
    Callback Contract.
    • A ServiceConnectionProxy
    argument is required by the
    Connect method.
    

    View Slide

42. CVE-2018-10169 - Analysis
    • The ServerConnectionProxy class is used by ProtonVPN to store VPN
    server configuration details.
    • We control the values of the class instance we choose to pass to the
    service, including the OvpnConfigPath parameter.
    • OpenVPN’s “plugin” option may be abused to load arbitrary DLLs.
    

    View Slide

43. CVE-2018-10169 - Exploitation
    • To begin writing our exploit client, we add references to the
    service’s proxy library.
    

    View Slide

44. CVE-2018-10169 - Exploitation
    • Next, we create a DuplexChannelFactory using the service’s
    endpoint Address, endpoint Binding, and Service Contract.
    • We use a dummy implementation of VpnEventsCallback
    autogenerated by Visual Studio.
    • Finally, we call CreateChannel to return a ServiceChannelProxy.
    

    View Slide

45. CVE-2018-10169 - Exploitation
    • I wrote a DLL payload named “OpenVPN_PoC.dll” that includes
    code in DLLMain to start a bind shell listener on port 4444.
    • After adding the “plugin” option to our config file, we set it’s path as
    the OvpnConfigPath of our ServerConnectionProxy.
    

    View Slide

46. CVE-2018-10169 - Exploitation
    • Finally, we call method “Connect” using our ServerConnectionProxy
    to trigger the vulnerability
    • We use the .NET TcpClient Class to connect to the listener.
    

    View Slide

47. DEMO - CVE-2018-10169 (ProtonVPN)
    

    View Slide

48. Birds of a feather…
    •CVE-2018-10170 (NordVPN)
    •CVE-2018-10645 (VyprVPN)
    •CVE-2018-10381 (TunnelBear)
    •CVE-2018-10646 (CG6)
    • CVSS: 9.8
    • CVSS: 7.8
    • CVSS: 9.8
    • CVSS: 7.8
    

    View Slide

49. CVE-2018-13101 (KioskSimple)
    • KioskSimpleService.exe in RedSwimmer KioskSimple 1.4.7.0 suffers
    from a privilege escalation vulnerability in the WCF endpoint.
    • The exposed methods allow read and write access to the Windows
    registry and control of services.
    • These methods may be abused to achieve privilege escalation via
    execution of attacker controlled binaries.
    CVSS Score: 9.8
    

    View Slide

50. KioskSimple - Analysis
    • Decompiling the service
    binary with dnSpy, revealed
    the code to be obfuscated.
    • Metadata revealed the hint:
    “Powered by SmartAssembly
    6.11.1.354"
    

    View Slide

51. KioskSimple - Analysis
    • Searching for “SmartAssembly deobfuscator” quickly revealed the
    tool de4dot, which was quick and easy to use.
    

    View Slide

52. KioskSimple - Analysis
    • Following deobfuscation, we load the “cleaned” binary into dnSpy.
    • dnSpy’s Analyzer reveals that the AddServiceEndpoint method is
    used in namespace 0, class 0, method 0 of “KioskSimpleService”.
    

    View Slide

53. KioskSimple - Analysis
    • Reviewing this call quickly reveals the service’s endpoint Address,
    endpoint Binding, and Service Contract.
    • Address: net.pipe://localhost/KioskSimple/PipeRegistry
    • Binding: NetNamedPipeBinding
    • Contract: “IRegistryService”
    

    View Slide

54. KioskSimple - Analysis
    • There are several interesting methods
    exposed by RegistryService:
    • ChangeLocalMachingRegistryValue
    • StartService
    • StopService
    • These methods may be abused to
    elevate privileges on the local machine.
    

    View Slide

55. KioskSimple - Exploitation
    • Attack Plan:
    • Populate our target service’s “ImagePath” key with a target
    application using ChangeLocalMachineRegistryValue
    • Call StopService to stop our target service if it is already running
    • Call StartService to start our target service, executing our
    application as SYSTEM.
    • Parameters must be TripleDES encrypted and base64 encoded ☹
    • Thankfully, the key is hardcoded into the application
    

    View Slide

56. KioskSimple - Exploitation
    • After referencing KioskSimple’s cryptographic library, we may use
    the “Encryptor” class to encrypt each of our argument values.
    

    View Slide

57. DEMO - CVE-2018-13101 (KioskSimple)
    

    View Slide

58. WCF RCE 0-day
    • Using the techniques discussed throughout this presentation, we
    discovered a WCF RCE 0-day in a popular commercial bandwidth
    performance and fault management application.
    • This service exposes an insecure remote endpoint using the
    NetTcpBinding.
    • I managed to find this 0-day while preparing for Ekoparty
    • Follow @VerSprite on twitter for release details
    

    View Slide

59. WCF RCE 0-day - Analysis
    • One of the service’s many WCF endpoints exposes a method
    named “InvokeActionMethod”.
    • One of the Action Methods defined is named…
    “ExecuteExternalProgram”
    

    View Slide

60. WCF RCE 0-day - Analysis
    • The service requires password authenticated transport …
    • However, the password is simply a hash of the username
    

    View Slide

61. WCF RCE 0-day - Exploitation
    • This vulnerability is essentially a remote variant of the “RunMe”
    method in “VulnWCFService”.
    • I decided to exploit this method with a powershell reverse shell.
    

    View Slide

62. DEMO – WCF RCE 0-day
    

    View Slide

63. Mitigations?
    • Avoid exposing potentially dangerous operations
    • Securely program any operations exposed
    • Require proper endpoint authentication
    • Run as LocalService instead of LocalSystem
    

    View Slide

64. Conclusion
    • WCF Endpoint Abuse is a very ripe vulnerability class.
    • It’s easy to analyze; managed code is simple to decompile.
    • It is easy to exploit; there’s no memory corruption involved.
    • Hunt for WCF Endpoint Abuse Vulns!
    

    View Slide

65. View Slide