Condividi tramite

Avenues to Compromise

  • Articolo

 

Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012

Law Number Seven: The most secure network is a well-administered one. – 10 Immutable Laws of Security Administration

In organizations that have experienced catastrophic compromise events, assessments usually reveal that the organizations have limited visibility into the actual state of their IT infrastructures, which may differ significantly from their “as documented” states. These variances introduce vulnerabilities that expose the environment to compromise, often with little risk of discovery until the compromise has progressed to the point at which the attackers effectively “own” the environment.

Detailed assessments of these organizations’ AD DS configuration, public key infrastructures (PKIs), servers, workstations, applications, access control lists (ACLs), and other technologies reveal misconfigurations and vulnerabilities that, if remediated, could have prevented the initial compromise.

Analysis of IT documentation, processes, and procedures identifies vulnerabilities introduced by gaps in administrative practices that were leveraged by attackers to eventually obtain privileges that were used to fully compromise the Active Directory forest. A fully compromised forest is one in which attackers compromise not only individual systems, applications, or user accounts, but escalate their access to obtain a level of privilege in which they can modify or destroy all aspects of the forest. When an Active Directory installation has been compromised to that degree, attackers can make changes that allow them to maintain a presence throughout the environment, or worse, to destroy the directory and the systems and accounts it manages.

Although a number of the commonly exploited vulnerabilities in the descriptions that follow are not attacks against Active Directory, they allow attackers to establish a foothold in an environment that can be used to run privilege escalation (also called privilege elevation) attacks and to eventually target and compromise AD DS.

This section of this document focuses on describing the mechanisms that attackers typically use to gain access to the infrastructure and eventually to launch privilege elevation attacks. Also see the following sections:

Note

Although this document focuses on Active Directory and Windows systems that are part of an AD DS domain, attackers rarely focus solely on Active Directory and Windows. In environments with a mixture of operating systems, directories, applications, and data repositories, it is common to find that non-Windows systems have also been compromised. This is particularly true if the systems provide a “bridge” between Windows and non-Windows environments, such as file servers accessed by Windows and UNIX or Linux clients, directories that provide authentication services to multiple operating systems, or metadirectories that synchronize data across disparate directories.

AD DS is targeted because of the centralized access and configuration management capabilities it provides not only to Windows systems, but to other clients. Any other directory or application that provides authentication and configuration management services can, and will be targeted by determined attackers. Although this document is focused on protections that can reduce the likelihood of a compromise of Active Directory installations, every organization that includes non-Windows computers, directories, applications, or data repositories should also prepare for attacks against those systems.

Initial Breach Targets

Nobody intentionally builds an IT infrastructure that exposes the organization to compromise. When an Active Directory forest is first constructed, it is usually pristine and current. As years pass and new operating systems and applications are acquired, they’re added to the forest. As the manageability benefits that Active Directory provides are recognized, more and more content is added to the directory, more people integrate their computers or applications with AD DS, and domains are upgraded to support new functionality offered by the most current versions of the Windows operating system. What also happens over time, however, is that even as a new infrastructure is being added, other parts of the infrastructure might not be maintained as well as they initially were, systems and applications are functioning properly and therefore are not receiving attention, and organizations begin to forget that they have not eliminated their legacy infrastructure. Based on what we see in assessing compromised infrastructures, the older, larger, and more complex the environment, the more likely it is that there are numerous instances of commonly exploited vulnerabilities.

Regardless of the motivation of the attacker, most information security breaches start with the compromise of one or two systems at a time. These initial events, or entry points into the network, often leverage vulnerabilities that could have been fixed, but were not. The 2012 Data Breach Investigations Report (DBIR), which is an annual study produced by the Verizon RISK Team in cooperation with a number of national security agencies and other companies, states that 96 percent of attacks were “not highly difficult,” and that “97 percent of breaches were avoidable through simple or intermediate controls.” These findings may be a direct consequence of the commonly exploited vulnerabilities that follow.

Gaps in Antivirus and Antimalware Deployments

Law Number Eight: An out-of-date malware scanner is only marginally better than no scanner at all. - Ten Immutable Laws of Security (Version 2.0)

