Abstract
Creating a threat model and performing security code reviews play a significant role in improving the security quality of an application. As part of that effort it is imperative to ensure that architects, developers and testers pay careful attention to configuration management issues during the design and development of an application rather than leave it to administrators at deployment.
Introduction
In earlier articles we have discussed the need for threat modeling and code review. Threat modeling helps us model the system as an attacker would see it while still leveraging intimate knowledge of the design and architecture to make intelligent and perhaps more importantly conscious risk management decisions. Security code inspections take that one step further by attempting to look for design and architectural flaws as well as language specific implementation bugs.
The summer article on security code inspections mentioned eight vulnerability categories. In a series of articles we will now go further in depth into each of those categories seeing examples of both bad and good practices and specific recommendations of what to look for as a reviewer and how to prevent problems as a architect or developer.
This - the first of these articles – will cover the often ignored but broad and important category of configuration management. We will follow this with articles on cryptography, authentication, authorization, user and session management, data validation, exception management and auditing and logging.
Configuration Management – Shared Responsibility
Configuration management issues have traditionally been associated with administrators and deployment experts to handle. As a consequence little to no attention is paid to this broad category during design and development. Architects and developers often mistakenly assume this task is not important during the initial phases of the development lifecycle and decide it is best left for the deployment phase. On the other hand, administrators and security personnel are very rarely if ever included in early product design and architecture discussions. When security personnel and administrators are not involved early in the lifecycle, developers often make assumptions that do not reflect the real-world deployment conditions for the application. Further when the developers, security personnel and administrators realize the problems, it is often too late to correct the code, therefore compromises are made by all parties which often severely impacts the security of the application. Perhaps the best example of this is the choice of process accounts. Generally speaking, developers write and test code while running as administrators on their local machines. Hence, most operations “just work”. In production environments on the other hand, security policies and standards often demand that the application run as a low privileged user. Hence, during application deployment all hell breaks lose and a blame game ensues when the application fails to operate correctly due to a lack of permissions. In our experience from having performed dozens of security reviews we have seen the business needs to get the application released generally triumph over security posture. Consequently, the application is deployed and run as a high privileged user and therefore in an insecure configuration. If the security personnel, administrators and development teams coordinated early in the lifecycle this issue could have been handled before writing a line of code, saving time, money and potential security breaches.
For instance, if the developers of the above application were creating temporary files under the program files directory e.g. /opt/appname or C:\Program Files\appname, simply moving those files to the /tmp directory in UNIX or the All Users profile directory on Windows could eliminate one dependency for super-user privileges. As implied above however, this is a choice most developers and architects would rather make early in the application’s life. To prevent such problems from manifesting themselves, an often recommended, but rarely implemented, best practice is to ensure developers write code at the same privilege level at which the code is expected to run. This forces developers to make informed and well thought-out decisions with respect to permissions their code requires to run successfully in production.
Configuration Management & Security
With that said, what are some of the key configuration management issues that development teams should focus on to improve the security of their code?
Fundamentally, most configuration management issues come down to access control decisions. As the example above indicates, it is important to determine early in the software development lifecycle (SDLC) what privileges each of the applications processes will run under. This simple “Know Your Deployment Security Context” pattern impacts not only the choice of APIs but can significantly impact application design through the notion of privilege separation. While this concept will be explained in detail in a future article, a short description is in order here. Privilege separation, or compartmentalization, allows developers to separate those operations and tasks that require elevated privileges and place them in a separate executable. This eliminates the need for running the entire application with super-user privileges. For instance, within the .NET framework, it is strongly recommended to run your ASP.NET applications in a partial or medium trust environment in order to protect the underlying host as well as other web applications hosted on that machine. However, some operations such as reading and writing to certain parts of the file system might need full trust. A recommended approach here leverages privilege separation to place those operations needing full trust into a library which is then installed into the GAC. Highly privileged operations must be extremely well reviewed for security flaws to ensure they cannot be compromised. Configuration management decisions must account for what the user / process identity is as well as the executing code’s identity. For instance, even though the user running the application has unrestricted access to the local file system, code identity permissions may restrict an application running from the Internet zone to just read access and that to only within a specific directory. In the .NET framework these decisions can be made fairly intuitively using the configuration tools that ship as part of the framework. However, in order to make the correct decisions it is critical that both developers, who make choices regarding API usage, and administrators, who enforce runtime policies, are on the same page from day one.
Controlling access to administrative interfaces is another critical configuration management decision. In most cases, access to administrative services should not be allowed over the Internet and may be locked down even further using technologies such as IPSEC. Multi-factor authentication mechanisms such as RSA SecureID are also often used to enhance access control to such interfaces. These stronger authentication mechanisms rely on more than just a username / password combination to authenticate the user to the application. However, while the administrative interface is perhaps the most powerful piece of an application, in our experience it is tested the least! Even when administrative interfaces are tested, rarely does the development team take into account the deployment scenarios and complex authentication mechanisms describe above.
Access to configuration stores such as databases and configuration files (e.g. web.config or web.xml) must be carefully controlled. These often contain information such as credit card numbers, passwords and access control information that represent the most critical assets in the system and are therefore often the target of an attack. As recent experience has shown us, the consequences of a leak can have a severely damaging effect not just on the application itself but on the business as a whole.
Another instance where configuration management decisions are critical to the security of the application is with log files. Auditing and logging can be a tremendously powerful tool for debugging problems, investigating security incidents (forensics), enforcing non-repudiation and identifying and preventing future attacks. However, the effectiveness of log files is only as reliable as the access controls applied to them. For instance, most attackers will tell you one of the first things they do after they have compromised a system is to figure out if they can subvert the logging mechanisms to clear their traces and avoid possible prosecution. For standard applications and operating system based logging, “log wipers” are a standard part of the hacker toolkit. If an attacker is able to modify or delete logged information, the information in the log files can no longer be trusted, and therefore is not useful for non-repudiation or forensics on the hacked application.
In general, all resources used by an application must have a well defined and accepted access control policy around them. This is true for not only file system based resources such as configuration and log files but also for registry keys, database tables as well as the application executables and plugins themselves.
With regards to the cryptography used for encrypting sensitive information, hashing passwords for storage and using digital signatures for integrity, configuration management again plays an significant role. If SSL is to be used then it is important that all testing activities take this into account. This includes which cipher suites are used and the key lengths. For secure cryptographic key management, it is important that the keys are stored in well protected locations through the use of appropriate access control mechanisms. Consider, for instance, the use of the Microsoft Data Protection API (DPAPI) which leverages the underlying Windows password infrastructure to avoid explicit key storage. On the Java side, the Java KeyStore object can be used to store keys securely using PKCS #12. Hardware and third party software alternatives are also available. Keystores, the passwords used to access the stores and other files that store keys must obviously be strongly protected. Keys should never be placed inline in the source code or even in configuration files, developers must always assume that secrets stored in code or configuration files will be compromised. When cryptographic keys are being exchanged, again it is important to ensure that this is done using tried and tested mechanisms such as Diffie-Hellman or RSA and that thus transport security is guaranteed for the key exchange. Similarly, a clear strategy must be in place to deal with issues such as key revocation and expiry. Certification revocation lists can be leveraged if a public key infrastructure is in place.
Configuration management decisions can also control and limit unauthorized information disclosure. Most web servers and application server frameworks allow administrators to display generic error messages irrespective of how the individual applications deal with errors and exceptions. Similarly, administrators can help prevent application level trace information from being displayed to the end-user. With the .NET 2.0 framework, the health monitoring feature can also be controlled through the web.config and is therefore another instance of a security sensitive configuration management issue.
Configuration management issues also appear within the application itself. For instance, in the .NET framework it is important to check whether web application’s web.config is overriding any settings from the machine.config. The allowOverride directive in the machine.config file can prevent precisely this from happening when set to false. This is one of many instances where developers and administrators must work together to ensure that functionality and security are balanced given the risk posture of the organization and the business application at hand.
A number of configuration management issues are more heavily influenced by the development team with input and help from administrators. Specifically, with regards to the .NET framework code access security policies can be used to define what an application, as well as specific users and roles within the application, can or cannot do. Such code access security policies have to be replicated within production environments. Similarly, configuration settings such as validateRequest – which is meant to prevent cross-site scripting attacks in ASP.NET applications - and EnableViewStateMac – used to detect data tampering attacks – must be turned on in the web or machine configuration files.
Finally, it is important to have a clear understanding of how the application will deal with third-party add-ons or plugins, patches and updates. These could be to correct security, add functionality or fix other types of bugs. Updates to the underlying platform or operating system must be tested in pre-production environments to ensure they do not impact or break functionality. If and when such updates do have an adverse impact, a clear strategy must exist to safeguard the system while still maintaining business function. A number of applications had to deal with this precise issue due to the many changes designed to improve security in Microsoft Windows XP Service Pack 2. The only correct solution there was to use the extensive Microsoft documentation that preceded the release to prepare for it. Updates to the application itself, if handled through an auto-update mechanism, must ensure that the mechanism is bullet-proof and cannot be subverted through techniques such as DNS spoofing. Digital signatures present a potentially effective solution to this problem. Similarly with third-party plugins some kind of certification mechanism is strongly recommended to prevent unauthorized malware. In general, the application must have an effective mechanism to validate the integrity of patches as well as add-ons and should be able to prevent malicious code from being injected into the application.
Summary
Configuration management issues impact all parts of an application from access control to cryptography and from authentication to auditing and logging. Some of these issues are so fundamental that a change necessitates the complete re-architecture and design of the application. With that in mind it is critical to deal with such issues early in the SDLC in order to avoid late and costly changes to the code base or highly insecure configuration compromises as an alternative.