Assessing WCF NET.TCP Endpoint Configurations

Originally published here: https://www.optiv.com/blog/assessing-wcf-net-tcp-endpoint-configurations

Several years back, Microsoft shipped Windows Communication Foundation (WCF) as part of its .NET platform. The idea was simple: create a framework that could enable developers to write the code for a service one time only, and allow that code to run in a number of ways (SOAP/XML, REST/JSON, TCP Socket, etc.) via configuration. A developer does not need to modify code for an existing WCF service currently hosted as an XML web service when moving that service to a different type of WCF endpoint. In fact, the developer may not even be involved in that move.

NET.TCP endpoints are Microsoft’s answer to high-performance WCF communication, since there is no HTTP wrapper involved to introduce latency. This makes WCF well suited for services inside the firewall, such as server-to-server in a multi-tiered application, but less suitable for soliciting direct connections on the Internet (better to use one of the various HTTPS options instead in that scenario). NET.TCP endpoints can use one of the following security schemes (see https://msdn.microsoft.com/en-us/library/ms731316(v=vs.110).aspx for further reference):

• SecurityMode.None — In this scenario there is no authentication (authN), authorization (authZ), or transport layer encryption. This is as simple and raw as NET.TCP endpoints can get.
• SecurityMode.Transport — Transport layer encryption (TLS) is used to wrap communications between the client and server.
• SecurityMode.Message — The message itself contains credentials or digital signatures used by the remote party for authN and authZ decisions.
• SecurityMode.TransportWithMessageCredential — This is a combination of Transport and Message security settings.

With the HTTP/S based WCF endpoints, a tester can quickly determine if transport encryption and authentication are required, usually with just a web browser. However, with NET.TCP endpoints, this becomes much more difficult to enumerate.

One way to determine the security settings for the NET.TCP endpoint is to look at the web.config or app.config file associated with the deployed endpoint. However, on a blackbox penetration test, this is simply out of scope. Even if it’s in scope, WCF configurations are some of the easiest to confuse and mess up. It’s entirely possible that having the config file may generate more questions than answers.

Simply scanning the NET.TCP endpoint’s port with nmap will not yield anything other than the port is open, as the service will be custom and otherwise not completely known by nmap.

The only other way to determine the security settings for the NET.TCP endpoint is to connect to it programmatically. Typically, this requires accessing the service Metadata Exchange (MEX) URL and letting Visual Studio dynamically create a stub project with the live service as a dependency. However, if the service does not have its definition published (security teams often advise developers not to publish the MEX), then this is impossible and the tester is left to acquire a copy of the service’s “contract” and write C# code to consume it. If the “contract” for the WCF service is published but complicated, then there may be a lot of code for the tester to enumerate in order to send even a single valid request end-to-end.

Since none of those are ideal situations, I took a few minutes to create a more generic tool called WcfScan that can be used to scan and enumerate a NET.TCP WCF service’s security configuration. The code is open source and the tool can be found on GitHub: https://github.com/malcomvetter/WcfScan.

The code creates a very simple, generic service contract and attempts to connect to the supplied service endpoint URL, cycling through all of the possible security setting options. Ultimately, the generic contract will not make a successful end-to-end call to the service; however, it will work just fine for enumerating the security settings by interpreting the exceptions that the .NET framework returns. This allows the tester to focus on the results rather than write boilerplate code that is only needed for a few minutes. For the tester who is unfamiliar with development in .NET, WcfScan can help to quickly assess basic security configuration settings for a NET.TCP service binding.

Usage is simple: WcfScan.exe net.tcp://[host]:[port]/[path]

This screenshot shows WcfScan enumerating a service endpoint running over NET.TCP with no authentication:

This screenshot shows WcfScan enumerating a NET.TCP service that is wide open with no authentication, sending all of its messages in clear-text across the network:

Of course, this simply enumerates the transport and authentication settings. It does not look for any additional injection or logic flaws in the WCF service. For that, your tester will need both security and development skills.