|
|
A hole is any feature of hardware or software that
allows unauthorized users to gain access or increase their level of access
without authorization. I realize this is a broad definition, but it is accurate.
A hole could be virtually anything. For example, many peculiarities of hardware
or software commonly known to all users qualify as holes. One such peculiarity
(perhaps the most well known)is that CMOS passwords on IBM compatibles are lost
when the CMOS battery is shorted, disabled, or removed. Even the ability to boot
into single-user mode on a workstation could be classified as a hole. This is so
because it will allow a malicious user to begin entering interactive command
mode, perhaps seizing control of the machine.
So a hole is nothing more than some form of
vulnerability. Every platform has holes, whether in hardware or software. In
short, nothing is absolutely safe.
The Vulnerability Scale
There are different types of holes, including
Ø
Holes
that allow denial of service
Ø
Holes
that allow local users with limited privileges to increase those privileges
without authorization
Ø
Holes
that allow outside parties (on remote hosts) unauthorized access to the network
These types of holes and attacks can be rated
according to the danger they pose to the victim host. Some represent significant
dangers that can destroy the target; others are less serious, qualifying only as
nuisances.
Holes That Allow Denial of Service
Holes that allow denial of service are in category C,
and are of low priority. These attacks are almost always operating-system based.
That is, these holes exist within the networking portions of the operating
system itself. When such holes exist, they must generally be corrected by the
authors of the software or by patches from the vendor.
For large networks or sites, a denial-of-service
attack is of only limited significance. It amounts to a nuisance and no more.
Smaller sites, however, may suffer in a denial-of-service attack. This is
especially so if the site maintains only a single machine (and therefore, a
single mail or news server).
The syn_flooder attack is instigated by creating a
high number of half-open connections. Because each connection opened must be
processed to its ultimate conclusion (in this case, a time-out), the system is
temporarily bogged down. This appears to be a problem inherent in the design of
the TCP/IP suite, and something that is not easily remedied.
This hole, then, exists within the heart of the
networking services of the UNIX operating system (or nearly any operating system
running full-fledged TCP/IP over the Internet). Thus, although efforts are
underway for fixes, I would not classify this as a high priority. This is
because in almost all cases, denial-of-service attacks represent no risk of
penetration. That is, crackers cannot harm data or gain unauthorized levels of
privilege through these means; they can just make themselves nuisanances.
Still higher in the hole hierarchy (class B) are
those holes that allow local users to gain increased and unauthorized access.
These types of holes are typically found within applications on this or that
platform.
A local user is someone who has an account on the
target machine or network. A typical example of a local user is someone with
shell access to his ISP's box. If he has an e-mail address on a box and that
account also allows shell access, that "local" user could be thousands
of miles away. In this context, local refers to the user's account privileges,
not his geographical location.
sendmail
A fine example of a hole that allows local users
increased and unauthorized access is a well-known sendmail problem. sendmail is
perhaps the world's most popular method of transmitting electronic mail. It is
the heart of the Internet's e-mail system. Typically, this program is initiated
as a daemon at boot time and remains active as long as the machine is active. In
its active state, sendmail listens (on port 25) for deliveries or other requests
from the void.
When sendmail is started, it normally queries to
determine the identity of the user because only root is authorized to perform
the startup and maintenance of the sendmail program. Other users with equivalent
privileges may do so, but that is the extent of it. However, according to the
CERT advisory titled "Sendmail Daemon Mode Vulnerability":
Unfortunately, due to a coding error, sendmail can be
invoked in daemon mode in a way that bypasses the built-in check. When the check
is bypassed, any local user is able to start sendmail in daemon mode. In
addition, as of version 8.7, sendmail will restart itself when it receives a
SIGHUP signal. It does this restarting operation by re-executing itself using
the exec(2) system call. Re-executing is done as the root user. By manipulating
the sendmail environment, the user can then have sendmail execute an arbitrary
program with root privileges.
Thus, a local user can gain a form of root access.
These holes are quite common. One surfaces every month or so. sendmail is
actually renowned for such holes, but has no monopoly on the phenomenon (nor is
the problem indigenous to UNIX).
Older versions of sendmail contain a weakness in the
buffer (you will learn a little bit about the buffer/stack scenario in the
following paragraphs). As such, one used to be able to crack the system by
invoking the debug option in sendmail and overflowing the buffer. This was done
with the -d option. A similar problem surfaced regarding sendmail's
communication with the syslog daemon (another buffer overflow problem).
These types of holes represent a serious threat for
one reason: If a local user successfully manages to exploit such a hole, the
system administrator may never discover it. Also, leveraged access is far more
dangerous in the hands of a local user than an outsider. This is because a local
user can employ basic system utilities to learn more about the local network.
Such utilities reveal far more than any scanner can from the void. Therefore, a
local user with even fleeting increased access can exploit that access to a much
greater degree.
The only real comfort with respect to these types of
holes is that there is a much greater chance of identifying the offender,
particularly if he is inexperienced. If the system administrator is running
strong logging utilities, the offender will need a fair amount of expertise to
escape detection.
Most class B holes arise from some defect within an
application. There are some fairly common programming errors that lead to such
holes. One such error concerns the character buffer in programs written in C
(hence, the dreaded buffer overflow).
Rather than exhaustively treat the subject of buffer
overflows, I will briefly describe problem here. The purpose of this explanation
is to familiarize you with a rather ingenious technique of gaining unauthorized
access
Programs written in C often use a buffer. Flatly
stated, a buffer is an abstraction, an area of memory in which some type of text
or data will be stored. Programmers make use of such a buffer to provide
pre-assigned space for a particular block or blocks of data. For example, if one
expects the user to input his first name, the programmer must decide how many
characters that first name buffer will require (how many letters should be
allowed in that field, or the number of keystrokes a user can input in a given
field). This is called the size of the character buffer. Thus, if the programmer
writes:
char first_name[20];
he is allowing the user 20 characters for a first
name. But suppose the user's first name has 35 characters. What happens to the
last 15 characters? They overflow the character buffer. When this overflow
occurs, the last 15 characters are put somewhere in memory, at another address
(an address the programmer did not intend for those characters to go to).
Crackers, by manipulating where those extra characters end up, can cause
arbitrary commands to be executed by the operating system. Most often, this
technique is used by local users to gain access to a root shell. Unfortunately,
many common utilities have been found to be susceptible to buffer overflow
attacks.
Programmers can eliminate this problem through
careful programming techniques. I am not suggesting here that programmers should
provide error checking for each and every character buffer written; this is
probably unrealistic and may be waste of time. For although these defects can
certainly place your network at risk, the cracker requires a high level of skill
to implement a buffer overflow attack. Although the technique is often discussed
in cracking circles, few actually have the programming knowledge to do it.
The buffer overflow issue is nothing new; it has been
with us at least since the days of the Worm. Eugene Spafford, as I have already
noted, was one of the first individuals to conduct a purposeful analysis of the
Worm. He did so in the now-famous paper, "The Internet Worm: An
Analysis." Spafford's paper is undoubtedly the best source of information
about the Worm.
Holes That Allow Remote Users Unauthorized Access
(Class A)
Class A holes are the most threatening of all and not
surprisingly, most of them stem from either poor system administration or
misconfiguration. Vendors rarely overlook those holes that allow remote users
unauthorized access. At this late stage of the game, even vendors that were
previously not security minded have a general grasp of the terrain.
The typical example of a misconfiguration (or
configuration failure) is any sample script that remains on the drive, even
though the distribution docs advise that it be removed. One such hole has been
rehashed innumerable times on the Net. It involves those files included within
Web server distributions.
Most Web server software contains fairly sparse
documentation. A few files may exist, true, and some may tout themselves as
tutorials. Nonetheless, as a general rule, distributions come with the following
elements:
•Installation instructions
•The binaries
•In some rare cases, the source
•Sample configuration files with comments
interspersed within them, usually commented out within the code
•Sample CGI scripts
To the credit of those distributing such software,
most configuration files offer a warning regarding sample scripts. Nonetheless,
for reasons of which I am uncertain, not everyone heeds those warnings (at least
one government site recently cracked had this problem). In any case, these
scripts can sometimes provide an intruder from the void with access ranging from
limited to root.
Probably the most talked-about hole of this kind is
the vulnerability in a file called test-cgi, distributed with early versions of
the Apache Web Server distribution. This file contained a flaw that allowed
intruders from the void to read files within the CGI directory. If your test-cgi
file contained the following line, you were probably vulnerable:
echo QUERY_STRING = $QUERY_STRING
As noted in the article titled "Test-CGI
Vulnerability in Certain Setups":
All of these lines should have the variables enclosed
in loose quotes ("). Without these quotes certain special characters
(specifically `*') get expanded where they shouldn't. Thus submitting a query of
`*' will return the contents of the current directory (probably where all of the
cgi files are).
Interestingly, no sooner than this advisory (and
others like it) circulated, it was found that:
Test-CGI in the Apache 1.1.1 distribution already has
the required:
echo QUERY_STRING = "$QUERY_STRING"
However, it does not have the necessary quotes around
the
"$CONTENT_TYPE"
string. Therefore it's still vulnerable in its
default configuration.
In closing, if you are new to security, the preceding
pages may leave you with the sense that a hole is evidence of vendor
incompetence. Not so. Vendor-based holes may take a long time to fix. If the
vendor is large, this may expand into weeks or even months. Development teams in
the corporate world work much like any other body. There is a hierarchy to be
traversed. A software programmer on a development team cannot just make a
material alteration to a program because he or she feels the need. There is a
standardized process; protocols must be followed. Perhaps even worse is when the
flaw exists in some standard that is administrated by a committee or board. If
so, it may be a long, long time before the hole is fixed.
For the moment, holes are a fact of life. And there
is no likelihood of that changing in the near future. Therefore, all system and
network administrators should study such holes whenever they can. Consider it a
responsibility that goes along with the job title because even if you don't
study them, crackers will.