What We Mean by "Elevation of Privileges"

by Steve Fallin and Scott Pinzon, WatchGuard Technologies, Inc.

At the British Open, one of golf's most prestigious events, a woman guarding the official driving range performed her job diligently. On July 15, 2003, when a group of golfers arrived for practice, one of them wasn't wearing the required tournament credentials. As instructed, the guard threw her arms wide and personally blocked his way. She would not admit the uncredentialed golfer unless he could prove he had legitimate business on the range.

The guard had failed to recognize Tiger Woods, the most famous face in golf. Was she diligent, or ignorant? Brave, or stupid? We don't know, but we do know she was acting a lot like your computer.

Recent LiveSecurity editorials have explained common attack techniques, such as buffer overflows and cross-site scripting attacks. The plight of the unrecognized Tiger got us thinking about another phrase often used in LiveSecurity Information Alerts: "elevation of privilege attack." Here's what we mean by "elevation of privilege," and countermeasures you can use against such attacks.

What is "privilege"?

In security terms, we can define "privilege" as, "permission to do something, but only if there is some verification of identity." If you have the credential, you get in. If you don't have the credential, you don't.

On a computer network, identity is not necessarily "me." Identity is demonstrated by tokens normally associated with me. To the computer, "I" am my user name and password. You can enter my username and password and gain my system privileges, because the computer has no other way of recognizing me -- like the security guard at the British Open.

In your network, every application, every user, and every element (routers, firewalls, host systems, etc.) has this notion of "privilege" built in. And privilege has degrees. An application like Minesweeper does not run with the same privileges as Exchange. Someone logging in as "guest" typically cannot do everything "administrator" can. Because the mindless computer lacks intuition, it can only follow rules programmers specify. You must guard privileges, or else attackers will use the rules against you.

What is "elevation of privilege"?

"Elevation of privilege," then, is not a class of attack, as much as it is the process of any attack. Virtually all attacks attempt to do something the attacker is not privileged to do. The bad guy wants to somehow leverage whatever limited privilege he has, and turn it into higher ("elevated") privilege.

Most commonly, attackers guess or otherwise obtain the security tokens of a user who has higher privileges than the attacker. Thus, you'll often hear the term "elevation of privileges" sloppily used to mean gaining someone else's User ID. But that's just one of the ways to elevate privileges.

Typical privilege elevation techniques

How do attackers get from limited guest privileges on your system (like a visitor to your Web site) to system administrator or root privileges? By attacking any of four points:

Your physical premises
A person
An application
A "container"

The first two points require little explanation. Obviously, I need to secure my physical premises. If someone hostile can walk up to one of my consoles and start typing, all my perimeter measures are irrelevant. With regard to attacking a person, the short cut to obtaining a password is to get it through social engineering. You can read about that in numerous places, notably in The Fugitive Game: Online with Kevin Mitnick, by Johnathan Littman.

For this article, we'll spend more time on points 3 and 4.

Attacking an application

How does a software program obtain privileges? Usually, its installation script tells your system what the software needs in order to run, and the system grants the requested privileges. The system tracks what privileges are associated with each user and application by consulting a table hidden in its registry. Applications not needing extensive permissions usually run with your privileges -- that is, the privileges assigned to the user account you logged in with when you installed the applications. If you're installing them as administrator, they'll have access to more privileges than they might need.

If you're an attacker, you want to run code on the victim's machine borrowing the privileges of one of his system-level apps. You find a process that is running with greater privileges than you have, and try to mess it up. As it crashes, you do something that makes it give its privileges to you. Attackers typically use a buffer overflow to accomplish this. A skillfully designed buffer overflow interrupts the program as it executes, and makes it run additional code supplied by the attacker. The "additional code" is intended to give the attacker root-level access to the machine. Once access has been gained, the attacker often installs a set of tools, referred to as a root kit, to make future access to that machine easier and more useful. A successful buffer overflow can take an attacker from zero privileges to total control.

Attacking a "container"

The buffer overflow is just one of numerous techniques for attacking applications. Some applications have limited privileges to interact with the operating system; for example, suppose an app should write only to one specific directory. What happens if the attacker can force it to write somewhere else? In many cases, the application's notion of privileges completely shatters, and the attacker can do anything she wants.

We could write many chapters about various "elevation of privilege" techniques -- the examples above are nowhere near exhaustive. But you've grasped the general idea.

Countermeasures against privilege elevation attacks

So, what can you do to prevent Attacker X from making himself Grand Master over your network? Several things.

Review those logs

Time-consuming, tedious, and absolutely necessary for the health of your network: review your log files. Once you understand what "normal" looks like for your network, you're more likely to spot dangerous abnormalities.

What should you look for? In two words: weird stuff. Examples: You know Bob is on vacation at Disney World, and his laptop is sitting in your office, but someone keeps logging into your network as Bob. Time to investigate. If, normally, your Web server can run six weeks at a time without requiring a reboot, but it rebooted itself three times last night, some attacker may be trying to perfect his buffer overflow attack against it. If your database server is locked in a closet in your server farm but the log files report a console login attempt on that server (which has no keyboard), investigate further. Get the idea?

Keep up-to-date on patches

Another painful but necessary task. We're surprised to see the Frethem virus spreading as we write this, because it works primarily on Internet Explorer systems that have not been updated in over a year. A diligent sys admin may patch daily. Lately, advisories about buffer overflows are being reported in the popular press. You can't assume "no one knows about them." Plug all known holes.

Use passphrases

We have often advised in LiveSecurity articles, "Use strong passwords." The problem with passwords that are cryptographically strong (e.g., "1@3gg]+nP915f~") is that no one can remember them, and they're hard to type. A nice balance between that and a too-easy password (e.g., "bob") is the passphrase. Try using bits of poetry, lines from plays or movies, anything lengthy but memorable. In Star Wars: A New Hope, an embarrassed Han Solo tells his mocking sidekick Chewbacca, "Laugh it up, fuzzball." Modified slightly to "L4ugh it up, Fu22ball!" you have a strong passphrase, hard for an attacker to brute force or guess, but easy for you to live with. Pick your own favorite. Just don't read it from anything hanging near your workstation.

Manage settings aggressively

Sure, it's easier to set your firewall to permit "Any" to "all." But that's not secure. Work out a security policy that grants employees the minimum amount of access they need to do their jobs. Then set your routers, switches, and firewalls to enforce the policy. While you're at it, consider installing interdepartmental firewalls: that way, if an attacker breaks in somewhere, you've limited the damage to a smaller network segment.

Deploy server security software

WatchGuard's ServerLock software locks down vital areas on your server so that no one, regardless of privilege level, can make changes -- not even the system administrator. When you need to change something (since you are now keeping up with patches!) you turn ServerLock off briefly, make the change, then turn it back on. The attacker might still elevate his privileges somehow, but he can't do anything with those new privileges.

Further countermeasures are really up to application developers. Buffer overflows don't succeed in a well-written program. But you can't do a lot about that right now. What you can do is make sure your people use strong credentials, then protect those credentials.

Now that we've had time to think about it, we've decided that British Open security guard was someone we'd like working on our IT staff. Her stance against granting privileges to uncredentialed guests make it tough to pull an "elevation of privileges" attack against her. Her act was exemplary -- even if she did fail to recognize the world's greatest "hacker."

Copyright© 2002, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.