Analysis of organizations’ antivirus and antimalware deployments often reveals an environment in which most workstations are configured with antivirus and antimalware software that is enabled and current. Exceptions are usually workstations that connect infrequently to the corporate environment or employee devices for which antivirus and antimalware software can be difficult to deploy, configure, and update.

Server populations, however, tend to be less consistently protected in many compromised environments. As reported in the 2012 Data Breach Investigations, 94 percent of all data compromises involved servers, which represents an 18 percent increase over the previous year, and 69 percent of attacks incorporated malware. In server populations, it is not uncommon to find that antivirus and antimalware installations are inconsistently configured, outdated, misconfigured, or even disabled. In some cases, the antivirus and antimalware software is disabled by administrative staff, but in other cases, attackers disable the software after compromising a server via other vulnerabilities. When the antivirus and antimalware software is disabled, the attackers then plant malware on the server and focus on propagating compromise across the server population.

It is important not only to ensure that your systems are protected with current, comprehensive malware protection, but also to monitor systems for disabling or removal of antivirus and antimalware software and to automatically restart protection when it is manually disabled. Although no antivirus and antimalware software can guarantee prevention and detection of all infections, a properly configured and deployed antivirus and antimalware implementation can reduce the likelihood of infection.

Incomplete Patching

Law Number Three: If you don’t keep up with security fixes, your network won’t be yours for long. – 10 Immutable Laws of Security Administration

Microsoft releases security bulletins on the second Tuesday of each month, although on rare occasions security updates are released between the monthly security updates (these are also known as “out-of-band” updates) when the vulnerability is determined to pose an urgent risk to customer systems. Whether a small business configures its Windows computers to use Windows Update to manage system and application patching or a large organization uses management software such as System Center Configuration Manager (SCCM) to deploy patches according to detailed, hierarchical plans, many customers patch their Windows infrastructures in a relatively timely manner.

However, few infrastructures include only Windows computers and Microsoft applications, and in compromised environments, it is common to find that the organization’s patch management strategy contains gaps. Windows systems in these environments are inconsistently patched. Non-Windows operating systems are patched sporadically, if at all. Commercial off-the-shelf (COTS) applications contain vulnerabilities for which patches exist, but have not been applied. Networking devices are often configured with factory-default credentials and no firmware updates years after their installation. Applications and operating systems that are no longer supported by their vendors are often kept running, despite the fact that they can no longer be patched against vulnerabilities. Each of these unpatched systems represents another potential entry point for attackers.

The consumerization of IT has introduced additional challenges in that employee owned devices are being used to access corporate owned data, and the organization may have little to no control over the patching and configuration of employees’ personal devices. Enterprise-class hardware typically ships with enterprise-ready configuration options and management capabilities, at the cost of less choice in individual customization and device selection. Employee-focused hardware offers a broader range of manufacturers, vendors, hardware security features, software security features, management capabilities and configuration options, and many enterprise features may be absent altogether.

Patch and Vulnerability Management Software

If an effective patch management system is in place for the Windows systems and Microsoft applications, part of the attack surface that unpatched vulnerabilities create has been addressed. However, unless the non-Windows systems, non-Microsoft applications, network infrastructure, and employee devices are also kept up-to-date on patches and other fixes, the infrastructure remains vulnerable. In some cases, an application’s vendor may offer automatic update capabilities; in others, there may be a need to devise an approach to regularly retrieve and apply patches and other fixes. Although specific product recommendations cannot be made here, Appendix A: Patch and Vulnerability Management Software includes information about commercially available patch and vulnerability management software provided by Microsoft Partners.

Outdated Applications and Operating Systems

“You can’t expect a six-year-old operating system to protect you against a six-month-old attack.” – Information Security Professional with 10 years of experience securing enterprise installations

Although “get current, stay current” may sound like a marketing phrase, outdated operating systems and applications create risk in many organizations’ IT infrastructures. An operating system that was released in 2003 might still be supported by the vendor and provided with updates to address vulnerabilities, but that operating system might not contain security features added in newer versions of the operating system. Outdated systems can even require weakening of certain AD DS security configuration to support the lesser capabilities of those computers.

