Configuration Files, XCOPY Deployment, and Security

Over the course of the last ten years, Microsoft® has revised its approach to storing application settings at least three times. Originally (in Windows® 3.0), application settings were stored in INI files. When Windows® NT® 3.5 and Windows® 95® were released, the Windows® registry became the storage media of choice. Finally, in .NET Framework Microsoft® made a 180-degree turn and introduced configuration - .config - files, which are nothing more than old-style INI files wrapped in fancy XML format. If the history repeats itself, the next Microsoft® move will be back to the registry (or its equivalent), but in the meantime application developers are advised to store application settings in configuration files.

The move to configuration files was probably triggered by the Microsoft's desire to make application deployment easier. Inability to install applications by simply copying files (or what is known as XCOPY deployment) has long been a concern for system administrators, and apparently Microsoft® decided to address it. It must be said though that moving application settings from the registry to configuration files only enables XCOPY deployment for the simplest applications, such as applications which do not require installation of Windows® services or configuration of virtual directory settings; other applications still need certain setup or configuration steps to be performed directly on the machines where they are installed. Nevertheless, even though configuration files do not provide the comprehensive XCOPY deployment solution, they are currently embraced by developers and administrators alike.

Although, configuration files offer certain advantages over the registry (such as ease of programmatic read access), they are not by any means perfect. For example, saving application settings to a configuration file programmatically is more complicated than using the registry. Security is yet another area of concern.

Security issues

There are two major problems with configuration files related to security. First, configuration files are a little easier to access than the registry. Because configuration files may need to be read by applications running with limited privileges (such as Web applications running as ASPNET, IUSR_Machine, or IWAM_Machine), they normally have unrestricted read permissions. This means that configuration files can be easily copied giving a hacker a slightly better chance to succeed in compromising security, especially if the application settings contain sensitive information, such as connection strings, encryption keys, or passwords. This is not the main problem, though, since the registry can also be hacked.

The main security problem relates to how sensitive settings are stored in configuration files. In fact, it is more related to XCOPY deployment than to configuration files per se, because the problem here is not as much as where sensitive data are stored - the registry, configuration file, or somewhere else - but how these data are protected. Assuming that sensitive settings are encrypted (storing sensitive information in plain text is a serious security violation), the question is: who, where, and how must be allowed to decrypt the data. XCOPY deployment scenario assumes that a sensitive application setting can be encrypted on machine X, saved in a configuration file, which is copied to machine Y, and then decrypted (on machine Y). While this capability - encrypting data on one system and decrypting on any other system - can make an application administrator responsible for deployment happy, it should also raise concern for security professionals.

The problem here is that if one of these other systems (say machine Y) happens to belong to a hacker who manages to copy application files from the compromised system X, there will be little to stop him from decrypting data. For example, if the compromised ASP.NET application stores encrypted connection string in configuration file, the hacker can add a simple page (ASPX file) and use reverse-engineered application logic to get the decrypted value. Depending on how good (or bad) functions handling encryption, decryption, and key management are implemented, this may require more (or less) effort, but in the worst case, the hacker may be able to get the plain text values by using the compromised configuration file in his own application. This is very dangerous, and this risk will always be present in applications distributed via simple XCOPY deployment.

Addressing the problem

To reduce - if not eliminate - the security risk described above, implementation of cryptographic functions must be machine-specific. In the other words, a sensitive application setting encrypted on machine X should not be decryptable on an arbitrary machine Y. Given the software and hardware capabilities available at the time of this writing, the best way of accomplishing this would be by requiring an administrator to define a machine-specific key and protecting this key using security features provided by the operating system (such as DPAPI).

In this scenario, the hacker will not be able to get the plain text value after copying configuration settings (and application files) from the compromised system to his machine. This means that after the application is deployed to the target system (via XCOPY or some other installation method) all sensitive data must be defined (or redefined) locally. This inconvenience can be addressed by using a shared secret key between machines belonging to the same server farm so that after the key is defined on all systems, the configuration settings can be shared between all of them, but it would still require an administrator to perform a manual step of defining this key during server build, application installation, or both. And it assumes that the machine-specific key is adequately protected on every system on the server farm. The bottom line here is that this is a relatively minor inconvenience, which is justified by improved security, and avoiding this inconvenience by using pure XCOPY deployment option can pose a serious security vulnerability.

Conclusion

Whether storing application settings in the Windows® registry or configuration files, you have to consider security implications. It is important to understand that sensitive settings, which can be encrypted on one machine and decrypted on any other system, are not sufficiently protected. Addressing this problem is not easy, but it can and should be done if application security is important to you. To see how this issue can be solved, please read the Authentication, Authorization, and Key Management topics in the Security chapter of CipherSafe.NET User's Guide (you can get it from the Help Files section of the Downloads page). These topics illustrate how CipherSafe.NET handles this problem and may offer you some ideas how to approach it.