Page 45 - MSDN Magazine, November 2017

reporting and response capabilities into your .NET apps, with little-to-no additional coding required. These Runtime Checks are an active protection measure, able to change your app’s behavior in response to a security threat, thus protecting your sensitive data.
In this article, I present a methodology for using Runtime Checks effectively, using a typical LOB app as an example. I’ll explore how an attacker can use a debugger to cause a data breach, detail how Runtime Checks can protect against this breach and discuss the role of these controls in a layered-protection approach.
Sample Solution
To help explain how a data breach can happen in a client, I’ve prepared a sample LOB solution that can be downloaded from bit.ly/2yiT2eY. Instructions for building, running and using the various parts of the solution are available in the sample code’s README.
The solution has four components:
AdventureWorks2014 Database: This is a Microsoft SQL Server database containing the Adventure Works 2014 OLTP data- base sample. You can download that sample from bit.ly/2wM0yy0.
Adventure Works Sales Service: This is an ASP.NET Web service that exposes customer data from the database, including sensitive data like credit cards. In order to make this component easier to set up, the sample code omits most security controls, but for the purposes of this article I’ll assume the service implements the following:
• Two factors of authentication—a user password and an SMS sent to the user’s phone on login
• Time-limited sessions
• SSL encryption for all requests and responses
Adventure Works Sales Client: This is a Windows Presenta- tion Foundation (WPF) desktop client that connects to the Sales Service to manipulate the customer data. This is the component
with which the article will be most concerned.
When a Sales employee runs the Client, they log in through the
e-mail addresses, phone numbers and credit cards. In a real sce- nario, customer names would also be considered sensitive, and the non-sensitive data could include things such as retail store addresses.
Data Breach with a Debugger
Debuggers are wonderful development tools. They allow you to discover critical logic errors, step through tricky control-flow scenarios and diagnose crash dumps. However, like any tool, debuggers can also be used for evil.
Let’s say that the Adventure Works intranet has a bad actor— perhaps a vindictive employee, an outside contractor, or even an external attacker who’s gained unauthorized access to the intranet. This attacker doesn’t have access to the database or Sales Service, but they can access a Sales employee’s laptop. Certainly, this is a security problem, but because the Sales Service implements two-factor authentication and the attacker doesn’t have access to the employee’s phone, the customer data should be safe, right?
Actually, no. The attacker can wait for the Sales employee to log in through the Sales Client and then, either manually or through a script, attach a debugger to the Client process. Because the Client is a .NET app, the debugger will reveal a lot of high-level informa- tion, including the session token, even if no debugging symbols (PDB files, for example) are present.
Figure 1 demonstrates this scenario. Using the WinDbg debugger (bit.ly/2sh4clf) with the Psscor4 extension (bit.ly/2hbG2kk), I dumped various .NET objects in the memory of a running Sales Client process. I eventually found the AuthToken object and dumped the value of its HashField property.
With this session token, the attacker can make authenticated requests to the Sales Service in the employee’s name. The attacker need not continue debugging or manipulating the Client; once he has the session token, he can go directly to the Web service and use the token to cause a data breach.
LoginDialog, which starts the authenticated ses- sion and opens the CustomerWindow. From this window, the employee can view and edit customer names, or open EmailWindow, PhoneWindow, or CreditCardWindow to edit a customer’s sensitive data. Some common functions are also provided in a static class named Utilities.
Application Insights: While not required to run the sample, both the Sales Service and Client can send usage and error telemetry to Application Insights. With the Runtime Checks discussed in this article, the Client’s telemetry also includes security incident reporting.
For this article, I’ll be focusing on securing the Sales Client. I’ll assume the database and Sales Service are already secured. Of course, that’s not a safe assumption to make in a real scenario, but it helps demonstrate a point: even if you “do everything right” with server security, data breaches are still possible through client software.
I will also treat customer names as non- sensitive data and instead focus on securing msdnmagazine.com
Figure 1 WinDbg Revealing a Session Token in the Sales Client
November 2017 41