Applications that were written to use legacy authentication protocols by vendors who are no longer supporting the application usually cannot be retooled to support stronger authentication mechanisms. However, an organization’s Active Directory domain may still be configured to store LAN Manager hashes or reversibly encrypted passwords to support such applications. Applications written prior to the introduction of newer operating systems may not function well or at all on current operating systems, requiring organizations to maintain older and older systems, and in some cases, completely unsupported hardware and software.

Even in cases in which organizations have updated their domain controllers to Windows Server 2012, Windows Server 2008 R2, or Windows Server 2008, it is typical to find significant portions of the member server population to be running Windows Server 2003 (which is no longer in mainstream support), or even Windows 2000 Server or Windows NT Server 4.0 (which are completely unsupported). The longer an organization maintains aging systems, the more the disparity between feature sets grows, and the more likely it becomes that production systems will be unsupported. Additionally, the longer an Active Directory forest is maintained, the more we observe that legacy systems and applications are missed in upgrade plans. This can mean that a single computer running a single application can introduce domain- or forest-wide vulnerabilities because Active Directory is configured to support its legacy protocols and authentication mechanisms.

To eliminate legacy systems and applications, you should first focus on identifying and cataloging them, then on determining whether to upgrade or replace the application or host. Although it can be difficult to find replacements for highly specialized applications for which there is neither support nor an upgrade path, you may be able to leverage a concept called “creative destruction” to replace the legacy application with a new application that provides the necessary functionality. Planning for Compromise is described in more depth in “Planning for Compromise” later in this document.

Misconfiguration

Law Number Four: It doesn’t do much good to install security fixes on a computer that was never secured to begin with. – 10 Immutable Laws of Security Administration

Even in environments where systems are generally kept current and patched, we commonly identify gaps or misconfigurations in the operating system, applications running on computers, and Active Directory. Some misconfigurations expose only the local computer to compromise, but after a computer is “owned,” attackers usually focus on further propagating the compromise across other systems and eventually to Active Directory. Following are some of the common areas in which we identify configurations that introduce risk.

In Active Directory

The accounts in Active Directory that are most commonly targeted by attackers are those that are members of the most-highly privileged groups, such as members of the Domain Admins (DA), Enterprise Admins (EA), or built-in Administrators (BA) groups in Active Directory. The membership of these groups should be reduced to the smallest number of accounts possible so that the attack surface of these groups is limited. It is even possible to eliminate “permanent” membership in these privileged groups; that is, you can implement settings that allow you to temporarily populate these groups only when their domain- and forest-wide privileges are needed. When highly privileged accounts are used, they should be used only on designated, secure systems such as domain controllers or secure administrative hosts. Detailed information to help implement all of these configurations is provided in Reducing the Active Directory Attack Surface.

When we evaluate the membership of the highest privileged groups in Active Directory, we commonly find excessive membership in all three of the most- privileged groups. In some cases, organizations have dozens, even hundreds of accounts in DA groups. In other cases, organizations place accounts directly into built-in Administrators groups, thinking that that group is “less privileged” than the DAs group. It is not. We often find a handful of permanent members of the EA group in the forest root domain, despite the fact that EA privileges are rarely and temporarily required. Finding an IT user’s day-to-day administrative account in all three groups is also common, even though this is an effectively redundant configuration. As described in Reducing the Active Directory Attack Surface, whether an account is a permanent member of one of these groups or all of them, the account can be used to compromise, and even destroy the AD DS environment and the systems and accounts managed by it. Recommendations for the secure configuration and use of privileged accounts in Active Directory are provided in Reducing the Active Directory Attack Surface.

On Domain Controllers

When we assess domain controllers, we find often find them configured and managed no differently than member servers. Domain controllers sometimes run the same applications and utilities installed on member servers, not because they’re needed on the domain controllers, but because the applications are part of a standard build. These applications may provide minimal functionality on the domain controllers but add significantly to its attack surface by requiring configuration setting that open ports, create highly privileged service accounts, or grant access to the system by users who should not connect to a domain controller for any purpose other than authentication and Group Policy application. In some breaches, attackers have used tools that were already installed on domain controllers not only to gain access to the domain controllers, but to modify or damage the AD DS database.

