Page 46 - MSDN Magazine, November 2017

There are other scenarios where bad actors could use the Client in an unauthorized way:
Manipulating Sensitive Data Directly: While the preceding scenario was a session hijacking attack, because the Sales Client accesses sensitive data (such as credit cards) as part of its normal operation, that data can also be seen with a debugger. Attackers could even cause the app to behave unusually or modify the data in the database.
Reverse Engineering: Attackers could also run the Client themselves and attach a debugger to discover how the Client works. Combined with the ease of decompiling .NET apps, the attackers might be able to discover exploits or other important details about the Client or Service that would help them plan an attack.
Tampering: If attackers can reverse engineer the app and access the employee’s file system, they can replace the legitimate Client with a modified one, secretly extracting or manipulating data when the employee logs in.
Other apps might be vulnerable to debuggers in different ways. For instance, an app that reports an employee’s location for purposes of tracking fieldwork could be manipulated to provide inaccurate data. Or, a game might reveal key strategic information in a debugger.
About Runtime Checks
Runtime Checks is a new feature in PreEmptive Protection - Dotfuscator Community Edition (CE), a protection tool included with Visual Studio since 2003 (bit.ly/2wB0b9g). You may know that Dotfuscator CE can obfuscate the intermediate code of .NET assemblies, but obfuscation isn’t the subject of this article. Instead, I’ll be showing how I used Runtime Checks—hereafter, just Checks— to allow the Sales Client to protect itself while it runs.
Checks are prebuilt validations Dotfuscator can inject into your .NET apps. Your apps will then be able to detect unauthorized use, like debugging or tampering. Despite the name, Checks do more than just detect these states; they can also react in pre-specified ways, such as by exiting the app. Checks can also call into appli- cation code, allowing for custom behavior based on the Check’s result. These reporting and response features are configurable per-Check, so all your apps can detect unauthorized uses in the same way, but each app can respond to that detection differently.
The code sample includes a Dotfuscator.xml config file that can instruct Dotfuscator to protect the Sales Client from unauthorized debugging and tampering. In the rest of this article, I’ll explain how I created this configuration, what choices I made, and how you can similarly configure Dotfuscator to protect your own apps.
Setting Up the Tooling
The easiest way to get started with Dotfuscator CE is to use the Visual Studio Quick Launch (Ctrl+Q) to search for “dotfuscator.” If Dotfuscator isn’t installed, an option to install PreEmptive Protection - Dotfuscator will appear; select that option and con- firm the appropriate dialogs.
Once Dotfuscator is installed, repeating this search will provide an option to launch Tools | PreEmptive Protection - Dotfuscator; select that option to begin using Dotfuscator. After some typical first-time use dialogs, the Dotfuscator CE UI opens.
Important Note: The protection described here and included in the sample requires at least version 5.32 of Dotfuscator CE. You can see what version you have installed by choosing Help | About. If you’re using an earlier version, please download the latest ver- sion of Community Edition from bit.ly/2fuUeow.
Checks are prebuilt validations Dotfuscator can inject into your .NET apps. Your apps will then be able to detect unauthorized use.
Dotfuscator operates on specialized config files that specify what assemblies it should protect and how to apply protection. Dotfus- cator starts with a new config file loaded; I adjusted it for the Sales Client using the following steps:
1. First,IsavedthenewconfigfileasAdventureWorksSalesClient\\ Dotfuscator.xml.
2. Next, I told Dotfuscator where to find the Client’s assemblies. I switched to the Dotfuscator Inputs screen and clicked the green plus-sign icon. From the Select Input browse dialog, I navigated to the AdventureWorksSalesClient\\bin\\Release directory and then clicked Open without selecting a file.
3. Dotfuscator added the whole directory as an input named Release. I expanded the tree node to verify that the AdventureWorksSalesClient.exe assembly was present.
4. Then, I made the config file portable, instead of specific to absolute paths in my environment. I selected the Release node, clicked the pencil icon and replaced the absolute path with ${configdir}\\bin\\Release. ${configdir} is a Dotfuscator macro that represents the directory holding the config file.
5. Finally, as this article isn’t concerned with the Dotfuscator code obfuscation features, I disabled them by right-clicking on the Renaming item in the Dotfuscator navigation list and unchecking Enable.
Configuring Check Injection
Dotfuscator allows you to configure Checks from the Injection screen, on the Checks tab. What choices you make for the configura- tion, however, vary depending on the kind of app you’re protecting. Rather than list all the features and settings, I’ll walk-through the choices and configuration I made for the Sales Client sample.
For the sample, I configured three Checks:
• Two Debugging Checks, which detect unauthorized use of
a debugger:
◉ A “Login” Debugging Check, to detect session hijacking
scenarios as described earlier
◉ A “Query” Debugging Check, to detect a debugger being
used to read/write sensitive data in the Client
• One Tamper Check, which detects use of a modified
application binary
42 msdn magazine
Security