Defenses Against IIS Attacks
Many of the attacks we have explored in this chapter have various levels of impact, depending on how IIS is implemented and the conditions present within the deployment architecture. Although Microsoft has begun to tighten down the default configuration of IIS over the last few releases, there are still considerations that should be explored before moving a freshly installed IIS server from a staging environment into a production environment. Some of these considerations are simple to address and implement and others may require a good long look at the architecture of your network and Web applications. At a minimum, organizations should review the following recommendations and implement them accordingly; however, depending on you your environment, additional considerations may present themselves.
Disable Unused Services
A basic tenet of security is to only enable services required to support business operations. Reducing the overall number of services in your network will also reduce the targets available to attackers and overall presence of vulnerabilities exponentially. Consider the following example.
Your home, apartment, or condo most likely has several doors and windows installed throughout. Most doors can be left unlocked to allow people to enter freely and windows can be left open to allow fresh air in as needed. This is most certainly a good thing in situations where the risk of a burglar walking in and stealing your personal property is minimal. However, each door left unlocked and window left open still presents vulnerabilities in your home's security posture and increased opportunities for exploitation by a burglar. The more open doors and windows, the greater chance a burglar will be able to enter the dwelling without resistance. To reduce the likelihood a burglar will walk in and steal your valuables, we close and lock windows as a precautionary measure. In comparison, the idea behind limiting the services running on you network is to reduce the likelihood an attacker will leverage them.
Although this concept seems to be easy to understand, it almost always fails in reality. Far too many times, penetration testers compromise systems due to unneeded services and are answered with a friendly, “Wow, I forgot that service was running,” or, “I didn't know that service was on by default” when informing administrators their network was compromised during a penetration test. As a simple rule, disable all services not required to support business operations and periodically verify that the services remain disabled by conducting additional vulnerability assessments and penetration tests. In general, a Web server should be dedicated to providing only Web services and not running various other pieces of software used for unrelated functionality.
Default Configurations
Default configurations can sometimes leave systems less secure than recommended when adding them to a production network. Over the last few releases of IIS, Microsoft has made some headway in securing the default configurations for IIS and some of its supporting components; however, penetration testers and attackers still find many systems deployed with default configurations in place. Many of the default configurations may only allow attackers to gain more information about the underlying operating system and other components of the IIS deployment. However, gaining information from various information disclosure-related vulnerabilities can be critical to an attacker's success with further attacks.
Some of the most common default configurations found while performing penetration tests against IIS Web servers include debugging utilities and methods, sample files, WebDAV and ISAPI extensions, and internal IP address disclosures. Although these methods, files, and extensions are implemented to provide functionality, security concerns have been identified with some of the components mentioned and they should be implemented only when needed. Disabling unnecessary components can help limit the attacks that can be performed against the IIS implementation.
Account Security
When working with securing operating systems, it is important to ensure user and service accounts that are installed by default are properly secured before implementation in a production environment. Removing user and administrative accounts can reduce the attack that surface attackers can use to attempt password guessing, dictionary, and brute force attacks against IIS.
In addition, administrators should consider renaming default accounts to make it more difficult for attackers to identify valid user accounts. To perform passwords attacks against an operating system, one of the requirements is to identify valid user account names so attackers can then try to guess passwords for them. For instance, in a default Windows installation, the default administrator level account is the “Administrator” account. If the attacker knows the default administrator level account name is “Administrator,” all he needs to do now is to perform various attacks in an effort to learn the password for the account. However, if an administrator changes the name of the “Administrator” account to something like “Rumpelstiltskin,” an attacker would first have to identify valid user names to increase his chances in being successful during password guessing attacks. It is not impossible for an attacker to learn user names; however, changing default user account names does add another layer of complexity to the attack making our IIS server a less attractive target. Using complex passwords and changing them on a routine basis is also a fundamental security recommendation while working with IIS and other services. Refer to Chapter 1, “Windows Operating System – Password Attacks,” for more information about Windows password security.
Patch Management
Ensuring operating systems and the third-party software running on them are up-to-date with security patches is one of the most important things administrators can do to help protect their network. This is apparent by the number of times this book has covered the topic as a defensive recommendation. Always stay aware of the current patch levels for your organizations software and test patches before implementing them into a production environment. Significant delays in applying security patches can significantly impact the security of your network.
alt1 Warning
It cannot be stressed enough: patching operating systems is critical in protecting your organization from deadly attacks! During penetration tests, it is common for penetration testers to identify operating systems and applications that have not been patched for months and sometimes years. Even as of the writing of this book, it is still very common to discover systems missing patches issued from more than a year ago.
A prime example of this is the MS08-067 Microsoft Security BulletinS issued in October 2008. The patch for this security bulletin has been available to the general public for quite some time and still today penetration testers and attackers are compromising systems using exploit code, readily available to anyone who wishes to use it. Leaving systems unpatched for extended periods of time allows more opportunities for attackers to discover and leverage vulnerabilities using exploits that have proven to be reliable.
Swww.microsoft.com/technet/security/Bulletin/MS08-067.mspx
In addition, large numbers of systems missing many patches is a direct indication of a patch management process that has failed. In these cases, administrators and security professionals should readdress the current patch management policy and procedures to identify the shortcomings.
Logging
Although the importance of logging is mentioned throughout this book, implementing logging is still one of the most important things an organization can do to help identify potential issues. Implementing logging of security events and performance thresholds can help provide administrators with an early warning of some common attack signatures. This is one of the fundamental concepts that allow administrators and security personnel to really know what is happening within their networks.
Segregate IIS
Reducing the amount of services available on a server running IIS will help limit the avenues an attacker can take toward compromising your Web server; however, the concept of segregation as it applies to Web servers and other Microsoft network functionality is just as important. Installing an IIS server on a dedicated server is preferred over installing IIS on a server running supporting databases, Active Directory, or other applications not directly related to the operation of the IIS server.
One of the reasons you should not install or run IIS alongside other services on the same server is because doing so increases the size of the server's exploitable footprint. Consider an IIS server that has been fully patched, hardened, and deployed on a member server without additional service running in parallel. If all of the proper steps have been taken and the server is only running the required services, it will significantly reduce the attack surface that attackers can leverage and thus increase the overall security of the server.
In cases where IIS is installed and running on the same server as databases, Active Directory, or any other network accessible service, it may be possible for attackers to leverage these other services allowing access to the IIS server and its installed Web applications. For example, an attacker attempting to compromise your organization's Web server is unable to find any vulnerability to leverage on the IIS server; however, he identifies a buffer overflow vulnerability on the SQL Server installed on the same server. The attacker is able to leverage the buffer overflow vulnerability against the SQL Server and ultimately gains access to the underlying operating system and, of course, to the IIS server. The attacker is now able to complete his initial objective of accessing the IIS server through a vulnerability identified in a database server installed on the same server. For this reason, it is important to properly segregate Web servers, databases, directory services, middleware, and other applications by installing them on separate servers.
Not only should administrators segregate services between servers but considerations should also be made to segregate the different tiers of a Web application into separate DMZ segments. In many situations, organizations will place Web, business logic, and backend databases on the same network DMZ segment. Deploying services in this manner may allow attackers to easily pivot from one server to the next if no restrictions are in place, once a DMZ host has been compromised. Figure 6.7 provides an example of how many organizations deploy services in a DMZ environment making it easy for attackers to jump from one compromised system to other within the DMZ.
FIGURE 6.7. DMZ with No Segregation
Figure 6.8 illustrates an alternate method of deploying services in a DMZ environment. Instead of grouping all of the critical assets within a single DMZ segment, administrators and architects should consider deploying systems using a tiered approach using multiple DMZs to act as buffer zones. Creating DMZs with multiple firewalls will allow finer control over the types of network traffic allowed to traverse each DMZ segment. In Figure 6.8, Firewall 1 is configured to only allow Web traffic using TCP ports 80 and 443 to connect to the Web server and drop all other traffic attempting to traverse the firewall. In addition, Firewall 2 is configured to only allow access from the Web server to the listening database ports on the database server. For an additional layer of security, the database can be configured to only accept transactions sourcing from the Web server. Even though Figure 6.8 shows an example implementation of segregation, administrators still need to take into account the trusted connection between the Web server and the database server. The purpose of Figure 6.8 is to illustrate how closely controlling traffic flows can help reduce the avenues of attack.
FIGURE 6.8. Segregated DMZ
Segregation of services and applications running on servers and controlling how trusted services communicate with each other can significantly increase the overall security of your organizations networks. Planning for deployment of Web services should account for not only the Web server itself but also the business logic and backend database components required to support the Web applications configured on the Web servers.
Penetration Testing
Deploying Internet facing Web servers without proper system configuration management and hardening can lead to unnecessary exposure to potential threats. As with any Internet facing service, it is important to validate the security of those services that are exposed to the Internet by performing external vulnerability assessments and penetration tests. Penetration tests provide a realistic view of what types of vulnerabilities may exist in your IIS deployment and the applications running on the Web servers.
Penetration testing using a third-party provider can prove to be valuable for identifying vulnerabilities before a malicious attacker has the opportunity to leverage them. Many times penetration tests by skilled testers will reveal misconfigurations and poorly implemented services that can be reported back to the organizations network security personnel and administrators. This allows the organization to quickly address the discovered issues and reduce the likelihood of vulnerabilities being leveraged. Penetration tests may be required many times in a year depending on how often the underlying platform is modified and additional functionality is added to Web applications. Conducting penetration tests on a regular basis can help identify unauthorized configuration changes or changes that were implemented by administrators and developers and not secured properly.
URLScan
Many times, attacks against Web servers and Web applications can be conducted using a standard Web browser. Modifying legitimate Web server requests can allow attackers to gain access to data or cause exceptions, providing the attacker with more information about the server and application implementation. URLScan[T] is a tool that can be configured and used by administrators to restrict certain types of HTTP requests that can be processed by an IIS server. By blocking certain types of HTTP requests, URLScan can help prevent malicious requests from being processed by the IIS server. URLScan has several nice features that make it a good choice for installing and configuring. The tool has the capability of filtering file extensions and denying specific verb names that can be called when using authoring tools such as WebDAV. In addition, the tool can also be configured to identify specific patterns in URLs and denying them from being processed by the Web server. URLScan is also capable of storing its own log files for capturing events, and URLScan features have already been built into IIS 7.0.
Thttp://technet.microsoft.com/en-us/library/dd450367(WS.10).aspx
IIS Lockdown
The IIS Lockdown tool has been provided to administrators as an easy way to help secure IIS servers by removing or disabling some of the components of IIS not required for production use. According to Microsoft's TechNet Web site,[U] the IIS Lockdown tool is not required for IIS versions 6.0 or 7.0 as these versions of IIS already have restrictions in place, which exceed the benefit the tool would provide; however, versions of IIS prior to 6.0 may still benefit from the tools use. The updated version of the IIS Lockdown tool also includes preconfigured templates that may be implemented for a variety of server roles and integrates URLScan.
Uhttp://technet.microsoft.com/en-us/library/dd450372(WS.10).aspx
Summary
IIS plays an important role in many networks today as its flexibility and ease of use has made it popular for administrators to implement. Its robust features and support for many Web development languages has also made it appealing to Web application developers who desire to deploy Web-based solutions to meet customer and organization needs. In this chapter, you explored some of the common features that make IIS a strong consideration for developers as a delivery platform.
In this chapter, you also looked into some of the attacks that can be performed against IIS and the sites being hosted on IIS servers. Several scenarios provided you with a look at some of the more common types of attacks and how they are used by an attacker to gain access to your data. These attacks provided an overview of how IIS servers can be attacked without having to use attacks that are technically sophisticated or require a lot of technical skill to perform. The simplicity of these attacks should provide you with a good idea of how simple it can be to lose full control of your Web server.
Finally, after explaining several attack scenarios, you reviewed some of the defensive considerations to help ensure IIS servers are deployed with security in mind. Some of the defensive controls include detective controls such as logging while others involved the concepts of segregation, maintenance, and predeployment hardening. Staying current with the current security threats and countermeasures can help your organization ensure a strong defense against attacks against IIS and supporting platforms. Use the knowledge gained from this chapter to assess your current implementation of Microsoft's IIS server and adjust your security posture as required to implement strong security practices.