When we extract the Internet Explorer® configuration settings on domain controllers, we find that users have logged on with accounts that have high levels of privilege in Active Directory and have used the accounts to access the Internet and intranet from the domain controllers. In some cases, the accounts have configured Internet Explorer settings on the domain controllers to allow download of Internet content, and freeware utilities have been downloaded from Internet sites and installed on the domain controllers. Internet Explorer Enhanced Security Configuration is enabled for Users and Administrators by default, yet we often observe that is has been disabled for Administrators. When a highly privileged account accesses the Internet and downloads content to any computer, that computer is put at severe risk. When the computer is a domain controller, the entire AD DS installation is put at risk.

Protecting Domain Controllers

Domain controllers should be treated as critical infrastructure components, secured more stringently and configured more rigidly than file, print, and application servers. Domain controllers should not run any software that is not required for the domain controller to function or doesn’t protect the domain controller against attacks. Domain controllers should not be permitted to access the Internet, and security settings should be configured and enforced by Group Policy Objects (GPOs). Detailed recommendations for the secure installation, configuration, and management of domain controllers are provided in Securing Domain Controllers Against Attack.

Within the Operating System

Law Number Two: If a bad guy can alter the operating system on your computer, it’s not your computer anymore. – Ten Immutable Laws of Security (Version 2.0)

Although some organizations create baseline configurations for servers of different types and allow limited customization of the operating system after it’s installed, analysis of compromised environments often uncovers large numbers of servers deployed in an ad hoc fashion, and configured manually and independently. Configurations between two servers performing the same function may be completely different, where neither server is configured securely. Conversely, server configuration baselines may be consistently enforced, but also consistently misconfigured; that is, servers are configured in a manner that creates the same vulnerability on all servers of a given type. Misconfiguration includes practices such as disabling of security features, granting excessive rights and permissions to accounts (particularly service accounts), use of identical local credentials across systems, and permitting installation of unauthorized applications and utilities that create vulnerabilities of their own.

Disabling Security Features

Organizations sometimes disable Windows Firewall with Advanced Security (WFAS) out of a belief that WFAS is difficult to configure or requires work-intensive configuration. However, beginning with Windows Server 2008, when any role or feature is installed on a server, it is configured by default with the least privileges required for the role or feature to function, and the Windows Firewall is automatically configured to support the role or feature. By disabling WFAS (and not using another host-based firewall in its place), organizations increase the attack surface of the entire Windows environment. Perimeter firewalls provide some protection against attacks that directly target an environment from the Internet, but they provide no protection against attacks that exploit other attack vectors such as drive-by download attacks, or attacks that originate from other compromised systems on the intranet.

User Account Control (UAC) settings are sometimes disabled on servers because administrative staff find the prompts intrusive. Although Microsoft Support article 2526083 describes scenarios in which UAC may be disabled on Windows Server, unless you are running a server core installation (where UAC is disabled by design), you should not disable UAC on servers without careful consideration and research.

In other cases, server settings are configured to less-secure values because organizations apply outdated server configuration settings to new operating systems, such as applying Windows Server 2003 baselines to computers running Windows Server 2012, Windows Server 2008 R2, or Windows Server 2008, without changing the baselines to reflect the changes in the operating system. Rather than carrying old server baselines to new operating systems, when deploying a new operating system, review security changes and configuration settings to ensure that the settings implemented are applicable and appropriate for the new operating system.

Granting Excessive Privilege

In nearly every environment we have assessed, excessive privilege is granted to local and domain-based accounts on Windows systems. Users are granted local Administrator rights on their workstations, member servers run services that are configured with rights beyond what they need to function, and local Administrators groups across the server population contain dozens or even hundreds of local and domain accounts. Compromise of only one privileged account on a computer allows attackers to compromise the accounts of every user and service that logs on to the computer, and to harvest and leverage credentials to propagate the compromise to other systems.

