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
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
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
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.
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
6. The of WCF
7. The ABC of WCF •Address •Binding •Contract
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
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: <basicHttpBinding>,<wsHttpBinding>,<wsDualHttpBinding>,<wsFeder ationHttpBinding>,<netHttpBinding>,<netHttpsBinding>,<netTcpBindi ng>,<netNamedPipeBinding>,<netMsmqBinding>,<netPeerTcpBindi ng>,<msmqIntegrationBinding>,<basicHttpContextBinding>,<netTcp ContextBinding>,<webHttpBinding>,<wsHttpContextBinding>,<udpBi nding> https://docs.microsoft.com/en-us/dotnet/framework/wcf/system-provided-bindings
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
11. WCF Target Enumerati n
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!
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 ☹
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 ☹
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
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.
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 <data name="EndpointNotFound" xml:space="preserve"> <value>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.</value> </data>
18. Analyzing “VulnWCFService”
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
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.
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.
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.
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.
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”
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.
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.
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!
28. Building a WCF Client
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!
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
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!)
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.
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.
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
35. Real W rld Vulnerabilities
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
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”.
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.
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.
40. CVE-2018-10169 - Analysis • VpnConnectionManagerProxyHostFactory.Create() calls AddServiceEndpoint with the following configuration: • Address: net.pipe://localhost/protonvpn-service/ConnectionManager • Binding: NetNamedPipeBinding • Contract: “IVpnConnectionManagerProxy”
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.
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.
43. CVE-2018-10169 - Exploitation • To begin writing our exploit client, we add references to the service’s proxy library.
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.
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.
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.
47. DEMO - CVE-2018-10169 (ProtonVPN)
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
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
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"
51. KioskSimple - Analysis • Searching for “SmartAssembly deobfuscator” quickly revealed the tool de4dot, which was quick and easy to use.
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”.
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”
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.
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
56. KioskSimple - Exploitation • After referencing KioskSimple’s cryptographic library, we may use the “Encryptor” class to encrypt each of our argument values.
57. DEMO - CVE-2018-13101 (KioskSimple)
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
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”
60. WCF RCE 0-day - Analysis • The service requires password authenticated transport … • However, the password is simply a hash of the username
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.
62. DEMO – WCF RCE 0-day
63. Mitigations? • Avoid exposing potentially dangerous operations • Securely program any operations exposed • Require proper endpoint authentication • Run as LocalService instead of LocalSystem
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!