The Privilege Escalation Problem
Certain components of a system have trust
relationships (sometimes implicit, sometimes explicit) with other
parts of the system. Some of these trust relationships offer "trust
elevation" possibilities—that is, these components can
escalate trust by crossing internal boundaries from a region of
less trust to a region of more trust. To understand this, think
about what happens when a kernel-level system call is made by a
simple application. The kernel is clearly trusted to a much greater
extent than the application, because if the kernel misbehaves,
really bad things happen, whereas the application can usually be
killed with far from drastic consequences.
When we talk about trusted parameters we should
think in terms of trust elevation in the system. Where is a trusted
parameter being input and where is it being used? Does the point of
use belong to a region of higher trust than the point of input? If
so, we have uncovered a privilege escalation path.
Process-Permissions Equal Trust
The permissions of a process place an effective
upper limit on the capabilities of an exploit, but an exploit is
not bound by a single process. Remember that you are attacking a
system. Account for situations
when a low-privilege process communicates with a higher privilege
process. Synchronous communication may be carried out via procedure
calls, file handles, or sockets. Interestingly, communication via a
data file is free from most normal time constraints. So are many
database entries. This means you can place "logic bombs" or "data
bombs" in a system that go off some time in the future when a
certain state is reached.
Links between programs can be extensive and very
hard to audit. For the developer, this means that natural cracks
will exist in the design. Thus, opportunity exists for the
attacker. System boundaries often present the greatest areas of
weakness in a target. Vulnerabilities also exist where multiple
system components communicate. The connections can be surprising.
Consider a log file. If a low-privilege process can create log
entries and a high-privilege process reads the log file, there
exists a clear communication
path between the two programs. Although this may seem far fetched,
there have been published exploits leveraging vulnerabilities of
this nature. For example, a Web server will log user-supplied data
from page requests. An anonymous user can insert special
meta-characters into the page request, thus causing the characters
to be saved in a log file. When a root-level user performs normal
system maintenance on the log file, the meta-characters can cause
data to be appended to the password file. Problems ensue.
If We Don't Run as Administrator,
Everything Breaks!
Secure programming guides are full of references
to the principle of least privilege (see Building Secure Software [Viega and
McGraw, 2001], for example). The problem is that most code is not
designed to work with least privilege. Often times the code will
fail to operate properly if access restrictions are placed on it.
The sad thing is that many such programs could very likely be
written without requiring Administrator or root access, but they
aren't. As a result, today's software runs with way too much
systemwide privilege.
Thinking about privilege requires adjusting your
viewpoint to a panoramic, systemwide view. (This is an excellent
attacker trick that you should internalize.) Often the OS is the
essential service providing privilege and access control checks,
but many programs do not properly adhere to the least-privilege
concept, so they abuse the OS and request too much privilege (often
without being told "no"). Furthermore, the user of the program may
or may not notice this issue, but you can be assured that an
attacker will. One very interesting technique is to run a target
program in a sandbox and examine the security context of each call
and operation (something that is made easier in advanced platforms
like Java 2). Privilege problems are very likely to surface during
this exercise, and thus provide one of the richest forms of
attack.
Look for programs that write to the system
directories or registry keys (such as HKLM which stores a number of
critical Windows environment variables). These are typically run
with elevated privileges and have usually not been designed with
security in mind. Such programs are excellent exploit targets
because they yield lots of power when they break.
|
Elevated Processes That Read Data from
Untrusted Sources
Once remote access to a system has been
obtained, an attacker should begin looking for files and registry
keys that can be controlled. Likewise, the attacker should begin
looking for local pipes and system objects. Windows NT, for
example, has an object manager and a directory of system objects
that include memory sections (actual memory segments that can have
read/write access), open file handles, pipes, and mutexes. All
these are potential input points where an attacker can take the
next step into the machine. Once the border of the software system
has been penetrated, the attacker will usually want to obtain
further access into the kernel or server process. Any data input
point can be used as another toehold to climb further into
privileged memory spaces.
A setuid utility program accepts command-line
arguments. One of these arguments allows a user to supply the path
to a configuration file. The configuration file allows shell
commands to be inserted. Thus, when the utility starts up, it runs
the given commands. One example found in the wild is the UUCP (or
UNIX-to-UNIX copy program) set of utilities. The utility program
may not have root access, but may belong to a group or user context
that is more privileged than that of the attacker. In the case of
UUCP, the elevation may lead to the dialer group, or the UUCP user
account. Escalating privilege in steps will usually lead an
attacker to a root compromise (the ultimate goal).
Some programs will not allow a user-supplied
configuration file, but the systemwide configuration file may have
weak permissions. The number of vulnerabilities that exist because
of poorly configured permissions is large. A note of caution: As an
attacker, you must consider the configuration file as an obvious
detection point. A security process may monitor the target file. If
you make changes to a configuration file to gain privilege, then
you should immediately clean the file when you are finished. You
can also run certain utilities to set back file access dates. The
key is not to leave a forensic trail surrounding the file you
exploited.
|
Processes That Use Elevated
Components
Some processes are smart enough to execute user
requests as a low-privilege thread. These requests, in theory,
cannot be used in attacks. However, one underlying assumption is
that the low-privilege accounts used to control
access cannot read secret files, and so forth. The fact is that
many systems are not administered very well, and even low-privilege
accounts can walk right through the file system and process space.
Also note that many approaches to least privilege have exceptions.
Take the Microsoft IIS server, for example. If IIS is not
configured properly, user-injected code can execute the
RevertToSelf() API call and cause the code to become
administrator level again. Furthermore, certain DLLs are always
executed as administrator, regardless of the user's privilege. The
moral of the story here is that if you audit a target long enough,
you are very likely to find a point of entry where least privilege
is not being applied.
|
No comments:
Post a Comment