Network and Host Misconfigurations
One of the biggest drivers behind security breaches is the misconfigurations of the targets.
This can bring down any site at any time, regardless of the security
measures taken. (For example, when the Justice Department server was
cracked, DOJ was running a firewall. As they discovered, a misconfigured
firewall might as well be no firewall at all.)
Misconfiguration can occur at any point along the
distribution chain, all the way from the factory to your office. For
example, certain network utilities, when enabled, open serious security
holes. Many software products ship with these utilities enabled. The
resulting risks remain until you deactivate or properly configure the
utility in question.
A good example would be network-printing utilities. These
might be enabled in a fresh install, leaving the system insecure. It's up
to you to disable those utilities. However, in order to disable them, you
first have to know of their existence.
Seasoned network administrators laugh about this. After
all, how could anyone be unaware of utilities running on their box? The
answer is simple: Think of your favorite word processor. Just how much do
you know about it? If you routinely write macros in a word-processing
environment, you are an advanced user, one member of a limited class. In
contrast, most people use only the basic functions of word processors:
text, tables, spell check, and so forth. There is certainly nothing wrong with this approach.
Nevertheless, most word processors have more advanced features, which are
often missed by casual users.
Note
There is an often-quoted axiom in computing publishing
circles, and it goes like this: "Eighty percent of the people use only
twenty percent of a program's capabilities."
For example, how many readers that used DOS-based
WordPerfect knew that it included a command-line screen-capture utility? It
was called Grab. It grabbed the screen in any DOS-based program. At the
time, that functionality was unheard of in word processors. The Grab
program was extremely powerful when coupled with a sister utility called
Convert, which was used to transform other graphic file formats into *.wpg files, a format suitable for
importation into a WordPerfect document. Both utilities were called from a
command line in the C:\WP
directory. Neither were directly accessible from within the WordPerfect
environment. Despite the power these two utilities possessed, they were not
well known.
Similarly, users might know little about the inner
workings of their favorite operating system. For most, the cost of
acquiring such knowledge far exceeds the value. Oh, they pick up tidbits
over the years—perhaps they read computer periodicals that feature
occasional tips and tricks, or perhaps they learn because they are required
to at their job or another official position where extensive training is
offered. No matter how they acquire the knowledge, nearly everyone knows
something cool about their operating system.
Keeping up with the times is difficult, though. The
software industry is a dynamic environment, and users are generally two
years behind development. This lag in the assimilation of new technology
only contributes to the security problem. When an operating system develop
ment team materially alters its product, many users are suddenly left
knowing less. Microsoft Windows 95 is a good example. When it was released,
95 had new support for all sorts of different protocols—protocols with
which the average Windows user wasn't familiar (and migrating to a
Registry-based system was quite a leap). It is possible (and probable) that
users can be unaware of obscure network utilities.
That's one scenario. Utilities and services are enabled,
and this fact is unknown to the user. These services, while enabled, can foster security holes of varying
magnitude. When a machine configured in this manner is connected to the
Net, it is a hack waiting to happen.
Such problems are easily remedied. The solution is to turn
off (or properly configure) the offending utility or service. Typical
examples of this type of problem include the following:
·
Network printing utilities
·
Remote system-configuration utilities
·
File-sharing utilities
·
Default passwords
·
Sample CGI programs and scripts
Of the examples listed, default services (i.e. file
sharing, printing, or Web-based sample scripts) with known vulnerabilities
are the most common. There is also the reverse situation. Instead of being
unaware of active services that threaten your security, you might be
unaware of inactive utilities that could strengthen your security.
Many operating systems have built-in security features.
These features can be quite effective when enabled, but remain worthless
until you activate them. Again, it
boils down to knowledge. If you're lacking in knowledge, you are bound to
suffer needlessly.
But, unfortunately, it doesn't end there. There are other
problems facing the modern network administrator. For instance, certain
security utilities are simply impractical. Consider security programs that
administrate file-access privileges and restrict user access depending on
security level, time of day, and so forth. Perhaps your small network
cannot operate with fluidity and efficiency if advanced access restrictions
are enabled. If so, you must take that chance, perhaps implementing other
security procedures to compensate. In essence, these issues are the basis
of security theory: You must balance the risks against practical security
measures, based on the sensitivity of your network data.
You'll notice that most network security problems arise,
however, from a lack of education. For that reason, education is a
recurring theme throughout this book.
Note
Education issues are entirely within your control. That
is, you can eliminate these problems by providing yourself or your associates with adequate education.
(Put another way, crackers are most effective at gaining entry into
networks where such knowledge is lacking.)
Operating System and Application Flaws
As if the complexity surrounding advanced security features combined with the fact that operating
systems are shipping with dozens of enabled services weren't enough of a
problem, we face an additional challenge: vulnerabilities introduced by
flawed programming. Unfortunately, these forces are well beyond your
control. That's too bad because here's a fact: Vendor failure is one of the
most common sources of security problems. Anyone who subscribes to a bug or
security mailing list (such as BUGTRAQ) knows this. Every day, bugs or
programming weaknesses are found in network software. Every day, these are
posted to the Internet in advisories or warnings. Unfortunately, not all
users read such advisories.
System flaws needn't be classified into many subcategories
here. It's sufficient to say that a system flaw is any flaw that causes a
program to do the following:
·
Work improperly (under either normal or extreme conditions)
·
Allow crackers to exploit that weakness (or improper
operation) to damage or gain control of a system
There are two primary types of system flaws. The first
type, which I call a primary flaw, is a
flaw nested within your operating system's security structure. It's a flaw
inherent within a security-related program. By exploiting it, a cracker obtains one-step, unauthorized
access to the system or its data.
The
Netscape Secure Sockets Layer Flaw
In January 1996, two students in the Computer Science
department at the University of California, Berkeley, highlighted a
serious flaw in the Netscape Navigator encryption scheme. Their findings
were published in Dr. Dobb's Journal. The
article, "Randomness and the Netscape Browser," was written by
Ian Goldberg and David Wagner. In it, Goldberg and Wagner explain that
Netscape's implementation of a cryptographic protocol called Secure
Sockets Layer (SSL) was inherently flawed. This flaw would allow secure
communications intercepted on the WWW to be cracked. This is an excellent
example of a primary flaw.
|
Conversely, there are secondary flaws. A secondary flaw is any flaw arising in a program
that, although totally unrelated to
security, opens a security hole elsewhere on the system. In other words,
the programmers were charged with making the program functional, not
secure. No one (at the time the program was designed) imagined cause for
concern, nor did they imagine that such a flaw could arise.
Secondary flaws are far more common than primary flaws,
particularly on platforms that have not traditionally been security
oriented. An example of a secondary security flaw is any flaw within a
program that requires special access privileges in order to complete its
tasks (in other words, a program that must run with root or superuser
privileges). If that program can be attacked, the cracker can work through
that program to gain special, privileged access to files and services.
Whether primary or secondary, system flaws are especially
dangerous to the Internet community when they emerge in programs that are
used on a daily basis, such as FTP, DNS, SSH, or Telnet. These
mission-critical applications form the heart of the Internet and cannot be
suddenly taken away, even if a security flaw exists within them.
To understand this concept, imagine if Microsoft Word were
discovered to be totally insecure. Would people stop using it? Of course
not. Millions of offices throughout the world rely on Word. However, there
is a vast difference between a
serious security flaw in Microsoft Word and a serious security flaw in the
Apache Web server. The serious flaw in Apache would place hundreds of
thousands of servers (and therefore, millions of accounts) at risk. Because
of the Internet's size and the services it now offers, flaws inherent
within its security structure are of international concern.
To understand the true scope of this problem, take a look
at just some of the vulnerabilities discovered in services during 1999 and
2000 that have allowed "root" or "administrative" level
compromises:
·
The wu-ftpd FTP daemon shipped in many BSD and Linux
distributions
·
The University of Washington imapd daemon
·
ISC's Bind (an implementation of DNS)
·
Numerous services found in Sun Solaris
·
Microsoft's IIS
·
The Linuxconf configuration utility
·
SSH (Secure Shell)
…and that's just a small
sample. At the time of this writing, based on the Security Alert Consensus
(SAC, a weekly vulnerability newsletter put out by SANS, Network Computing,
and Neohapsis), there are new vulnerabilities being discovered at the rate
of 10–30 per week. We will go into the
entire process of vulnerability research and publication in greater detail
in Part III, "Hacking 101: The Tricks of the
Trade." For now, know that when a flaw is discovered within
sendmail, FTP, DNS, SSH, or other indispensable elements of the Internet,
programmers develop patches (small programs
or source code) to temporarily solve the problem. These patches are
distributed to the world at large, along with detailed advisories. This
brings us to vendor response.
Deficiencies in Vendor QA Efforts and Response
Two summers ago I found myself sitting
in on a meeting between Microsoft officials and one of their larger
clients. During this meeting the topic of the hidden flight simulator in
Excel came up. The client wanted to know what a flight simulator was doing
in a spreadsheet pro gram. They wanted to know how much room it was taking
up in the program, in memory, and on their workstations. But above all
else, they wanted to know how it had gotten past Microsoft's QA/QC efforts.
A few lines of code is one thing, but an entire flight simulator is quite
another. Microsoft's response? That they knew it was in there all along,
and that this "Easter egg" was just something they let their
programmers in Redmond do for fun. "It's part of the development
culture," the Microsoft representatives said.
Note
If you weren't aware of the embedded gift in your
Microsoft Excel application, fire up a copy of MS Excel that shipped in
Office 97. Press F5 (to go to a location), type X97:L97, and then click OK. Press
the Tab key. Then hold down Ctrl and Shift at the same time, and
simultaneously click the "chart wizard" button once—it's the one
with the colorful bar graphs. Violà—instant flight simulator.
The first word that came out of my mouth began with a
"B" and ended with a "T." But what else was Microsoft
going to say? Whoops? Sorry? We missed the few thousand lines of extra code that just happened to be a mini video game?
So in the spring of 2000 when "rain forest
puppy," an infamous and clever member of the underground reported that
the phrase "Netscape Engineers are Weenies" had been used as a
key and served as a pseudo back door into servers running FrontPage 98
extensions, I couldn't wait to hear Microsoft's excuse for this one. Was
this part of the development culture as well? Back doors and cheap shots at
the competition's development staff?
It turns out Microsoft initially admitted to the existence
of the egg that was all over their face, but then quickly masked it with an
even bigger problem that was released a bit later. Check out the updated
advisory at http://www.microsoft.com/technet/security/bulletin/ms00-025.asp—at
no point is there any mention of the word "weenie," back doors,
or other such shenanigans. Microsoft has appeared to have swept this one
under the carpet as well.
Note
One more thing I'd like to note about the Excel
"Easter egg" story. When MS offered this client the "We knew
about it" excuse, this client demanded a list of other back doors and
Easter eggs MS supposedly knew about. MS agreed—and then never delivered on
its promise. Makes you wonder, huh?
So if the largest software vendor in the world can't
control what is entering its code, is there any hope for the rest of the
industry? The simple fact of the matter is that many software companies
don't have adequate quality control/quality assurance programs in place.
Microsoft is an easy target as it has SO MANY software products in the
marketplace, but the truth is that a lot of companies are guilty of this as
well. Who winds up ultimately paying for these oversights? We do—the
consumers. We're the ones who get hammered when these oversights get used
for breaching our networks. However, the vendors claim that their customers
want more features, not more security. If that's not the case I encourage
the readers of this book to make their voices heard.
Tell your vendors how you really feel.
Let's take a look at a few of specific examples of
oversights and their impact on the scene.
Allaire's ColdFusion Problems
The beginning of 1999 was a great time for Allaire. Their
product, ColdFusion, had taken the industry by storm in giving Web
developers some powerful but easy tools for designing Web sites that
interacted with database back-ends. In the spring of 1999, however, rain
forest puppy reported a number of problems with the CGI sample scripts
Allaire shipped with ColdFusion. Remote attackers could leverage these
scripts to execute code on the vulnerable machines, retrieve protected
files, and ultimately compromise the targeted machine. A few months later,
the L0pht reported more problems. Although administrators probably
shouldn't have been installing sample scripts on production servers to
begin with, ignorance had prevailed once again. Soon black hat hackers all
over the planet were hacking ColdFusion servers at an alarming rate, and
Allaire had a major public relations issue on its hands.
Allaire was slow to react, as this was its first exposure
to the harshness known as the information security community. Eventually
Allaire released advisories urging customers to remove the scripts and
patch their servers, but the damage was done. Hundreds upon hundreds of
machines had already been hit, and the trend continued throughout the rest
of the year.
Eventually the chaos subsided, and attackers moved on with
more popular attack trends. Allaire has since then beefed up its internal
security efforts, released new, more secure versions of ColdFusion,
solicited third-party application reviews, and launched an awareness
heightening campaign
within its user base. Allaire is now one of the most pro-active vendors out
there when it comes to security. However, Allaire has been paying for its
sins ever since. In June 2000 when SANS (System Administration, Networking,
and Security) released its report on the Top 10 vulnerabilities found on
the Net today, Allaire's ColdFusion problem had crept up once again—it was
on the charts because it had been a BIG problem. Even though the
vulnerabilities had been addressed for close to a year, people remembered
them. The simple fact of the matter was that the vulnerability hit the
security scene really hard, and organizations were hurt pretty badly by it.
Vulnerable servers based on older versions of ColdFusion still creep up
once in a while, and administrators who suffered through the siege of 1999
were slow to forgive.
Fortunately, Allaire learned from its mistakes and its
customers will benefit from this. However, the people who were hacked
because of ColdFusion's earlier problems paid the price of this education.
Microsoft PPTP
Another example that wasn't exploited en masse but is definitely flawed is
Microsoft Corporation's implementation of Point-to-Point Tunneling Protocol
(PPTP). PPTP is a protocol that's used to build Virtual Private Networks
(VPNs) over the Internet. VPNs enable secure, encrypted traffic between
corporate link-points, thus eliminating the need for leased lines. (Through
VPNs, corporations can use the Internet as their global leased line.)
Microsoft's implementation of PPTP had been lauded as one of
the most solid security measures you could employ. In fact, it even won an
award or two in consumer computing magazines, Microsoft's PPTP had been
written up as an industry standard solution. That's great.
One month before the second edition of this book went to
press, Microsoft's PPTP was broken by two well-respected encryption
authorities, Bruce Schneier and Mudge. The press release rocked the
security world. Here's a portion of that release:
Doesn't Microsoft know better? You'd think they would. The
mistakes they made are not subtle; they're "kindergarten cryptographer" mistakes.
The encryption is used in a way that completely negates its effectiveness.
The documentation claims 128-bit keys, even though nothing remotely close
to that key length is actually used. Passwords are protected by hash
functions so badly that most can be easily recovered. And the control
channel is so sloppily designed that anyone can cause a Microsoft PPTP
server to go belly up.
—Frequently Asked Questions, Microsoft's PPTP Implementation.
Counterpane Technologies. http://www.counterpane.com/pptp-faq.html
That doesn't sound as if Microsoft's version of PPTP is
very secure, does it? Researchers found five separate flaws in the
implementation, including holes in password hashing, authen tication, and
encryption. In short, they discovered that Microsoft's implementation of
PPTP was a disaster.
I am willing to bet that you never saw that advisory. If
you didn't, you're like information officers in companies all over the
country. They believe that the products they're using are secure. After all,
Microsoft is a big, well-established company. If they say their products
are secure, it must be true.
That's the mindset of the average network manager these
days, and thousands of companies are at risk because of it.
Note
Mistakes of this sort are made all the time. Here's an
amusing example. It was discovered a while ago that the encryption scheme
in Microsoft Windows NT could be effectively turned off. The attack is now
known as the "You Are Now in France" attack. It works like this: France did not allow private citizens access to strong encryption. If Windows NT
interpreted that your location was France, the operating system's strong
encryption was disabled. Not very secure, is it?
The bottom line is this: You're on your own. That is, it's
up to you to take measures to secure your data. Don't count on any vendor
to do it for you. If you do, you're setting yourself up for a serious fall.
Vendor Response
Vendor response has traditionally been
good, but this shouldn't give you a false sense of security. Vendors are in
the business of selling software. To them, there is nothing fascinating
about someone discovering a hole in the system. At best, a security hole
represents a loss of revenue or prestige. Accordingly, vendors quickly
issue assurances to allay users'fears, but actual corrective action can
sometimes be long in coming.
The reasons for this can be complex, and often the vendor
is not to blame. Sometimes, imme diate corrective action just isn't
feasible, such as in the following cases:
·
When the affected application is comprehensively tied to the
operating system
·
When the application is widely in use or is a standard
·
When the application is third-party software and that third
party has poor support, has gone out of business, or is otherwise
unavailable
In these instances, a patch (or other solution) can
provide temporary relief. However, for this system to work effectively, all
users must know that the patch is available. Notifying the public would
seem to be the vendor's responsibility and, to be fair, vendors post such
patches to security groups and mailing lists. However,
vendors might not always take the extra step of informing the general
public. In many cases, it just isn't cost effective.
Once again, this issue breaks down to knowledge. Users who
have up-to-date knowledge of their network utilities, of holes, and of
patches are well prepared. Users without such knowledge tend to be victims.
That, more than any other reason, is why we wrote this book. In a nutshell,
security education is the best policy.
Lack of Qualified People in the Field
So if we didn't have vendors and programmers putting out
buggy code, operating systems shipping with every possible service enabled
and running by default, sample scripts installed everywhere, and a slew of
misconfigurations and mistakes being made, we'd still have one major
problem—not enough people have information security experience. IT managers
are having a hard enough time these days finding competent network
engineers, system administrators, and programmers, much less security
professionals.
Making matters worse, you can't get training that will
instantly make you an information security specialist. You have to take it
in steps. First, become competent with routers, switches, and firewalls.
Learn the ins and outs of UNIX and Windows NT. Learn the basics surrounding
cryptography and programming, and obtain a SOLID understanding of TCP/IP.
And then you can BEGIN to learn the intricacies surrounding security,
incident response, and other late night and stressful activities.
Excited yet?
The lack of personnel contributes to misguided or absent
information security programs within organizations. Policies remain
incomplete or nonexistent. Companies operate without a threat
identification effort. Machines go unpatched, development efforts go awry,
logs go unmonitored, and users remain uneducated. In short, we find
ourselves living in the world that we exist in today.
It doesn't have to be like this, however. If
administrators and users held up their areas of responsibility from a
security standpoint, we wouldn't be needing fleets of all-encompassing
infosec gurus. We're hoping for the day when security practices are as
common as running system backups—part of any good system administrator's
job. Unfortunately, we believe that day is a ways off.
The funniest part about this crazy field is that most of
us who are considered information security professionals got here by
accident. However, as time goes on, it continues to get easier to exchange
knowledge and learn at a quicker pace. More books are coming out, more
conferences exist, more papers are being written, information security
portals and sites continue to improve, and the security mailing lists that
exist on the net are only getting better. Security-related certifications
like the CISSP and the SANS GIAC programs are starting to crank out more
and more qualified people. In short, it's getting easier to learn as there
is a lot more out there then there was even two to three years ago.
Suffice it to say, however, that there will be a shortage
of good security people for quite some time.
|