Although pass-the-hash (PTH) and other credential theft attacks are ubiquitous today, it is because there is freely available tooling that makes it simple and easy to extract the credentials of other privileged accounts when an attacker has gained Administrator- or SYSTEM-level access to a computer. Even without tooling that allows harvesting of credentials from logon sessions, an attacker with privileged access to a computer can just as easily install keystroke loggers that capture keystrokes, screenshots, and clipboard contents. An attacker with privileged access to a computer can disable antimalware software, install rootkits, modify protected files, or install malware on the computer that automates attacks or turns a server into a drive-by download host.

The tactics used to extend a breach beyond a single computer vary, but the key to propagating compromise is the acquisition of highly privileged access to additional systems. By reducing the number of accounts with privileged access to any system, you reduce the attack surface not only of that computer, but the likelihood of an attacker harvesting valuable credentials from the computer.

Standardizing Local Administrator Credentials

There has long been debate among security specialists as to whether there is value in renaming local Administrator accounts on Windows computers. What is actually important about local Administrator accounts is whether they are configured with the same user name and password across multiple computers.

If the local Administrator account is named to the same value across servers and the password assigned to the account is also configured to the same value, attackers can extract the account’s credentials on one computer on which Administrator or SYSTEM-level access has been obtained. The attacker does not have to initially compromise the Administrator account; they need only compromise the account of a user who is a member of the local Administrators group, or of a service account that is configured to run as LocalSystem or with Administrator privileges. The attacker can then extract the credentials for the Administrator account and replay those credentials in network logons to other computers on the network.

As long as another computer has a local account with the same user name and password (or password hash) as the account credentials that are being presented, the logon attempt succeeds and the attacker obtains privileged access to the targeted computer. In current versions of Windows, the built-in Administrator account is disabled by default, but in legacy operating systems, the account is enabled by default.

Note

Some organizations have intentionally configured local Administrator accounts to be enabled in the belief that this provides a “failsafe” in case all other privileged accounts are locked out of a system. However, even if the local Administrator account is disabled and there are no other accounts available that can enable the account or log on to the system with Administrator privileges, the system can be booted into safe mode and the built-in local Administrator account can be re-enabled, as described in Microsoft Support article 814777. Additionally, if the system still successfully applies GPOs, a GPO can be modified to (temporarily) re-enable the Administrator account, or Restricted Groups can be configured to add a domain-based account to the local Administrators group. Repairs can be performed and the Administrator account can again be disabled. To effectively prevent a lateral compromise that uses built-in local Administrator account credentials, unique user names and passwords must be configured for local Administrator accounts. To deploy unique passwords for local Administrator accounts via a GPO, see Solution for management of built-in Administrator account's password via GPO on the MSDN website.

Permitting Installation of Unauthorized Applications

Law Number One: If a bad guy can persuade you to run his program on your computer, it’s not solely your computer anymore. – Ten Immutable Laws of Security (Version 2.0)

Whether an organization deploys consistent baseline settings across servers, the installation of applications that are not part of a server’s defined role should not be permitted. By allowing software to be installed that is not part of a server’s designated functionality, servers are exposed to inadvertent or malicious installation of software that increases the server’s attack surface, introduces application vulnerabilities, or causes system instability.

Applications

As described earlier, applications are often installed and configured to use accounts that are granted more privilege than the application actually requires. In some cases, the application’s documentation specifies that service accounts must be members of a server’s local Administrators group or must be configured to run in the context of the LocalSystem. This is often not because the application requires those rights, but because determining what rights and permissions an application’s service accounts need requires investment in additional time and effort. If an application does not install with the minimum privileges required for the application and its configured features to function, the system is exposed to attacks that leverage application privileges without any attack against the operating system itself.

Lack of Secure Application Development Practices

Infrastructure exists to support business workloads. Where these workloads are implemented in custom applications, it is critical to ensure that the applications are developed using secure best practices. Root-cause analysis of enterprise-wide incidents often reveals that an initial compromise is effected through custom applications–particularly those that are Internet facing. Most of these compromises are accomplished via compromise of well-known attacks such as SQL injection (SQLi) and cross-site scripting (XSS) attacks.

