Defenses Against Escalation of Privilege Attacks

At the end of the day, you ultimately need to protect your most valuable assets – your organization's data. In escalation of privilege attacks, the compromised account or application is the vehicle that delivers the attack. This means, therefore, that your layers of defense need to be laid out so that you first prevent the compromise or at least make it very difficult. Second, you will need to implement measures to prevent the attacker from doing much with the compromised account or application.

As a security professional, you can deploy the following measures on a Windows server or workstation platform to reduce the risk and impact of privilege escalation:

• Use of up-to-date antivirus software
• Patching
• Data execution prevention
• Running applications with least privilege required
• Data encryption

These measures, when deployed systematically in layers, are effective in slowing the progress of the would-be attacker. Hopefully, the attacker would become increasingly frustrated and give up or start being careless and give himself away. These measures are described in detail in the sections that follow.

First Defensive Layer: Stop the Enemy at the Gate

The first step in preventing escalation of privilege is to prevent the potential attacker from gaining a toehold in the server or service that he can use to escalate his privileges. If the door is slammed in the face of the would-be attacker and he cannot find another way in, then the attack is thwarted. Otherwise, the defenses serve to slow down the attacker, at the very least, in order to bolster defenses at another layer.

Defense at this layer begins by setting up a defensive perimeter with up-to-date antivirus software and routine scanning for viruses, rootkits, and malware. Hearkening back to the description of the defense-in-depth approach in Chapter 1, “Windows Operating System – Password Attacks,” these scanners are set up on the perimeter of your network and on each device that needs to be protected from the vandals that send these things out into the wild. The difficulty is sifting through all traffic to positively identify activities executed by the would-be attacker. If the attacker has compromised an Active Directory, database, or Web application account in your organization, any activity would be virtually indistinguishable from legitimate activities. Your perimeter defenses – human and technological – need to be attuned to watch for particular patterns of behavior. For example, your systems could be configured to watch for database access by a single user account that originates from multiple locations, such as the case where there are two simultaneous database connections with one originating from outside your network and the other originating from inside your network, or from two different network segments.

Another critical defensive activity is to reduce the attack surface by stopping, disabling, or even removing services that are unnecessary. This is one of those fundamental rules of IT security, but it can be frequently and easily ignored or applied poorly. Before a single piece of third-party software is installed, Windows XP offers 104 services depending on the edition that has been chosen and the additional Windows components that are installed; Windows Vista offers 152 potential running services and Windows 7 offers 164.^[1] The Services applet, depicted in Figure 2.6, is used to view and manage the status of installed services.

FIGURE 2.6. Managing Installed Services in Windows Vista

Since the Windows server and workstation operating systems share the same code base, there are many services that are not required or desired for a particular platform. For example, there are services that are required to run a server, which would not be required for a fully functional workstation, and vice versa. A specific example is Windows XP ships with a full version of IIS, which could turn a workstation or server into a fully functional Web server. It may not be desirable to grant individual end users to install, run, and administer their own Web servers, especially after a string of IIS exploits are published, and it is up to you to root out and patch all of these servers. Even one unpatched instance of IIS can wreak havoc on your network. Patch management will be covered in the section “Third Defensive Layer: Set the Rules for the Playground.”

To defend against the exploitation of a flaw in an unnecessary service, you will need to implement safeguards around what users can and need to do with their workstations. You need to ensure that the right services are enabled and are secured properly (for example, running with an appropriate safeguarded service account and the correct level of privilege), or you may want to go to the extent of removing the permissions required to install Windows components or simply not making the components available for installation. This can be done by preparing the deployed image with only the required services or using group policy objects and domain-level security to prevent the installation of unnecessary services.

Second Defensive Layer: Privileges Must Be Earned

There are two opposing viewpoints on the assignment of privileges to users. One extreme suggests that users should have complete access to their workstations. If there are no barriers to the activities they can perform, such as installing software, changing configuration settings, and accessing network services, they will be more productive, will require less help to do routine things, such as adding network printers and installing hardware and software, and will have the ability to learn how to do more with a computer. The other position is that users should start off with no privileges and only be granted access as they discover they need it. Ultimately the computer is a tool (owned by the organization, not the user) and the best compromise between the two is to give users only enough access to do the work they have been assigned and nothing more, which embodies the principle of least privilege. Please refer to the following sidebar for a definition. From a security point of view, this is the safest position to take and defend.

alt1 Tip

“Every program and every user of the system should operate using the least set of privileges necessary to complete the job.”²

Principle of least privilege, also known as the principle of least authority, is a principle of systems design that requires that every module in a particular abstraction layer of a computing environment must be able to access only such information and resources that are necessary to its legitimate purpose. When applied to users, this means that all users at all times should run with as few privileges as possible and also launch applications with as few privileges as possible. The best practice is to begin with users having minimal or no privilege and adding privilege only when properly authorized.

End-user accounts are not the only accounts that require careful management of privileges. It is one thing for an attacker to mount a horizontal privilege escalation from one end-user account to another in order to gain access to another set of files. It is much worse to compromise an account with elevated privileges – a vertical privilege escalation – because the potential for damage is much greater in impact and in breadth.

Privileges are not assigned just to users; applications need them as well. Applications need to be assigned specific privileges so that they are used and behave in a specific and predictable way. In addition, privileges are required to reduce the ability of buffer overrun exploits to abuse the privileges of an elevated user. If we recall attack Scenario 3, “Horizontal Escalation,” an enterprising user with too much time on his hands, not the willful, intentional attacker, changed a number in a URL and instantly had access to a colleague's information. It is certain that this is not the way the application developers intended users to make use of the application. In all likelihood, poor programming, lack of attention to secure coding best practices, and a probable lack of involvement or oversight by IT security personnel contributed to the application not having the proper “fences” around it. Proper safeguards, in the form of application privileges, would prevent this situation from occurring. Applications that work with personal information or host sensitive data need to run in their own memory spaces (please refer to data execution protection [DEP] in the next section as an example) and their users need explicitly assigned permissions that restrict their use of an application to the purpose for which it was originally intended.