SQL Injection is an application vulnerability that allows user-defined input to modify a SQL statement that is passed to the database for execution. This input can be provided via a field in the application, a parameter (such as the query string or a cookie), or other methods. The result of this injection is that the SQL statement provided to the database is fundamentally different than what the developer intended. Take, for example, a common query used in the evaluation of a user name/password combination:

SELECT userID FROM users WHERE username = ‘sUserName’ AND password = ‘sPassword’

When this is received by the database server, it instructs the server to look through the users table and return any userID record where the user name and password match those provided by the user (presumably via a login form of some kind). Naturally the intent of the developer in this case is to only return a valid record if a correct user name and password can be provided by the user. If either is incorrect, the database server will be unable to find a matching record and return an empty result.

The issue occurs when an attacker does something unexpected such as providing their own SQL in place of valid data. Because SQL is interpreted on-the-fly by the database server, the injected code would be processed as if the developer had put it in himself. For example, if the attacker entered administrator for the user ID and xyz OR 1=1 as the password, the resulting statement processed by the database would be:

SELECT userID FROM users WHERE username = ‘administrator’ AND password = ‘xyz’ OR 1=1

When this query is processed by the database server, all rows in the table will be returned in the query because 1=1 will always evaluate to True, thus it doesn’t matter if the correct username and password is known or provided. The net result in most cases is that the user will be logged on as the first user in the user’s database; in most cases, this will be the administrative user.

In addition to simply logging on, malformed SQL statements such as this can be used to add, delete, or change data, or even drop (delete) entire tables from a database. In the most extreme cases where SQLi is combined with excessive privilege, operating system commands can be run to enable the creation of new users, to download attack tools, or to take any other actions of the attackers choosing.

In cross-site scripting, the vulnerability is introduced in the application’s output. An attack begins with an attacker providing malformed data to the application, but in this case the malformed data is in the form of scripting code (such as JavaScript) that will be run by the victim’s browser. Exploit of an XSS vulnerability can allow an attacker to run any functions of the target application in the context of the user who launched the browser. XSS attacks are typically initiated by a phishing email encouraging the user to click a link that connects to the application and runs the attack code.

XSS is often exploited in online banking and e-commerce scenarios where an attacker can make purchases or transfer money in the context of the exploited user. In the case of a targeted attack on a custom web-based identity management application, it can allow an attacker to create their own identities, modify permissions and rights, and lead to a systemic compromise.

Although a full discussion of cross-site scripting and SQL injection is outside the scope of this document, the Open Web Application Security Project (OWASP) publishes a top 10 list with in-depth discussion of the vulnerabilities and countermeasures.

Regardless of the investment in infrastructure security, if poorly designed and written applications are deployed within that infrastructure, the environment is made vulnerable to attacks. Even well-secured infrastructures often cannot provide effective countermeasures to these application attacks. Compounding the problem, poorly designed applications may require that service accounts be granted excessive permissions for the application to function.

The Microsoft Security Development Lifecycle (SDL) is a set of structural process controls that work to improve security beginning early in requirements gathering and extending through the lifecycle of the application until it is decommissioned. This integration of effective security controls is not only critical from a security perspective, it is critical to ensure that application security is cost and schedule effective. Assessing an application for security issues when it is effectively code complete requires organizations to make decisions about application security only before or even after the application has been deployed. An organization can choose to address the application flaws before deploying the application in production, incurring costs and delays, or the application can be deployed in production with known security flaws, exposing the organization to compromise.

Some organizations place the full cost of fixing a security issue in production code above $10,000 per issue, and applications developed without an effective SDL can average more than ten high-severity issues per 100,000 lines of code. In large applications, the costs escalate quickly. By contrast, many companies set a benchmark of less than one issue per 100,000 lines of code at the final code review stage of the SDL, and aim for zero issues in high-risk applications in production.

Implementing the SDL improves security by including security requirements early in requirements gathering and design of an application provides threat modeling for high-risk applications; requires effective training and monitoring of developers; and requires clear, consistent code standards and practices. The net effect of an SDL is significant improvements in application security while reducing the cost to develop, deploy, maintain, and decommission an application. Although a detailed discussion of the design and implementation of SDL is beyond the scope of this document, refer to the Microsoft Security Development Lifecycle for detailed guidance and information.