Maximum Security:

A Hacker's Guide to Protecting Your Internet Site and Network

Previous chapterNext chapterContents


1

Why Did I Write This Book?

Hacking and cracking are activities that generate intense public interest. Stories of hacked servers and downed Internet providers appear regularly in national news. Consequently, publishers are in a race to deliver books on these subjects. To its credit, the publishing community has not failed in this resolve. Security books appear on shelves in ever-increasing numbers. However, the public remains wary. Consumers recognize driving commercialism when they see it, and are understandably suspicious of books such as this one. They need only browse the shelves of their local bookstore to accurately assess the situation.

Books about Internet security are common (firewall technology seems to dominate the subject list). In such books, the information is often sparse, confined to a narrow range of products. Authors typically include full-text reproductions of stale, dated documents that are readily available on the Net. This poses a problem, mainly because such texts are impractical. Experienced readers are already aware of these reference sources, and inexperienced ones are poorly served by them. Hence, consumers know that they might get little bang for their buck. Because of this trend, Internet security books have sold poorly at America's neighborhood bookstores.

Another reason that such books sell poorly is this: The public erroneously believes that to hack or crack, you must first be a genius or a UNIX guru. Neither is true, though admittedly, certain exploits require advanced knowledge of the target's operating system. However, these exploits can now be simplified through utilities that are available for a wide range of platforms. Despite the availability of such programs, however, the public remains mystified by hacking and cracking, and therefore, reticent to spend forty dollars for a hacking book.

So, at the outset, Sams.net embarked on a rather unusual journey in publishing this book. The Sams.net imprint occupies a place of authority within the field. Better than two thirds of all information professionals I know have purchased at least one Sams.net product. For that reason, this book represented to them a special situation.

Hacking, cracking, and Internet security are all explosive subjects. There is a sharp difference between publishing a primer about C++ and publishing a hacking guide. A book such as this one harbors certain dangers, including

If any of these dangers materialize, Sams.net will be subject to scrutiny or perhaps even censure. So, again, if all of this is true, why would Sams.net publish this book?

Sams.net published this book (and I agreed to write it) because there is a real need. I'd like to explain that need for a moment, because it is a matter of some dispute within the Internet community. Many people feel that this need is a manufactured one, a device dreamt up by software vendors specializing in security products. This charge--as the reader will soon learn--is unfounded.

Today, thousands of institutions, businesses, and individuals are going online. This phenomenon--which has been given a dozen different names--is most commonly referred to as the Internet explosion. That explosion has drastically altered the composition of the Internet. By composition of the Internet, I refer to the cyberography of the Net, or the demography of cyberspace. This quality is used to express the now diverse mixture of users (who have varying degrees of online expertise) and their operating systems.

A decade ago, most servers were maintained by personnel with at least basic knowledge of network security. That fact didn't prevent break-ins, of course, but they occurred rarely in proportion to the number of potential targets. Today, the Internet's population is dominated by those without strong security knowledge, many of whom establish direct links to the backbone. The number of viable targets is staggering.

Similarly, individual users are unaware that their personal computers are at risk of penetration. Folks across the country surf the Net using networked operating systems, oblivious to dangers common to their platform. To be blunt, much of America is going online unarmed and unprepared.

You might wonder even more why Sams would publish a book such as this. After all, isn't the dissemination of such information likely to cause (rather than prevent) computer break-ins?

In the short run, yes. Some readers will use this book for dark and unintended purposes. However, this activity will not weaken network security; it will strengthen it. To demonstrate why, I'd like to briefly examine the two most common reasons for security breaches:

Misconfiguration of the Victim Host

The primary reason for security breaches is misconfiguration of the victim host. Plainly stated, most operating systems ship in an insecure state. There are two manifestations of this phenomenon, which I classify as active and passive states of insecurity in shipped software.

The Active State

The active state of insecurity in shipped software primarily involves network utilities. Certain network utilities, when enabled, create serious security risks. Many software products ship with these options enabled. The resulting risks remain until the system administrator deactivates or properly configures the utility in question.

A good example would be network printing options (the capability of printing over an Ethernet or the Internet). These options might be enabled in a fresh install, leaving the system insecure. It is up to the system administrator (or user) to disable these utilities. However, to disable them, the administrator (or user) must first know of their existence.

You might wonder how a user could be unaware of such utilities. 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, the majority of 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.

For example, how many readers who 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. So, despite the power of these two utilities, 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 a job or other official position where extensive training is offered. No matter how they acquire the knowledge, nearly everyone knows something cool about their operating system. (Example: the Microsoft programming team easter egg in Windows 95.)


The Microsoft programming team easter egg: The Microsoft programming team easter egg is a program hidden in the heart of Windows 95. When you enter the correct keystrokes and undertake the correct actions, this program displays the names of each programmer responsible for Windows 95. To view that easter egg, perform the following steps:

1. Right-click the Desktop and choose New|Folder.

2. Name that folder and now the moment you've all been waiting for.

3. Right-click that folder and choose Rename.

4. Rename the folder we proudly present for your viewing pleasure.

5. Right-click the folder and choose Rename.

5. Rename the folder The Microsoft Windows 95 Product Team!.

6. Open that folder by double-clicking it.

The preceding steps will lead to the appearance of a multimedia presentation about the folks who coded Windows 95. (A word of caution: The presentation is quite long.)


Unfortunately, keeping up with the times is difficult. 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- development team materially alters its product, a large class of users is suddenly left knowing less. Microsoft Windows 95 is a good example of this phenomenon. New support has been added for many different protocols: protocols with which the average Windows user might not be familiar. So, it is possible (and probable) that users might be unaware of obscure network utilities at work with their operating systems.

This is especially so with UNIX-based operating systems, but for a slightly different reason. UNIX is a large and inherently complex system. Comparing it to other operating systems can be instructive. DOS contains perhaps 30 commonly used commands. In contrast, a stock distribution of UNIX (without considering windowed systems) supports several hundred commands. Further, each command has one or more command-line options, increasing the complexity of each utility or program.

In any case, in the active state of insecurity in shipped software, utilities are enabled and this fact is unknown to the user. These utilities, 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.

Active state problems are easily remedied. The solution is to turn off (or properly configure) the offending utility or service. Typical examples of active state problems include

Of the examples listed, default passwords is the most common. Most multiuser operating systems on the market have at least one default password (or an account requiring no password at all).

The Passive State

The passive state involves operating systems with built-in security utilities. These utilities can be quite effective when enabled, but remain worthless until the system administrator activates them. In the passive state, these utilities are never activated, usually because the user is unaware that they exist. Again, the source of the problem is the same: The user or system administrator lacks adequate knowledge of the system.

To understand the passive state, consider logging utilities. Many networked operating systems provide good logging utilities. These comprise the cornerstone of any investigation. Often, these utilities are not set to active in a fresh installation. (Vendors might leave this choice to the system administrator for a variety of reasons. For example, certain logging utilities consume space on local drives by generating large text or database files. Machines with limited storage are poor candidates for conducting heavy logging.) Because vendors cannot guess the hardware configuration of the consumer's machine, logging choices are almost always left to the end-user.

Other situations that result in passive-state insecurity can arise: Situations where user knowledge (or lack thereof) is not the problem. For instance, certain security utilities are simply impractical. Consider security programs that administer file-access privileges (such as those that 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 will notice that both active and passive states of insecurity in software result from the consumer's lack of knowledge (not from any vendor's act or omission). This is an education issue, and education is a theme that will recur throughout this book.


NOTE: Education issues are matters entirely within your control. That is, you can eliminate these problems by providing yourself or your associates with adequate education. (Put another way, crackers can gain most effectively by attacking networks where such knowledge is lacking.) That settled, I want to examine matters that might not be within the end-user's control.

System Flaws or Deficiency of Vendor Response

System flaws or deficiency of vendor response are matters beyond the end-user's control. Although vendors might argue this point furiously, here's a fact: These factors are the second most common source of security problems. Anyone who subscribes to a bug mailing list knows this. Each day, bugs or programming weaknesses are found in network software. Each 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 element of a program that causes the program to

I am concerned with two types of system flaws. The first, which I call a pure flaw, is a security flaw nested within the security structure itself. It is 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 was titled Randomness and the Netscape Browser 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 pure flaw. (It should be noted here that the flaw in Netscape's SSL implementation was originally discovered by an individual in France. However, Goldberg and Wagner were the first individuals in the United States to provide a detailed analysis of it.)

Conversely, there are secondary flaws. A secondary flaw is any flaw arising in a program that, while 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 pure 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. Historically, printer utilities have been problems in this area. (For example, in late 1996, SGI determined that root privileges could be obtained through the Netprint utility in its IRIX operating system.)

Whether pure or secondary, system flaws are especially dangerous to the Internet community because they often emerge in programs that are used on a daily basis, such as FTP or Telnet. These mission-critical applications form the very 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 NCSA HTTPD, which is a popular Web-server package. The serious flaw in HTTPD 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.

So, whenever a flaw is discovered within sendmail, FTP, Gopher, HTTP, 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.

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, immediate corrective action just isn't feasible, such as the following:

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 good 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 I wrote this book. In a nutshell, security education is the best policy.

Why Education in Security Is Important

Traditionally, security folks have attempted to obscure security information from the average user. As such, security specialists occupy positions of prestige in the computing world. They are regarded as high priests of arcane and recondite knowledge that is unavailable to normal folks. There was a time when this approach had merit. After all, users should be afforded such information only on a need-to-know basis. However, the average American has now achieved need-to-know status.

So, I pose the question again: Who needs to be educated about Internet security? The answer is: We all do. I hope that this book, which is both a cracker's manual and an Internet security reference, will force into the foreground issues that need to be discussed. Moreover, I wrote this book to increase awareness of security among the general public. As such, this book starts with basic information and progresses with increasing complexity. For the absolute novice, this book is best read cover to cover. Equally, those readers familiar with security will want to quickly venture into later chapters.

The answer to the question regarding the importance of education and Internet security depends on your station in life. If you are a merchant or business person, the answer is straightforward: In order to conduct commerce on the Net, you must be assured of some reasonable level of data security. This reason is also shared by consumers. If crackers are capable of capturing Net traffic containing sensitive financial data, why buy over the Internet? And of course, between the consumer and the merchant stands yet another class of individual concerned with data security: the software vendor who supplies the tools to facilitate that commerce. These parties (and their reasons for security) are obvious. However, there are some not so obvious reasons.

Privacy is one such concern. The Internet represents the first real evidence that an Orwellian society can be established. Every user should be aware that nonencrypted communication across the Internet is totally insecure. Likewise, each user should be aware that government agencies--not crackers--pose the greatest threat. Although the Internet is a wonderful resource for research or recreation, it is not your friend (at least, not if you have anything to hide).

There are other more concrete reasons to promote security education. I will focus on these for a moment. The Internet is becoming more popular. Each day, development firms introduce new and innovative ways to use the Network. It is likely that within five years, the Internet will become an important and functional part of our lives.

The Corporate Sector

For the moment, set aside dramatic scenarios such as corporate espionage. These subjects are exciting for purposes of discussion, but their actual incidence is rare. Instead, I'd like to concentrate on a very real problem: cost.

The average corporate database is designed using proprietary software. Licensing fees for these big database packages can amount to tens of thousands of dollars. Fixed costs of these databases include programming, maintenance, and upgrade fees. In short, development and sustained use of a large, corporate database is costly and labor intensive.

When a firm maintains such a database onsite but without connecting it to the Internet, security is a limited concern. To be fair, an administrator must grasp the basics of network security to prevent aspiring hackers in this or that department from gaining unauthorized access to data. Nevertheless, the number of potential perpetrators is limited and access is usually restricted to a few, well-known protocols.

Now, take that same database and connect it to the Net. Suddenly, the picture is drastically different. First, the number of potential perpetrators is unknown and unlimited. An attack could originate from anywhere, here or overseas. Furthermore, access is no longer limited to one or two protocols.

The very simple operation of connecting that database to the Internet opens many avenues of entry. For example, database access architecture might require the use of one or more foreign languages to get the data from the database to the HTML page. I have seen scenarios that were incredibly complex. In one scenario, I observed a six-part process. From the moment the user clicked a Submit button, a series of operations were undertaken:

1. The variable search terms submitted by the user were extracted and parsed by a Perl script.

2. The Perl script fed these variables to an intermediate program designed to interface with a proprietary database package.

3. The proprietary database package returned the result, passing it back to a Perl script that formatted the data into HTML.

Anyone legitimately employed in Internet security can see that this scenario was a disaster waiting to happen. Each stage of the operation boasted a potential security hole. For exactly this reason, the development of database security techniques is now a hot subject in many circles.

Administrative personnel are sometimes quick to deny (or restrict) funding for security within their corporation. They see this cost as unnecessary, largely because they do not understand the dire nature of the alternative. The reality is this: One or more talented crackers could--in minutes or hours--destroy several years of data entry.

Before business on the Internet can be reliably conducted, some acceptable level of security must be reached. For companies, education is an economical way to achieve at least minimal security. What they spend now may save many times that amount later.

Government

Folklore and common sense both suggest that government agencies know something more, something special about computer security. Unfortunately, this simply isn't true (with the notable exception of the National Security Agency). As you will learn, government agencies routinely fail in their quest for security.

In the following chapters, I will examine various reports (including one very recent one) that demonstrate the poor security now maintained by U.S. government servers. The sensitivity of data accessed by hackers is amazing.

These arms of government (and their attending institutions) hold some of the most personal data on Americans. More importantly, these folks hold sensitive data related to national security. At the minimum, this information needs to be protected.

Operating Systems

There is substantial rivalry on the Internet between users of different operating systems. Let me make one thing clear: It does not matter which operating system you use. Unless it is a secure operating system (that is, one where the main purpose of its design is network security), there will always be security holes, apparent or otherwise. True, studies have shown that to date, fewer holes have been found in Mac and PC-based operating systems (as opposed to UNIX, for example), at least in the context to the Internet. However, such studies are probably premature and unreliable.

Open Systems

UNIX is an open system. As such, its source is available to the public for examination. In fact, many common UNIX programs come only in source form. Others include binary distributions, but still include the source. (An illustrative example would be the Gopher package from the University of Minnesota.) Because of this, much is known about the UNIX operating system and its security flaws. Hackers can inexpensively establish Linux boxes in their homes and hack until their faces turn blue.

Closed and Proprietary Systems

Conversely, the source of proprietary and closed operating systems is unavailable. The manufacturers of such software furiously protect their source, claiming it to be a trade secret. As these proprietary operating systems gravitate to the Net, their security flaws will become more readily apparent. To be frank, this process depends largely on the cracking community. As crackers put these operating systems (and their newly implemented TCP/IP) to the test, interesting results will undoubtedly emerge. But, to my point.

We no longer live in a world governed exclusively by a single operating system. As the Internet grows in scope and size, all operating systems known to humankind will become integral parts of the network. Therefore, operating-system rivalry must be replaced by a more sensible approach. Network security now depends on having good, general security knowledge. (Or, from another angle, successful hacking and cracking depends on knowing all platforms, not just one.) So, I ask my readers to temporarily put aside their bias. In terms of the Internet at least, the security of each one of us depends on us all and that is no trivial statement.

How Will This Book Affect the Internet Community?

This section begins with a short bedtime story. It is called The Loneliness of the Long-Distance Net Surfer.

The Information Superhighway is a dangerous place. Oh, the main highway isn't so bad. Prodigy, America Online, Microsoft Network...these are fairly clean thoroughfares. They are beautifully paved, with colorful signs and helpful hints on where to go and what to do. But pick a wrong exit, and you travel down a different highway: one littered with burned-out vehicles, overturned dumpsters, and graffiti on the walls. You see smoke rising from fires set on each side of the road. If you listen, you can hear echoes of a distant subway mixed with strange, exotic music.

You pull to a stop and roll down the window. An insane man stumbles from an alley, his tattered clothes blowing in the wind. He careens toward your vehicle, his weathered shoes scraping against broken glass and concrete. He is mumbling as he approaches your window. He leans in and you can smell his acrid breath. He smiles--missing two front teeth--and says "Hey, buddy...got a light?" You reach for the lighter, he reaches for a knife. As he slits your throat, his accomplices emerge from the shadows. They descend on your car as you fade into unconsciousness. Another Net Surfer bites the dust. Others decry your fate. He should have stayed on the main road! Didn't the people at the pub tell him so? Unlucky fellow.

This snippet is an exaggeration; a parody of horror stories often posted to the Net. Most commonly, they are posted by commercial entities seeking to capitalize on your fears and limited understanding of the Internet. These stories are invariably followed by endorsements for this or that product. Protect your business! Shield yourself now! This is an example of a phenomenon I refer to as Internet voodoo. To practitioners of this secret art, the average user appears as a rather gullible chap. A sucker.

If this book accomplishes nothing else, I hope it plays a small part in eradicating Internet voodoo. It provides enough education to shield the user (or new system administrator) from unscrupulous forces on the Net. Such forces give the Internet-security field a bad name.

I am uncertain as to what other effects this book might have on the Internet community. I suspect that these effects will be subtle or even imperceptible. Some of these effects might admittedly be negative and for this, I apologize. I am aware that Chapter 9, "Scanners," where I make most of the known scanners accessible to and easily understood by anyone, will probably result in a slew of network attacks (probably initiated by youngsters just beginning their education in hacking or cracking). Nevertheless, I am hoping that new network administrators will also employ these tools against their own networks. In essence, I have tried to provide a gateway through which any user can become security literate. I believe that the value of the widespread dissemination of security material will result in an increased number of hackers (and perhaps, crackers).

Summary

I hope this chapter clearly articulates the reasons I wrote this book:

There is also another, one that is less general: I wanted to narrow the gap between the radical and conservative information now available about Internet security. It is significant that many valuable contributions to Internet security have come from the fringe (a sector seldom recognized for its work). To provide the Internet community with a book of value, these fringe elements had to be included.

The trouble is, if you examine security documents from the fringe, they are very grass roots and revolutionary. This style--which is uniquely American if nothing else--is often a bit much for square security folks. Likewise, serious security documents can be stuffy, academic, and, to be frank, boring. I wanted to deliver a book of equal value to readers aiming for either camp. I think that I have.


2

How This Book Will Help You

Prior to writing this book, I had extensive discussions with the Sams.net editorial staff. In those discussions, one thing became immediately clear: Sams.net wanted a book that was valuable to all users, not just to a special class of them. An examination of earlier books on the subject proved instructive. The majority were well written and tastefully presented, but appealed primarily to UNIX or NT system administrators. I recognized that while this class of individuals is an important one, there are millions of average users yearning for basic knowledge of security. To accommodate that need, I aimed at creating an all-purpose Internet security book.

To do so, I had to break some conventions. Accordingly, this book probably differs from other Sams.net books in both content and form. Nevertheless, the book contains copious knowledge, and there are different ways to access it. This chapter briefly outlines how the reader can most effectively access and implement that knowledge.

Is This Book of Practical Use?

Is this book of practical use? Absolutely. It can serve both as a reference book and a general primer. The key for each reader is to determine what information is most important to him or her. The book loosely follows two conventional designs common to books by Sams.net:

This book is a hybrid of both techniques. For example, the book examines services in the TCP/IP suite, then quickly progresses to how those services are integrated in modern browsers, how such services are compromised, and ultimately, how to secure against such compromises. In this respect, there is an evolutionary pattern to the book.

At the same time, the book begins with a general examination of the structure of the Internet and TCP/IP (which will seem light in comparison to later analyses of sniffing, where you examine the actual construct of an information packet). As you progress, the information becomes more and more advanced. In this respect, there is a developmental pattern to the book.

Using This Book Effectively: Who Are You?

Different people will derive different benefits from this book, depending on their circumstances. I urge each reader to closely examine the following categories. The information will be most valuable to you whether you are

I want to cover these categories and how this book can be valuable to each. If you do not fit cleanly into one of these categories, try the category that best describes you.

System Administrator

A system administrator is any person charged with managing a network or any portion of a network. Sometimes, people might not realize that they are a system administrator. In small companies, for example, programming duties and system administration are sometimes assigned to a single person. Thus, this person is a general, all-purpose technician. They keep the system running, add new accounts, and basically perform any task required on a day-to-day basis. This, for your purposes, is a system administrator.

What This Book Offers the System Administrator

This book presumes only basic knowledge of security from its system administrators, and I believe that this is reasonable. Many capable system administrators are not well versed in security, not because they are lazy or incompetent but because security was for them (until now) not an issue. For example, consider the sysad who lords over an internal LAN. One day, the powers that be decree that the LAN must establish a connection to the Net. Suddenly, that sysad is thrown into an entirely different (and hostile) environment. He or she might be exceptionally skilled at internal security but have little practical experience with the Internet. Today, numerous system administrators are faced with this dilemma. For many, additional funding to hire on-site security specialists is not available and thus, these people must go it alone. Not anymore. This book will serve such system administrators well as an introduction to Internet security.

Likewise, more experienced system administrators can effectively use this book to learn--or perhaps refresh their knowledge about--various aspects of Internet security that have been sparsely covered in books mass-produced for the general public.

For either class of sysad, this book will serve a fundamental purpose: It will assist them in protecting their network. Most importantly, this book shows the attack from both sides of the fence. It shows both how to attack and how to defend in a real-life, combat situation.

Hacker

The term hacker refers to programmers and not to those who unlawfully breach the security of systems. A hacker is any person who investigates the integrity and security of an operating system. Most commonly, these individuals are programmers. They usually have advanced knowledge of both hardware and software and are capable of rigging (or hacking) systems in innovative ways. Often, hackers determine new ways to utilize or implement a network, ways that software manufacturers had not expressly intended.

What This Book Offers the Hacker

This book presumes only basic knowledge of Internet security from its hackers and programmers. For them, this book will provide insight into the Net's most common security weaknesses. It will show how programmers must be aware of these weaknesses. There is an ever-increasing market for those who can code client/server applications, particularly for use on the Net. This book will help programmers make informed decisions about how to develop code safely and cleanly. As an added benefit, analysis of existing network utilities (and their deficiencies) may assist programmers in developing newer and perhaps more effective applications for the Internet.

Cracker

A cracker is any individual who uses advanced knowledge of the Internet (or networks) to compromise network security. Historically, this activity involved cracking encrypted password files, but today, crackers employ a wide range of techniques. Hackers also sometimes test the security of networks, often with the identical tools and techniques used by crackers. To differentiate between these two groups on a trivial level, simply remember this: Crackers engage in such activities without authorization. As such, most cracking activity is unlawful, illegal, and therefore punishable by a term of imprisonment.

What This Book Offers the Cracker

For the budding cracker, this book provides an incisive shortcut to knowledge of cracking that is difficult to acquire. All crackers start somewhere, many on the famous Usenet group alt.2600. As more new users flood the Internet, quality information about cracking (and security) becomes more difficult to find. The range of information is not well represented. Often, texts go from the incredibly fundamental to the excruciatingly technical. There is little material that is in between. This book will save the new cracker hundreds of hours of reading by digesting both the fundamental and the technical into a single (and I hope) well-crafted presentation.

Business Person

For your purposes, business person refers to any individual who has established (or will establish) a commercial enterprise that uses the Internet as a medium. Hence, a business person--within the meaning employed in this book--is anyone who conducts commerce over the Internet by offering goods or services.


NOTE: It does not matter whether these goods or services are offered free as a promotional service. I still classify this as business.

What This Book Offers the Business Person

Businesses establish permanent connections each day. If yours is one of them, this book will help you in many ways, such as helping you make informed decisions about security. It will prepare you for unscrupulous security specialists, who may charge you thousands of dollars to perform basic, system-administration tasks. This book will also offer a basic framework for your internal security policies. You have probably read dozens of dramatic accounts about hackers and crackers, but these materials are largely sensationalized. (Commercial vendors often capitalize on your fear by spreading such stories.) The techniques that will be employed against your system are simple and methodical. Know them, and you will know at least the basics about how to protect your data.

Journalist

A journalist is any party who is charged with reporting on the Internet. This can be someone who works for a wire news service or a college student writing for his or her university newspaper. The classification has nothing to do with how much money is paid for the reporting, nor where the reporting is published.

What This Book Offers the Journalist

If you are a journalist, you know that security personnel rarely talk to the media. That is, they rarely provide an inside look at Internet security (and when they do, this usually comes in the form of assurances that might or might not have value). This book will assist journalists in finding good sources and solid answers to questions they might have. Moreover, this book will give the journalist who is new to security an overall view of the terrain. Technology writing is difficult and takes considerable research. My intent is to narrow that field of research for journalists who want to cover the Internet. In coming years, this type of reporting (whether by print or broadcast media) will become more prevalent.

Casual User

A casual user is any individual who uses the Internet purely as a source of entertainment. Such users rarely spend more than 10 hours a week on the Net. They surf subjects that are of personal interest.

What This Book Offers the Casual User

For the casual user, this book will provide an understanding of the Internet's innermost workings. It will prepare the reader for personal attacks of various kinds, not only from other, hostile users, but from the prying eyes of government. Essentially, this book will inform the reader that the Internet is not a toy, that one's identity can be traced and bad things can happen while using the Net. For the casual user, this book might well be retitled How to Avoid Getting Hijacked on the Information Superhighway.

Security Specialist

A security specialist is anyone charged with securing one or more networks from attack. It is not necessary that they get paid for their services in order to qualify in this category. Some people do this as a hobby. If they do it, they are a specialist.

What This Book Offers the Security Specialist

If your job is security, this book can serve as one of two things:


NOTE: In this book, the void refers to that portion of the Internet that exists beyond your router or modem. It is the dark, swirling mass of machines, services, and users beyond your computer or network. These are quantities that are unknown to you. This term is commonly used in security circles to refer to such quantities.

Much of the information covered here will be painfully familiar to the security specialist. Some of the material, however, might not be so familiar. (Most notably, some cross-platform materials for those maintaining networks with multiple operating systems.) Additionally, this book imparts a comprehensive view of security, encapsulated into a single text. (And naturally, the materials on the CD-ROM will provide convenience and utility.)

The Good, the Bad, and the Ugly

How you use this book is up to you. If you purchased or otherwise procured this book as a tool to facilitate illegal activities, so be it. You will not be disappointed, for the information contained within is well suited to such undertakings. However, note that this author does not suggest (nor does he condone) such activities. Those who unlawfully penetrate networks seldom do so for fun and often pursue destructive objectives. Considering how long it takes to establish a network, write software, configure hardware, and maintain databases, it is abhorrent to the hacking community that the cracking community should be destructive. Still, that is a choice and one choice--even a bad one--is better than no choice at all. Crackers serve a purpose within the scheme of security, too. They assist the good guys in discovering faults inherent within the network.

Whether you are good, bad, or ugly, here are some tips on how to effectively use this book:

Certain examples contained within this book are available on the CD-ROM. Whenever you see the CD-ROM icon on the outside margin of a page, the resource is available on the CD. This might be source code, technical documents, an HTML presentation, system logs, or other valuable information.

The Book's Parts

The next sections describe the book's various parts. Contained within each description is a list of subjects covered within that chapter.

Part I: Setting the Stage

Part I of this book will be of the greatest value to users who have just joined the Internet community. Topics include

Essentially, Part I sets the stage for the remaining parts of this book. It will assist readers in understanding the current climate on the Net.

Part II: Understanding the Terrain

Part II of this book is probably the most critical. It illustrates the basic design of the Internet. Each reader must understand this design before he or she can effectively grasp concepts in security. Topics include

In short, you will examine why and how the Internet was established, what services are available, the emergence of the WWW, why security might be difficult to achieve, and various techniques for living in a hostile computing environment.

Part III: Tools

Part III of this book examines the average toolbox of the hacker or cracker. It familiarizes the reader with Internet munitions, or weapons. It covers the proliferation of such weapons, who creates them, who uses them, how they work, and how the reader can use them. Some of the munitions covered are

The coverage necessarily includes real-life examples. This chapter will be most useful to readers engaging in or about to engage in Internet security warfare.

Part IV: Platforms and Security

Part IV of this book ventures into more complex territory, treating vulnerabilities inherent in certain operating systems or applications. At this point, the book forks, concentrating on issues relevant to particular classes of users. (For example, if you are a Novell user, you will naturally gravitate to the Novell chapter.)

Part IV begins with basic discussion of security weaknesses, how they develop, and sources of information in identifying them. Part IV then progresses to platforms, including

Part V: Beginning at Ground Zero

Part V of this book examines who has the power on a given network. I will discuss the relationship between these authoritarian figures and their users, as well as abstract and philosophical views on Internet security. At this point, the material is most suited for those who will be living with security issues each day. Topics include

Part VI: The Remote Attack

Part VI of this book concerns attacks: actual techniques to facilitate the compromise of a remote computer system. In it, I will discuss levels of attack, what these mean, and how one can prepare for them. You will examine various techniques in depth: so in depth that the average user can grasp--and perhaps implement--attacks of this nature. Part VI also examines complex subjects regarding the coding of safe CGI programs, weaknesses of various computer languages, and the relative strengths of certain authentication procedures. Topics discussed in this part include

Part VII: The Law

Part VII confronts the legal, ethical, and social ramifications of Internet security and the lack, compromise, and maintenance thereof.

This Book's Limitations

The scope of this book is wide, but there are limitations on the usefulness of the information. Before examining these individually, I want to make something clear: Internet security is a complex subject. If you are charged with securing a network, relying solely upon this book is a mistake. No book has yet been written that can replace the experience, gut feeling, and basic savvy of a good system administrator. It is likely that no such book will ever be written. That settled, some points on this book's limitations include the following:

Timeliness

I commenced this project in January, 1997. Undoubtedly, hundreds of holes have emerged or been plugged since then. Thus, the first limitation of this book relates to timeliness.

Timelines might or might not be a huge factor in the value of this book. I say might or might not for one reason only: Many people do not use the latest and the greatest in software or hardware. Economic and administrative realities often preclude this. Thus, there are LANs now operating on Windows for Workgroups that are permanently connected to the Net. Similarly, some individuals are using SPARCstation 1s running SunOS 4.1.3 for access. Because older software and hardware exist in the void, much of the material here will remain current. (Good examples are machines with fresh installs of an older operating system that has now been proven to contain numerous security bugs.)

Equally, I advise the reader to read carefully. Certain bugs examined in this book are common to a single version of software only (for example, Windows NT Server 3.51). The reader must pay particular attention to version information. One version of a given software might harbor a bug, whereas a later version does not. The security of the Internet is not a static thing. New holes are discovered at the rate of one per day. (Unfortunately, such holes often take much longer to fix.)

Be assured, however, that at the time of this writing, the information contained within this book was current. If you are unsure whether the information you need has changed, contact your vendor.

Utility

Although this book contains many practical examples, it is not a how-to for cracking Internet servers. True, I provide many examples of how cracking is done and even utilities with which to accomplish that task, but this book will not make the reader a master hacker or cracker. There is no substitute for experience, and this book cannot provide that.

What this book can provide is a strong background in Internet security, hacking, and cracking. A reader with little knowledge of these subjects will come away with enough information to crack the average server (by average, I mean a server maintained by individuals who have a working but somewhat imperfect knowledge of security).

Also, journalists will find this book bereft of the pulp style of sensationalist literature commonly associated with the subject. For this, I apologize. However, sagas of tiger teams and samurais are of limited value in the actual application of security. Security is a serious subject, and should be reported as responsibly as possible. Within a few years, many Americans will do their banking online. Upon the first instance of a private citizen losing his life savings to a cracker, the general public's fascination with pulp hacking stories will vanish and the fun will be over.

Lastly, bona fide security specialists might find that for them, only the last quarter of the book has significant value. As noted, I developed this book for all audiences. However, these gurus should keep their eyes open as they thumb through this book. They might be pleasantly surprised (or even downright outraged) at some of the information revealed in the last quarter of the text. Like a sleight-of-hand artist who breaks the magician's code, I have dropped some fairly decent baubles in the street.

Summary

In short, depending on your position in life, this book will help you

It is of value to hackers, crackers, system administrators, business people, journalists, security specialists, and casual users. There is a high volume of information, the chapters move quickly, and (I hope) the book imparts the information in a clear and concise manner.

Equally, this book cannot make the reader a master hacker or cracker, nor can it suffice as your only source for security information. That said, let's move forward, beginning with a small primer on hackers and crackers.


3

Hackers and Crackers

The focus of this chapter is on hackers, crackers, and the differences between them.

What Is the Difference Between a Hacker and a Cracker?

There have been many articles written (particularly on the Internet) about the difference between hackers and crackers. In them, authors often attempt to correct public misconceptions. This chapter is my contribution in clarifying the issue.

For many years, the American media has erroneously applied the word hacker when it really means cracker. So the American public now believe that a hacker is someone who breaks into computer systems. This is untrue and does a disservice to some of our most talented hackers.

There are some traditional tests to determine the difference between hackers and crackers. I provide these in order of their acceptance. First, I want to offer the general definitions of each term. This will provide a basis for the remaining portion of this chapter. Those definitions are as follows:

These definitions are good and may be used in the general sense. However, there are other tests. One is the legal test. It is said that by applying legal reasoning to the equation, you can differentiate between hackers (or any other party) and crackers. This test requires no extensive legal training. It is applied simply by inquiring as to mens rea.

Mens Rea

Mens rea is a Latin term that refers to the guilty mind. It is used to describe that mental condition in which criminal intent exists. Applying mens rea to the hacker-cracker equation seems simple enough. If the suspect unwittingly penetrated a computer system--and did so by methods that any law-abiding citizen would have employed at the time--there is no mens rea and therefore no crime. However, if the suspect was well aware that a security breach was underway--and he knowingly employed sophisticated methods of implementing that breach--mens rea exists and a crime has been committed. By this measure, at least from a legal point of view, the former is an unwitting computer user (possibly a hacker) and the latter a cracker. In my opinion, however, this test is too rigid.

At day's end, hackers and crackers are human beings, creatures too complex to sum up with a single rule. The better way to distinguish these individuals would be to understand their motivations and their ways of life. I want to start with the hacker.

To understand the mind-set of the hacker, you must first know what they do. To explain that, I need to briefly discuss computer languages.

Computer Languages

A computer language is any set of libraries or instructions that, when properly arranged and compiled, can constitute a functional computer program. The building blocks of any given computer language never fundamentally change. Therefore, each programmer walks to his or her keyboard and begins with the same basic tools as his or her fellows. Examples of such tools include

The programmer is given nothing more than languages (except a few manuals that describe how these tools are to be used). It is therefore up to the programmer what happens next. The programmer programs to either learn or create, whether for profit or not. This is a useful function, not a wasteful one. Throughout these processes of learning and creating, the programmer applies one magical element that is absent within both the language libraries and the compiler: imagination. That is the programmer's existence in a nutshell.

Modern hackers, however, reach deeper still. They probe the system, often at a microcosmic level, finding holes in software and snags in logic. They write programs to check the integrity of other programs. Thus, when a hacker creates a program that can automatically check the security structure of a remote machine, this represents a desire to better what now exists. It is creation and improvement through the process of analysis.

In contrast, crackers rarely write their own programs. Instead, they beg, borrow, or steal tools from others. They use these tools not to improve Internet security, but to subvert it. They have technique, perhaps, but seldom possess programming skills or imagination. They learn all the holes and may be exceptionally talented at practicing their dark arts, but they remain limited. A true cracker creates nothing and destroys much. His chief pleasure comes from disrupting or otherwise adversely effecting the computer services of others.

This is the division of hacker and cracker. Both are powerful forces on the Internet, and both will remain permanently. And, as you have probably guessed by now, some individuals may qualify for both categories. The very existence of such individuals assists in further clouding the division between these two odd groups of people. Now, I know that real hackers reading this are saying to themselves "There is no such thing as this creature you are talking about. One is either a hacker or a cracker and there's no more to it."

Randal Schwartz

If you had asked me five years ago, I would have agreed. However, today, it just isn't true. A good case in point is Randal Schwartz, whom some of you know from his weighty contributions to the programming communities, particularly his discourses on the Practical Extraction and Report Language (Perl). With the exception of Perl's creator, Larry Wall, no one has done more to educate the general public on the Perl programming language. Schwartz has therefore had a most beneficial influence on the Internet in general. Additionally, Schwartz has held positions in consulting at the University of Buffalo, Silicon Graphics (SGI), Motorola Corporation, and Air Net. He is an extremely gifted programmer.


NOTE: Schwartz has authored or co-authored quite a few books about Perl, including Learning Perl, usually called "The Llama Book," published by O'Reilly & Associates (ISBN 1-56592-042-2).

His contributions notwithstanding, Schwartz remains on the thin line between hacker and cracker. In fall 1993 (and for some time prior), Schwartz was employed as a consultant at Intel in Oregon. In his capacity as a system administrator, Schwartz was authorized to implement certain security procedures. As he would later explain on the witness stand, testifying on his own behalf:

Part of my work involved being sure that the computer systems were secure, to pay attention to information assets, because the entire company resides--the product of the company is what's sitting on those disks. That's what the people are producing. They are sitting at their work stations. So protecting that information was my job, to look at the situation, see what needed to be fixed, what needed to be changed, what needed to be installed, what needed to be altered in such a way that the information was protected.

The following events transpired:

For example, Schwartz once installed a shell script that allowed him to access the Intel network from other locations. This script reportedly opened a hole in Intel's firewall. Another system administrator discovered this program, froze Schwartz's account, and confronted him. Schwartz agreed that installing the script was not a good idea and further agreed to refrain from implementing that program again. Some time later, that same system administrator found that Schwartz had re-installed the program. (Schwartz apparently renamed the program, thus throwing the system administrator off the trail.) What does all this mean? From my point of view, Randal Schwartz probably broke Intel policy a number of times. What complicates the situation is that testimony reveals that such policy was never explicitly laid out to Schwartz. At least, he was given no document that expressly prohibited his activity. Equally, however, it seems clear that Schwartz overstepped his authority.

Looking at the case objectively, some conclusions can immediately be made. One is that most administrators charged with maintaining network security use a tool like Crack. This is a common procedure by which to identify weak passwords or those that can be easily cracked by crackers from the void. At the time of the Schwartz case, however, such tools were relatively new to the security scene. Hence, the practice of cracking your own passwords was not so universally accepted as a beneficial procedure. However, Intel's response was, in my opinion, a bit reactionary. For example, why wasn't the matter handled internally?

The Schwartz case angered many programmers and security experts across the country. As Jeffrey Kegler wrote in his analysis paper, "Intel v. Randal Schwartz: Why Care?" the Schwartz case was an ominous development:

Clearly, Randal was someone who should have known better. And in fact, Randal would be the first Internet expert already well known for legitimate activities to turn to crime. Previous computer criminals have been teenagers or wannabes. Even the relatively sophisticated Kevin Mitnick never made any name except as a criminal. Never before Randal would anyone on the `light side of the force' have answered the call of the 'dark side.'


Cross Reference: You can find Kegler's paper online at http://www.lightlink.com/spacenka/fors/intro.html.

I want you to think about the Schwartz case for a moment. Do you have or administrate a network? If so, have you ever cracked passwords from that network without explicit authorization to do so? If you have, you know exactly what this entails. In your opinion, do you believe this constitutes an offense? If you were writing the laws, would this type of offense be a felony?

In any event, as stated, Randal Schwartz is unfortunate enough to be the first legitimate computer security expert to be called a cracker. Thankfully, the experience proved beneficial, even if only in a very small way. Schwartz managed to revitalize his career, touring the country giving great talks as Just Another Convicted Perl Hacker. The notoriety has served him well as of late.


TIP: The transcripts of this trial are available on the Internet in zipped format. The entire distribution is 13 days of testimony and argument. It is available at http://www.lightlink.com/spacenka/fors/court/court.html.

Why Do Crackers Exist?

Crackers exist because they must. Because human nature is just so, frequently driven by a desire to destroy instead of create. No more complex explanation need be given. The only issue here is what type of cracker we are talking about.

Some crackers crack for profit. These may land on the battlefield, squarely between two competing companies. Perhaps Company A wants to disable the site of Company B. There are crackers for hire. They will break into almost any type of system you like, for a price. Some of these crackers get involved with criminal schemes, such as retrieving lists of TRW profiles. These are then used to apply for credit cards under the names of those on the list. Other common pursuits are cell-phone cloning, piracy schemes, and garden-variety fraud. Other crackers are kids who demonstrate an extraordinary ability to assimilate highly technical computer knowledge. They may just be getting their kicks at the expense of their targets.

Where Did This All Start?

A complete historical account of cracking is beyond the scope of this book. However, a little background couldn't hurt. It started with telephone technology. Originally, a handful of kids across the nation were cracking the telephone system. This practice was referred to as phreaking. Phreaking is now recognized as any act by which to circumvent the security of the telephone company. (Although, in reality, phreaking is more about learning how the telephone system works and then manipulating it.)

Telephone phreaks employed different methods to accomplish this task. Early implementations involved the use of ratshack dialers, or red boxes. (Ratshack was a term to refer to the popular electronics store Radio Shack.) These were hand-held electronic devices that transmitted digital sounds or tones. Phreakers altered these off-the-shelf tone dialers by replacing the internal crystals with Radio Shack part #43-146.


NOTE: Part #43-146 was a crystal, available at many neighborhood electronics stores throughout the country. One could use either a 6.5MHz or 6.5536 crystal. This was used to replace the crystal that shipped with the dialer (3.579545MHz). The alteration process took approximately 5 minutes.

Having made these modifications, they programmed in the sounds of quarters being inserted into a pay telephone. From there, the remaining steps were simple. Phreaks went to a pay telephone and dialed a number. The telephone would request payment for the call. In response, the phreak would use the red box to emulate money being inserted into the machine. This resulted in obtaining free telephone service at most pay telephones.

Schematics and very precise instructions for constructing such devices are at thousands of sites on the Internet. The practice became so common that in many states, the mere possession of a tone dialer altered in such a manner was grounds for search, seizure, and arrest. As time went on, the technology in this area became more and more advanced. New boxes like the red box were developed. The term boxing came to replace the term phreaking, at least in general conversation, and boxing became exceedingly popular. This resulted in even further advances, until an entire suite of boxes was developed. Table 3.1 lists a few of these boxes.

Table 3.1. Boxes and their uses.

Box What It Does
Blue Seizes trunk lines using a 2600MHz tone, thereby granting the boxer the same privileges as the average operator
Dayglo Allows the user to connect to and utilize his or her neighbor's telephone line
Aqua Reportedly circumvents FBI taps and traces by draining the voltage on the line
Mauve Used to tap another telephone line
Chrome Seizes control of traffic signals

There are at least 40 different boxes or devices within this class. Each was designed to perform a different function. Many of the techniques employed are no longer effective. For example, blue boxing has been seriously curtailed because of new electronically switched telephone systems. (Although reportedly, one can still blue box in parts of the country where older trunk lines can be found.) At a certain stage of the proceedings, telephone phreaking and computer programming were combined; this marriage produced some powerful tools. One example is BlueBEEP, an all-purpose phreaking/hacking tool. BlueBEEP combines many different aspects of the phreaking trade, including the red box. Essentially, in an area where the local telephone lines are old style, BlueBEEP provides the user with awesome power over the telephone system. Have a look at the opening screen of BlueBEEP in Figure 3.1.

It looks a lot like any legitimate application, the type anyone might buy at his or her local software outlet. To its author's credit, it operates as well as or better than most commercial software. BlueBEEP runs in a DOS environment, or through a DOS shell window in either Windows 95 or Windows NT. I should say this before continuing: To date, BlueBEEP is the most finely programmed phreaking tool ever coded. The author, then a resident of Germany, reported that the application was written primarily in PASCAL and assembly language. In any event, contained within the program are many, many options for control of trunk lines, generation of digital tones, scanning of telephone exchanges, and so on. It is probably the most comprehensive tool of its kind. However, I am getting ahead of the time. BlueBEEP was actually created quite late in the game. We must venture back several years to see how telephone phreaking led to Internet cracking. The process was a natural one. Phone phreaks tried almost anything they could to find new systems. Phreaks often searched telephone lines for interesting tones or connections. Some of those connections turned out to be modems.

No one can tell when it was--that instant when a telephone phreak first logged on to the Internet. However, the process probably occurred more by chance than skill. Years ago, Point- to-Point Protocol (PPP) was not available. Therefore, the way a phreak would have found the Internet is debatable. It probably happened after one of them, by direct-dial connection, logged in to a mainframe or workstation somewhere in the void. This machine was likely connected to the Internet via Ethernet, a second modem, or another port. Thus, the targeted machine acted as a bridge between the phreak and the Internet. After the phreak crossed that bridge, he or she was dropped into a world teeming with computers, most of which had poor or sometimes no security. Imagine that for a moment: an unexplored frontier.

What remains is history. Since then, crackers have broken their way into every type of system imaginable. During the 1980s, truly gifted programmers began cropping up as crackers. It was during this period that the distinction between hackers and crackers was first confused, and it has remained so every since. By the late 1980s, these individuals were becoming newsworthy and the media dubbed those who breached system security as hackers.

Then an event occurred that would forever focus America's computing community on these hackers. On November 2, 1988, someone released a worm into the network. This worm was a self-replicating program that sought out vulnerable machines and infected them. Having infected a vulnerable machine, the worm would go into the wild, searching for additional targets. This process continued until thousands of machines were infected. Within hours, the Internet was under heavy siege. In a now celebrated paper that provides a blow-by-blow analysis of the worm incident ("Tour of the Worm"), Donn Seeley, then at the Department of Computer Science at the University of Utah, wrote:

November 3, 1988 is already coming to be known as Black Thursday. System administrators around the country came to work on that day and discovered that their networks of computers were laboring under a huge load. If they were able to log in and generate a system status listing, they saw what appeared to be dozens or hundreds of "shell" (command interpreter) processes. If they tried to kill the processes, they found that new processes appeared faster than they could kill them.

The worm was apparently released from a machine at the Massachusetts Institute of Technology. Reportedly, the logging system on that machine was either working incorrectly or was not properly configured and thus, the perpetrator left no trail. (Seely reports that the first infections included the Artificial Intelligence Laboratory at MIT, the University of California at Berkeley, and the RAND Corporation in California.) As one might expect, the computing community was initially in a state of shock. However, as Eugene Spafford, a renowned computer science professor from Purdue University, explained in his paper "The Internet Worm: An Analysis," that state of shock didn't last long. Programmers at both ends of the country were working feverishly to find a solution:

By late Wednesday night, personnel at the University of California at Berkeley and at Massachusetts Institute of Technology had `captured' copies of the program and began to analyze it. People at other sites also began to study the program and were developing methods of eradicating it.

An unlikely candidate would come under suspicion: a young man studying computer science at Cornell University. This particular young man was an unlikely candidate for two reasons. First, he was a good student without any background that would suggest such behavior. Second, and more importantly, the young man's father, an engineer with Bell Labs, had a profound influence on the Internet's design. Nevertheless, the young man, Robert Morris Jr., was indeed the perpetrator. Reportedly, Morris expected his program to spread at a very slow rate, its effects being perhaps even imperceptible. However, as Brendan Kehoe notes in his book Zen and the Art of the Internet:

Morris soon discovered that the program was replicating and reinfecting machines at a much faster rate than he had anticipated--there was a bug. Ultimately, many machines at locations around the country either crashed or became `catatonic.' When Morris realized what was happening, he contacted a friend at Harvard to discuss a solution. Eventually, they sent an anonymous message from Harvard over the network, instructing programmers how to kill the worm and prevent reinfection.

Morris was tried and convicted under federal statutes, receiving three years probation and a substantial fine. An unsuccessful appeal followed. (I address this case in detail in Part VII of this book, "The Law.")

The introduction of the Morris Worm changed many attitudes about Internet security. A single program had virtually disabled hundreds (or perhaps thousands) of machines. That day marked the beginning of serious Internet security. Moreover, the event helped to forever seal the fate of hackers. Since that point, legitimate programmers have had to rigorously defend their hacker titles. The media has largely neglected to correct this misconception. Even today, the national press refers to crackers as hackers, thus perpetuating the misunderstanding. That will never change and hence, hackers will have to find another term by which to classify themselves.

Does it matter? Not really. Many people charge that true hackers are splitting hairs, that their rigid distinctions are too complex and inconvenient for the public. Perhaps there is some truth to that. For it has been many years since the terms were first used interchangeably (and erroneously). At this stage, it is a matter of principle only.

The Situation Today: A Network at War

The situation today is radically different from the one 10 years ago. Over that period of time, these two groups of people have faced off and crystallized into opposing teams. The network is now at war and these are the soldiers. Crackers fight furiously for recognition and often realize it through spectacular feats of technical prowess. A month cannot go by without a newspaper article about some site that has been cracked. Equally, hackers work hard to develop new methods of security to ward off the cracker hordes. Who will ultimately prevail? It is too early to tell. The struggle will likely continue for another decade or more.

The crackers may be losing ground, though. Because big business has invaded the Net, the demand for proprietary security tools has increased dramatically. This influx of corporate money will lead to an increase in the quality of such security tools. Moreover, the proliferation of these tools will happen at a much faster rate and for a variety of platforms. Crackers will be faced with greater and greater challenges as time goes on. However, as I explain in Chapter 5, "Is Security a Futile Endeavor?" the balance of knowledge maintains a constant, with crackers only inches behind. Some writers assert that throughout this process, a form of hacker evolution is occurring. By this they mean that crackers will ultimately be weeded out over the long haul (many will go to jail, many will grow older and wiser, and so forth). This is probably unrealistic. The exclusivity associated with being a cracker is a strong lure to up-and-coming teenagers. There is a mystique surrounding the activities of a cracker.

There is ample evidence, however, that most crackers eventually retire. They later crop up in various positions, including system administrator jobs. One formerly renowned cracker today runs an Internet salon. Another works on systems for an airline company in Florida. Still another is an elected official in a small town in Southern California. (Because all these individuals have left the life for a more conservative and sane existence, I elected not to mention their names here.)

The Hackers

I shall close this chapter by giving real-life examples of hackers are crackers. That seems to be the only reliable way to differentiate between them. From these brief descriptions, you can get a better understanding of the distinction. Moreover, many of these people are discussed later at various points in this book. This section prepares you for that as well.

Richard Stallman Stallman joined the Artificial Intelligence Laboratory at MIT in 1971. He received the 250K McArthur Genius award for developing software. He ultimately founded the Free Software Foundation, creating hundreds of freely distributable utilities and programs for use on the UNIX platform. He worked on some archaic machines, including the DEC PDP-10 (to which he probably still has access somewhere). He is a brilliant programmer.

Dennis Ritchie, Ken Thompson, and Brian Kernighan Ritchie, Thompson, and Kernighan are programmers at Bell Labs, and all were instrumental in the development of the UNIX operating system and the C programming language. Take these three individuals out of the picture, and there would likely be no Internet (or if there were, it would be a lot less functional). They still hack today. (For example, Ritchie is busy working on Plan 9 from Bell Labs, a new operating system that will probably supplant UNIX as the industry-standard super-networking operating system.)

Paul Baran, Rand Corporation Baran is probably the greatest hacker of them all for one fundamental reason: He was hacking the Internet before the Internet even existed. He hacked the concept, and his efforts provided a rough navigational tool that served to inspire those who followed him.

Eugene Spafford Spafford is a professor of computer science, celebrated for his work at Purdue University and elsewhere. He was instrumental in creating the Computer Oracle Password and Security System (COPS), a semi-automated system of securing your network. Spafford has turned out some very prominent students over the years and his name is intensely respected in the field.

Dan Farmer Farmer worked with Spafford on COPS (Release 1991) while at Carnegie Mellon University with the Computer Emergency Response Team (CERT). For real details, see Purdue University Technical Report CSD-TR-993, written by Eugene Spafford and Daniel Farmer. (Yes, Dan, the byline says Daniel Farmer.) Farmer later gained national notoriety for releasing the System Administrator Tool for Analyzing Networks (SATAN), a powerful tool for analyzing remote networks for security vulnerabilities.

Wietse Venema Venema hails from the Eindhoven University of Technology in the Netherlands. He is an exceptionally gifted programmer who has a long history of writing industry-standard security tools. He co-authored SATAN with Farmer and wrote TCP Wrapper, one of the commonly used security programs in the world. (This program provides close control and monitoring of information packets coming from the void.)

Linus Torvalds A most extraordinary individual, Torvalds enrolled in classes on UNIX and the C programming language in the early 1990s. One year later, he began writing a UNIX-like operating system. Within a year, he released this system to the Internet (it was called Linux). Today, Linux has a cult following and has the distinction of being the only operating system ever developed by software programmers all over the world, many of whom will never meet one another. Linux is free from copyright restrictions and is available free to anyone with Internet access.

Bill Gates and Paul Allen From their high school days, these men from Washington were hacking software. Both are skilled programmers. Starting in 1980, they built the largest and most successful software empire on Earth. Their commercial successes include MS-DOS, Microsoft Windows, Windows 95, and Windows NT.

The Crackers

Kevin Mitnik Mitnik, also known as Condor, is probably the world's best-known cracker. Mitnik began his career as a phone phreak. Since those early years, Mitnik has successfully cracked every manner of secure site you can imagine, including but not limited to military sites, financial corporations, software firms, and other technology companies. (When he was still a teen, Mitnik cracked the North American Aerospace Defense Command.) At the time of this writing, he is awaiting trial on federal charges stemming from attacks committed in 1994-1995.

Kevin Poulsen Having followed a path quite similar to Mitnik, Poulsen is best known for his uncanny ability to seize control of the Pacific Bell telephone system. (Poulsen once used this talent to win a radio contest where the prize was a Porsche. He manipulated the telephone lines so that his call would be the wining one.) Poulsen has also broken nearly every type of site, but has a special penchant for sites containing defense data. This greatly complicated his last period of incarceration, which lasted five years. (This is the longest period ever served by a hacker in the United States.) Poulsen was released in 1996 and has apparently reformed.

Justin Tanner Peterson Known as Agent Steal, Peterson is probably most celebrated for cracking a prominent consumer credit agency. Peterson appeared to be motivated by money instead of curiosity. This lack of personal philosophy led to his downfall and the downfall of others. For example, once caught, Peterson ratted out his friends, including Kevin Poulsen. Peterson then obtained a deal with the FBI to work undercover. This secured his release and he subsequently absconded, going on a crime spree that ended with a failed attempt to secure a six-figure fraudulent wire transfer.

Summary

There are many other hackers and crackers, and you will read about them in the following chapters. Their names, their works, and their Web pages (when available) are meticulously recorded throughout this book. If you are one such person of note, you will undoubtedly find yourself somewhere within this book. The criterion to be listed here is straightforward: If you have done something that influenced the security of the Internet, your name likely appears here. If I missed you, I extend my apologies.

For the remaining readers, this book serves not only as a general reference tool, but a kind of directory of hackers and crackers. For a comprehensive listing, see Appendix A, "How to Get More Information." That appendix contains both establishment and underground resources.


4

Just Who Can Be Hacked, Anyway?

The Internet was born in 1969. Almost immediately after the network was established, researchers were confronted with a disturbing fact: The Internet was not secure and could easily be cracked. Today, writers try to minimize this fact, reminding you that the security technologies of the time were primitive. This has little bearing. Today, security technology is quite complex and the Internet is still easily cracked.

I would like to return to those early days of the Internet. Not only will this give you a flavor of the time, it will demonstrate an important point: The Internet is no more secure today than it was twenty years ago.

My evidence begins with a document: a Request for Comments, or RFC. Before you review the document, let me explain what the RFC system is about. This is important because I refer to many RFC documents throughout this book.

The Request For Comments (RFC) System

Requests for Comments (RFC) documents are special. They are written (and posted to the Net) by individuals engaged in the development or maintenance of the Internet. RFC documents serve the important purpose of requesting Internet-wide comments on new or developing technology. Most often, RFC documents contain proposed standards.

The RFC system is one of evolution. The author of an RFC posts the document to the Internet, proposing a standard that he or she would like to see adopted network-wide. The author then waits for feedback from other sources. The document (after more comments/changes have been made) goes to draft or directly to Internet standard status. Comments and changes are made by working groups of the Internet Engineering Task Force (IETF).


Cross Reference: The Internet Engineering Task Force (IETF) is "... a large, open, international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet." To learn more about the IETF, go to its home page at http://www.ietf.cnri.reston.va.us/.

RFC documents are numbered sequentially (the higher the number, the more recent the document) and are distributed at various servers on the Internet.


Cross Reference: One central server from which to retrieve RFC documents is at http://ds0.internic.net/ds/dspg0intdoc.html. This address (URL) is located at InterNIC, or the Network Information Center.

InterNIC

InterNIC provides comprehensive databases on networking information. These databases contain the larger portion of collected knowledge on the design and scope of the Internet. Some of those databases include


Cross Reference: All these documents are centrally available at http://rs.internic.net.

A Holiday Message

As I mentioned earlier, I refer here to an early RFC. The document in question is RFC 602: The Stockings Were Hung by the Chimney with Care. RFC 602 was posted by Bob Metcalfe in December, 1973. The subject matter concerned weak passwords. In it, Metcalfe writes: The ARPA Computer Network is susceptible to security violations for at least the three following reasons:

1. Individual sites, used to physical limitations on machine access, have not yet taken sufficient precautions toward securing their systems against unauthorized remote use. For example, many people still use passwords which are easy to guess: their fist [sic] names, their initials, their host name spelled backwards, a string of characters which are easy to type in sequence (such as ZXCVBNM).

2. The TIP allows access to the ARPANET to a much wider audience than is thought or intended. TIP phone numbers are posted, like those scribbled hastily on the walls of phone booths and men's rooms. The TIP required no user identification before giving service. Thus, many people, including those who used to spend their time ripping off Ma Bell, get access to our stockings in a most anonymous way.

3. There is lingering affection for the challenge of breaking someone's system. This affection lingers despite the fact that everyone knows that it's easy to break systems, even easier to crash them.

All of this would be quite humorous and cause for raucous eye winking and elbow nudging, if it weren't for the fact that in recent weeks at least two major serving hosts were crashed under suspicious circumstances by people who knew what they were risking; on yet a third system, the system wheel password was compromised--by two high school students in Los Angeles no less. We suspect that the number of dangerous security violations is larger than any of us know is growing. You are advised not to sit "in hope that Saint Nicholas would soon be there." That document was posted well over 20 years ago. Naturally, this password problem is no longer an issue. Or is it? Examine this excerpt from a Defense Data Network Security Bulletin, written in 1993:

Host Administrators must assure that passwords are kept secret by their users. Host Administrators must also assure that passwords are robust enough to thwart exhaustive attack by password cracking mechanisms, changed periodically and that password files are adequately protected. Passwords should be changed at least annually.

Take notice. In the more than 25 years of the Internet's existence, it has never been secure. That's a fact. Later in this book, I will try to explain why. For now, however, I confine our inquiry to a narrow question: Just who can be cracked?

The short answer is this: As long as a person maintains a connection to the Internet (permanent or otherwise), he or she can be cracked. Before treating this subject in depth, however, I want to define cracked.

What Is Meant by the Term Cracked?

For our purposes, cracked refers to that condition in which the victim network has suffered an unauthorized intrusion. There are various degrees of this condition, each of which is discussed at length within this book. Here, I offer a few examples of this cracked condition:

To be fair, modern security techniques have made cracking more difficult. However, the gorge between the word difficult and the word impossible is wide indeed. Today, crackers have access to (and often study religiously) a wealth of security information, much of which is freely available on the Internet. The balance of knowledge between these individuals and bona-fide security specialists is not greatly disproportionate. In fact, that gap is closing each day.

The purpose of this chapter is to show you that cracking is a common activity: so common that assurances from anyone that the Internet is secure should be viewed with extreme suspicion. To drive that point home, I will begin with governmental entities. After all, defense and intelligence agencies form the basis of our national security infrastructure. They, more than any other group, must be secure.

Government

Throughout the Internet's history, government sites have been popular targets among crackers. This is due primarily to press coverage that follows such an event. Crackers enjoy any media attention they can get. Hence, their philosophy is generally this: If you're going to crack a site, crack one that matters.

Are crackers making headway in compromising our nation's most secure networks? Absolutely. To find evidence that government systems are susceptible to attack, one needn't look far. A recent report filed by the Government Accounting Office (GAO) concerning the security of the nation's defense networks concluded that:

Defense may have been attacked as many as 250,000 times last year...In addition, in testing its systems, DISA attacks and successfully penetrates Defense systems 65 percent of the time. According to Defense officials, attackers have obtained and corrupted sensitive information--they have stolen, modified, and destroyed both data and software. They have installed unwanted files and "back doors" which circumvent normal system protection and allow attackers unauthorized access in the future. They have shut down and crashed entire systems and networks, denying service to users who depend on automated systems to help meet critical missions. Numerous Defense functions have been adversely affected, including weapons and supercomputer research, logistics, finance, procurement, personnel management, military health, and payroll.1


1Information Security: Computer Attacks at Department of Defense Pose Increasing Risks (Chapter Report, 05/22/96, GAO/AIMD-96-84); Chapter 0:3.2, Paragraph 1.


Cross Reference: Information Security: Computer Attacks at Department of Defense Pose Increasing Risks is available online at http://www.securitymanagement.com/library/000215.html.

That same report revealed that although more than one quarter of a million attacks occur annually, only 1 in 500 attacks are actually detected and reported. (Note that these sites are defense oriented and therefore implement more stringent security policies than many commercial sites. Many government sites employ secure operating systems that also feature advanced, proprietary security utilities.)

Government agencies, mindful of the public confidence, understandably try to minimize these issues. But some of the incidents are difficult to obscure. For example, in 1994, crackers gained carte-blanche access to a weapons-research laboratory in Rome, New York. Over a two-day period, the crackers downloaded vital national security information, including wartime- communication protocols.

Such information is extremely sensitive and, if used improperly, could jeopardize the lives of American service personnel. If crackers with relatively modest equipment can access such information, hostile foreign governments (with ample computing power) could access even more.

SATAN and Other Tools

Today, government sites are cracked with increasing frequency. The authors of the GAO report attribute this largely to the rise of user-friendly security programs (such as SATAN). SATAN is a powerful scanner program that automatically detects security weaknesses in remote hosts. It was released freely on the Net in April, 1995. Its authors, Dan Farmer and Weitse Venema, are legends in Internet security. (You will learn more about these two gentlemen in Chapter 9, "Scanners.")

Because SATAN is conveniently operated through an HTML browser (such as Netscape Navigator or NCSA Mosaic), a cracker requires less practical knowledge of systems. Instead, he or she simply points, clicks, and waits for an alert that SATAN has found a vulnerable system (at least this is what the GAO report suggests). Is it true?

No. Rather, the government is making excuses for its own shoddy security. Here is why: First, SATAN runs only on UNIX platforms. Traditionally, such platforms required expensive workstation hardware. Workstation hardware of this class is extremely specialized and isn't sold at the neighborhood Circuit City store. However, those quick to defend the government make the point that free versions of UNIX now exist for the IBM-compatible platform. One such distribution is a popular operating system named Linux.

Linux is a true 32-bit, multi-user, multi-tasking, UNIX-like operating system. It is a powerful computing environment and, when installed on the average PC, grants the user an enormous amount of authority, particularly in the context of the Internet. For example, Linux distributions now come stocked with every manner of server ever created for TCP/IP transport over the Net.


Cross Reference: Linux runs on a wide range of platforms, not just IBM compatibles. Some of those platforms include the Motorola 68k, the Digital Alpha, the Motorola PowerPC, and even the Sun Microsystems SPARC architecture. If you want to learn more about Linux, go to the ultimate Linux page at http://www.linux.org/.

Distributions of Linux are freely available for download from the Net, or can be obtained at any local bookstore. CD-ROM distributions are usually bundled with books that instruct users on using Linux. In this way, vendors can make money on an otherwise, ostensibly free operating system. The average Linux book containing a Linux installation CD-ROM sells for forty dollars.

Furthermore, most Linux distributions come with extensive development tools. These include a multitude of language compilers and interpreters:

Yet, even given these facts, the average kid with little knowledge of UNIX cannot implement a tool such as SATAN on a Linux platform. Such tools rarely come prebuilt in binary form. The majority are distributed as source code, which may then be compiled with options specific to the current platform. Thus, if you are working in AIX (IBM's proprietary version of UNIX), the program must be compiled for AIX. If working in Ultrix (DEC), it must be compiled for Ultrix, and so on.


NOTE: A port was available for Linux not long after SATAN was released. However, the bugs were not completely eliminated and the process of installing and running SATAN would still remain an elusive and frustrating experience for many Linux users. The process of developing an easily implemented port was slow in coming.

Most PC users (without UNIX experience) are hopelessly lost even at the time of the Linux installation. UNIX conventions are drastically different from those in DOS. Thus, before a new Linux user becomes even moderately proficient, a year of use will likely pass. This year will be spent learning how to use MIT's X Window System, how to configure TCP/IP settings, how to get properly connected to the Internet, and how to unpack software packages that come in basic source-code form.

Even after the year has passed, the user may still not be able to use SATAN. The SATAN distribution doesn't compile well on the Linux platform. For it to work, the user must have installed the very latest version of Perl. Only very recent Linux distributions (those released within one year of the publishing of this book) are likely to have such a version installed. Thus, the user must also know how to find, retrieve, unpack, and properly install Perl.

In short, the distance between a non-UNIX literate PC user and one who effectively uses SATAN is very long indeed. Furthermore, during that journey from the former to the latter, the user must have ample time (and a brutal resolve) to learn. This is not the type of journey made by someone who wants to point and click his or her way to super-cracker status. It is a journey undertaken by someone deeply fascinated by operating systems, security, and the Internet in general.

So the government's assertion that SATAN, an excellent tool designed expressly to improve Internet security, has contributed to point-and-click cracking is unfounded. True, SATAN will perform automated scans for a user. Nonetheless, that user must have strong knowledge of Internet security, UNIX, and several programming languages.

There are also collateral issues regarding the machine and connection type. For example, even if the user is seasoned, he or she must still have adequate hardware power to use SATAN effectively.


Cross Reference: You will examine SATAN (and programs like it) in greater detail in Chapter 9. In that chapter, you will be familiarized with many scanners, how they work, how they are designed, and the type of information they can provide for users.

SATAN is not the problem with government sites. Indeed, SATAN is not the only diagnostic tool that can automatically identify security holes in a system. There are dozens of such tools available:

Chapter 9 examines these automated tools and their methods of operation. For now, I will simply say this: These tools operate by attacking the available TCP/IP services and ports open and running on remote systems.

Whether available to a limited class of users or worldwide, these tools share one common attribute: They check for known holes. That is, they check for security vulnerabilities that are commonly recognized within the security community. The chief value of such tools is their capability to automate the process of checking one or more machines (hundreds of machines, if the user so wishes). These tools accomplish nothing more than a knowledgeable cracker might by hand. They simply automate the process.

Education and Awareness About Security

The problem is not that such tools exist, but that education about security is poor. Moreover, the defense information networks are operating with archaic internal security policies. These policies prevent (rather than promote) security. To demonstrate why, I want to refer to the GAO report I mentioned previously. In it, the government concedes:

...The military services and Defense agencies have issued a number of information security policies, but they are dated, inconsistent and incomplete...

The report points to a series of Defense Directives as examples. It cites (as the most significant DoD policy document) Defense Directive 5200.28. This document, Security Requirements for Automated Information Systems, is dated March 21, 1988.

In order to demonstrate the real problem here, let's examine a portion of that Defense Directive. Paragraph 5 of Section D of that document is written as follows:

Computer security features of commercially produced products and Government-developed or -derived products shall be evaluated (as requested) for designation as trusted computer products for inclusion on the Evaluated Products List (EPL). Evaluated products shall be designated as meeting security criteria maintained by the National Computer Security Center (NCSC) at NSA defined by the security division, class, and feature (e.g., B, B1, access control) described in DoD 5200.28-STD (reference (K)).


Cross Reference: Security Requirements for Automated Information Systems is available on the Internet at http://140.229.1.16:9000/htdocs/teinfo/directives/soft/5200.28.html

It is within the provisions of that paragraph that the government's main problem lies. The Evaluated Products List (EPL) is a list of products that have been evaluated for security ratings, based on DoD guidelines. (The National Security Agency actually oversees the evaluation.) Products on the list can have various levels of security certification. For example, Windows NT version 3.51 has obtained a certification of C2. This is a very limited security certification.


Cross Reference: Before you continue, you should probably briefly view the EPL for yourself. Check it out at http://www.radium.ncsc.mil/tpep/epl/index.html.

The first thing you will notice about this list is that most of the products are old. For example, examine the EPL listing for Trusted Information Systems' Trusted XENIX, a UNIX-based operating system.


Cross Reference: The listing for Trusted XENIX can be found at http://www.radium.ncsc.mil/tpep/epl/entries/CSC-EPL-92-001-A.html

If you examine the listing closely, you will be astonished. TIS Trusted XENIX is indeed on the EPL. It is therefore endorsed and cleared as a safe system, one that meets the government's guidelines (as of September 1993). However, examine even more closely the platforms on which this product has been cleared. Here are a few:

These architectures are ancient. They are so old that no one would actually use them, except perhaps as a garage hacking project on a nice Sunday afternoon (or perhaps if they were legacy systems that housed software or other data that was irreplaceable). In other words, by the time products reach the EPL, they are often pathetically obsolete. (The evaluation process is lengthy and expensive not only for the vendor, but for the American people, who are footing the bill for all this.) Therefore, you can conclude that much of the DoD's equipment, software, and security procedures are likewise obsolete.

Now, add the question of internal education. Are Defense personnel trained in (and implementing) the latest security techniques? No. Again, quoting the GAO report:

Defense officials generally agreed that user awareness training was needed, but stated that installation commanders do not always understand computer security risk and thus, do not always devote sufficient resources to the problem.

High-Profile Cases

Lack of awareness is pervasive, extending far beyond the confines of a few isolated Defense sites. It is a problem that affects many federal agencies throughout the country. Evidence of it routinely appears on the front pages of our nation's most popular newspapers. Indeed, some very high-profile government sites were cracked in 1996, including the Central Intelligence Agency (CIA) and the Department of Justice (DoJ).


Cross Reference: To see the CIA site in its hacked state, visit http://www.skeeve.net/cia/.


NOTE: skeeve.net was one of many sites that preserved the hacked CIA page, primarily for historical purposes. It is reported that after skeeve.net put the hacked CIA page out for display, its server received hundreds of hits from government sites, including the CIA. Some of these hits involved finger queries and other snooping utilities.


Cross Reference: The DoJ site, in its hacked state, can be viewed at http://river-city.clever.net/hacked/doj/.

As of this writing, neither case has been solved; most likely, neither will ever be. Both are reportedly being investigated by the FBI.

Typically, government officials characterize such incidents as rare. Just how rare are they? Not very. In the last year, many such incidents have transpired:

The phenomenon was not limited to federal agencies. In October, 1996, the home page of the Florida State Supreme Court was cracked. Prior to its cracking, the page's intended use was to distribute information about the court, including text reproductions of recent court decisions. The crackers removed this information and replaced it with pornography. Ironically, the Court subsequently reported an unusually high rate of hits.

In 1996 alone, at least six high-profile government sites were cracked. Two of these (the CIA and FBI) were organizations responsible for maintaining departments for information warfare or computer crime. Both are charged with one or more facets of national security. What does all this mean? Is our national security going down the tubes? It depends on how you look at it.

In the CIA and FBI cases, the cracking activity was insignificant. Neither server held valuable information, and the only real damage was to the reputation of their owners. However, the Rome, New York case was far more serious (as was the case at Fort Bragg). Such cases demonstrate the potential for disaster.

There is a more frightening aspect to this: The sites mentioned previously were WWW sites, which are highly visible to the public. Therefore, government agencies cannot hide when their home pages have been cracked. But what about when the crack involves some other portion of the targeted system (a portion generally unseen by the public)? It's likely that when such a crack occurs, the press is not involved. As such, there are probably many more government cracks that you will never hear about.

To be fair, the U.S. government is trying to keep up with the times. In January 1997, a reporter for Computerworld magazine broke a major story concerning Pentagon efforts to increase security. Apparently, the Department of Defense is going to establish its own tiger team (a group of individuals whose sole purpose will be to attack DoD computers). Such attacks will reveal key flaws in DoD security.

Other stories indicate that defense agencies have undertaken new and improved technologies to protect computers holding data vital to national security. However, as reported by Philip Shenon, a prominent technology writer for the New York Times:

While the Pentagon is developing encryption devices that show promise in defeating computer hackers, the accounting office, which is the investigative arm of Congress, warned that none of the proposed technical solutions was foolproof, and that the military's current security program was `dated, inconsistent and incomplete.'

The Pentagon's activity to develop devices that "show promise in defeating computer hackers" appears reassuring. From this, one could reasonably infer that something is being done about the problem. However, the reality and seriousness of the situation is being heavily underplayed.

If Defense and other vital networks cannot defend against domestic attacks from crackers, there is little likelihood that they can defend from hostile foreign powers. I made this point earlier in the chapter, but now I want to expand on it.

Can the United States Protect the National Information Infrastructure?

The United States cannot be matched by any nation for military power. We have sufficient destructive power at our disposal to eliminate the entire human race. So from a military standpoint, there is no comparison between the United States and even a handful of third-world nations. The same is not true, however, in respect to information warfare.

The introduction of advanced minicomputers has forever changed the balance of power in information warfare. The average Pentium processor now selling at retail computer chains throughout the country is more powerful than many mainframes were five years ago (it is certainly many times faster). Add the porting of high-performance UNIX-based operating systems to the IBM platform, and you have an entirely new environment.

A third-world nation could pose a significant threat to our national information infrastructure. Using the tools described previously (and some high-speed connections), a third-world nation could effectively wage a successful information warfare campaign against the United States at costs well within their means. In fact, it is likely that within the next few years, we'll experience incidents of bona-fide cyberterrorism.

To prepare for the future, more must be done than simply allocating funds. The federal government must work closely with security organizations and corporate entities to establish new and improved standards. If the new standards do not provide for quicker and more efficient means of implementing security, we will be faced with very dire circumstances.

Who Holds the Cards?

This (not legitimate security tools such as SATAN) is the problem: Thirty years ago, the U.S. government held all the cards with respect to technology. The average U.S. citizen held next to nothing. Today, the average American has access to very advanced technology. In some instances, that technology is so advanced that it equals technology currently possessed by the government. Encryption technology is a good example.

Many Americans use encryption programs to protect their data from others. Some of these encryption programs (such as the very famous utility PGP, created by Phil Zimmermann) produce military-grade encryption. This level of encryption is sufficiently strong that U.S. intelligence agencies cannot crack it (at least not within a reasonable amount of time, and often, time is of the essence).

For example, suppose one individual sends a message to another person regarding the date on which they will jointly blow up the United Nations building. Clearly, time is of the essence. If U.S. intelligence officials cannot decipher this message before the date of the event, they might as well have not cracked the message at all.

This principle applies directly to Internet security. Security technology has trickled down to the masses at an astonishing rate. Crackers (and other talented programmers) have taken this technology and rapidly improved it. Meanwhile, the government moves along more slowly, tied down by restrictive and archaic policies. This has allowed the private sector to catch up (and even surpass) the government in some fields of research.

This is a matter of national concern. Many grass-roots radical cracker organizations are enthralled with these circumstances. They often heckle the government, taking pleasure in the advanced knowledge that they possess. These are irresponsible forces in the programming community, forces that carelessly perpetuate the weakening of the national information infrastructure. Such forces should work to assist and enlighten government agencies, but they often do not, and their reasons are sometimes understandable.

The government has, for many years, treated crackers and even hackers as criminals of high order. As such, the government is unwilling to accept whatever valuable information these folks have to offer. Communication between these opposing forces is almost always negative. Bitter legal disputes have developed over the years. Indeed, some very legitimate security specialists have lost time, money, and dignity at the hands of the U.S. government. On more than one occasion, the government was entirely mistaken and ruined (or otherwise seriously disrupted) the lives of law-abiding citizens. In the next chapter, I will discuss a few such cases. Most arise out of the government's poor understanding of the technology.

New paths of communication should be opened between the government and those in possession of advanced knowledge. The Internet marginally assists in this process, usually through devices such as mailing lists and Usenet. However, there is currently no concerted effort to bring these opposing forces together on an official basis. This is unfortunate because it fosters a situation where good minds in America remain pitted against one another. Before we can effectively defend our national information infrastructure, we must come to terms with this problem. For the moment, we are at war with ourselves.

The Public Sector

I realize that a category such as the public sector might be easily misunderstood. To prevent that, I want to identify the range of this category. Here, the public sector refers to any entity that is not a government, an institution, or an individual. Thus, I will be examining companies (public and private), Internet service providers, organizations, or any other entity of commercial or semi-commercial character.

Before forging ahead, one point should be made: Commercial and other public entities do not share the experience enjoyed by government sites. In other words, they have not yet been cracked to pieces. Only in the past five years have commercial entities flocked to the Internet. Therefore, some allowances must be made. It is unreasonable to expect these folks to make their sites impenetrable. Many are smaller companies and for a moment, I want to address these folks directly: You, more than any other group, need to acquire sound security advice.

Small companies operate differently from large ones. For the little guy, cost is almost always a strong consideration. When such firms establish an Internet presence, they usually do so either by using in-house technical personnel or by recruiting an Internet guru. In either case, they are probably buying quality programming talent. However, what they are buying in terms of security may vary.

Large companies specializing in security charge a lot of money for their services. Also, most of these specialize in UNIX security. So, small companies seeking to establish an Internet presence may avoid established security firms. First, the cost is a significant deterrent. Moreover, many small companies do not use UNIX. Instead, they may use Novell NetWare, LANtastic, Windows NT, Windows 95, and so forth.

This leaves small businesses in a difficult position. They must either pay high costs or take their programmers' word that the network will be secure. Because such small businesses usually do not have personnel who are well educated in security, they are at the mercy of the individual charged with developing the site. That can be a very serious matter.

The problem is many "consultants" spuriously claim to know all about security. They make these claims when, in fact, they may know little or nothing about the subject. Typically, they have purchased a Web-development package, they generate attractive Web pages, and know how to set up a server. Perhaps they have a limited background in security, having scratched the surface. They take money from their clients, rationalizing that there is only a very slim chance that their clients' Web servers will get hacked. For most, this works out well. But although their clients' servers never get hacked, the servers may remain indefinitely in a state of insecurity.

Commercial sites are also more likely to purchase one or two security products and call it a day. They may pay several thousand dollars for an ostensibly secure system and leave it at that, trusting everything to that single product.

For these reasons, commercial sites are routinely cracked, and this trend will probably continue. Part of the problem is this: There is no real national standard on security in the private sector. Hence, one most often qualifies as a security specialist through hard experience and not by virtue of any formal education. It is true that there are many courses available and even talks given by individuals such as Farmer and Venema. These resources legitimately qualify an individual to do security work. However, there is no single piece of paper that a company can demand that will ensure the quality of the security they are getting.

Because these smaller businesses lack security knowledge, they become victims of unscrupulous "security specialists." I hope that this trend will change, but I predict that for now, it will only become more prevalent. I say this for one reason: Despite the fact that many thousands of American businesses are now online, this represents a mere fraction of commercial America. There are millions of businesses that have yet to get connected. These millions are all new fish, and security charlatans are lined up waiting to catch them.

The Public Sector Getting Cracked

In the last year, a series of commercial sites have come under attack. These attacks have varied widely in technique. Earlier in this chapter, I defined some of those techniques and the attending damage or interruption of service they cause. Here, I want to look at cases that more definitively illustrate these techniques. Let's start with the recent attack on Panix.com.

Panix.com

Panix.com (Public Access Networks Corporation) is a large Internet service provider (ISP) that provides Internet access to several hundred thousand New York residents. On September 6, 1996, Panix came under heavy attack from the void.

The Panix case was very significant because it demonstrates a technique known as the Denial of Service (DoS) attack. This type of attack does not involve an intruder gaining access. Instead, the cracker undertakes remote procedures that render a portion (or sometimes all) of a target inoperable.

The techniques employed in such an attack are simple. As you will learn in Chapter 6, "A Brief Primer on TCP/IP," connections over the Internet are initiated via a procedure called the three-part handshake. In this process, the requesting machine sends a packet requesting connection. The target machine responds with an acknowledgment. The requesting machine then returns its own acknowledgment and a connection is established.

In a syn_flooder attack, the requesting (cracker's) machine sends a series of connection requests but fails to acknowledge the target's response. Because the target never receives that acknowledgment, it waits. If this process is repeated many times, it renders the target's ports useless because the target is still waiting for the response. These connection requests are dealt with sequentially; eventually, the target will abandon waiting for each such acknowledgment. Nevertheless, if it receives tens or even hundreds of these requests, the port will remain engaged until it has processed--and discarded--each request.


NOTE: The term syn_flooder is derived from the activity undertaken by such tools. The TCP/IP three-way handshake is initiated when one machine sends another a SYN packet. In a typical flooding attack, a series of these packets are forwarded to a target, purporting to be from an address that is nonexistent. The target machine therefore cannot resolve the host. In any event, by sending a flurry of these SYN packets, one is flooding the target with requests that cannot be fulfilled.

Syn_flooder attacks are common, but do no real damage. They simply deny other users access to the targeted ports temporarily. In the Panix case, though, temporarily was a period lasting more than a week.

Syn_flooders are classified in this book as destructive devices. They are covered extensively in Chapter 14, "Destructive Devices." These are typically small programs consisting of two hundred lines of code or fewer. The majority are written in the C programming language, but I know of at least one written in BASIC.

Crack dot Com

ISPs are popular targets for a variety of reasons. One reason is that crackers use such targets as operating environments or a home base from which to launch attacks on other targets. This technique assists in obscuring the identity of the attacker, an issue we will discuss. However, DoS attacks are nothing special. They are the modern equivalent of ringing someone's telephone repeatedly to keep the line perpetually engaged. There are far more serious types of cracks out there. Just ask Crack dot Com, the manufacturers of the now famous computer game Quake.

In January, 1997, crackers raided the Crack dot Com site. Reportedly, they cracked the Web server and proceeded to chip away at the firewall from that location. After breaking through the firewall, the crackers gained carte-blanche access to the internal file server. From that location, they took the source code for both Quake and a new project called Golgotha. They posted this source code on the Net.


NOTE: For those of you who are not programmers, source code is the programming code of an application in its raw state. This is most often in human-readable form, usually in plain English. After all testing of the software is complete (and there are no bugs within it), this source code is sent a final time through a compiler. Compilers interpret the source code and from it fashion a binary file that can be executed on one or more platforms. In short, source code can be though of as the very building blocks of a program. In commercial circles, source code is jealously guarded and aggressively proclaimed as proprietary material. For someone to take that data from a server and post it indiscriminately to the Internet is probably a programmer's worst nightmare.

For Crack dot Com, the event could have far-reaching consequences. For example, it's possible that during the brief period that the code was posted on the Net, its competitors may have obtained copies of (at least some of) the programming routines. In fact, the crackers could have approached those competitors in an effort to profit from their activities. This, however, is highly unlikely. The crackers' pattern of activity suggests that they were kids. For example, after completing the crack, they paraded their spoils on Internet Relay Chat. They also reportedly left behind a log (a recording of someone's activity while connected to a given machine). The Crack dot Com case highlights the seriousness of the problem, however.

Kriegsman Furs

Another interesting case is that of Kriegsman Furs of Greensborough, North Carolina. This furrier's Web site was cracked by an animal-rights activist. The cracker left behind a very strong message, which I have reproduced in part:

Today's consumer is completely oblivious to what goes on in order for their product to arrive at the mall for them to buy. It is time that the consumer be aware of what goes on in many of today's big industries. Most importantly, the food industries. For instance, dairy cows are injected with a chemical called BGH that is very harmful to both humans and the cows. This chemical gives the cows bladder infections. This makes the cows bleed and guess what? It goes straight in to your bowl of cereal. Little does the consumer know, nor care. The same kind of thing goes on behind the back of fur wearers. The chemicals that are used to process and produce the fur are extremely bad for our earth. Not only that, but millions of animals are slaughtered for fur and leather coats. I did this in order to wake up the blind consumers of today. Know the facts.

Following this message were a series of links to animal-rights organizations and resources.

Kevin Mitnik

Perhaps the most well-known case of the public sector being hacked, however, is the 1994/1995 escapades of famed computer cracker Kevin Mitnik. Mitnik has been gaining notoriety since his teens, when he cracked the North American Aerospace Defense Command (NORAD). The timeline of his life is truly amazing, spanning some 15 years of cracking telephone companies, defense sites, ISPs, and corporations. Briefly, some of Mitnik's previous targets include

On December 25, 1994, Mitnik reportedly cracked the computer network of Tsutomu Shimomura, a security specialist at the San Diego Supercomputer Center. What followed was a press fiasco that lasted for months. The case might not have been so significant were it not for three factors:

First, Shimomura, though never before particularly famous, was known in security circles. He, more than anyone, should have been secure. The types of tools he was reportedly developing would have been of extreme value to any cracker. Moreover, Shimomura has an excellent grasp of Internet security. When he got caught with his pants down (as it were), it was a shock to many individuals in security. Naturally, it was also a delight to the cracker community. For some time afterward, the cracking community was enthralled by the achievement, particularly because Shimomura had reportedly assisted various federal agencies on security issues. Here, one of the government's best security advisors had been cracked to pieces by a grass-roots outlaw (at least, that was the hype surrounding the case).

Second, the technique used, now referred to as IP spoofing, was complex and not often implemented. IP spoofing is significant because it relies on an exchange that occurs between two machines at the system level. Normally, when a user attempts to log in to a machine, he or she is issued a login prompt. When the user provides a login ID, a password prompt is given. The user issues his or her password and logs in (or, he or she gives a bad or incorrect password and does not log in). Thus, Internet security breaches have traditionally revolved around getting a valid password, usually by obtaining and cracking the main password file.

IP spoofing differs from this radically. Instead of attempting to interface with the remote machine via the standard procedure of the login/password variety, the IP-spoofing cracker employs a much more sophisticated method that relies in part on trust. Trust is defined and referred to in this book (unless otherwise expressly stated) as the "trust" that occurs between two machines that identify themselves to one another via IP addresses.

In IP spoofing, a series of things must be performed before a successful break-in can be accomplished:

(Be mindful that this brief description is bare bones. I treat this subject extensively in its own chapter, Chapter 28, "Spoofing Attacks.")

In the attack, the target machine trusted the other. Whenever a login occurred between these two machines, it was authenticated through an exchange of numbers. This number exchange followed a forward/challenge scenario. In other words, one machine would generate a number to which the other must answer (also with a number). The key to the attack was to forge the address of the trusted machine and provide the correct responses to the other machine's challenges. And, reportedly, that is exactly what Mitnik did.

In this manner, privileged access is gained without ever passing a single password or login ID over the network. All exchanges happen deep at the system level, a place where humans nearly never interact with the operating system.

Curiously, although this technique has been lauded as new and innovative, it is actually quite antiquated (or at least, the concept is quite antiquated). It stems from a security paper written by Robert T. Morris in 1985 titled A Weakness in the 4.2BSD UNIX TCP/IP Software. In this paper, Morris (then working for AT&T Bell Laboratories) concisely details the ingredients to make such an attack successful. Morris opens the paper with this statement:

The 4.2 Berkeley Software Distribution of the UNIX operating system (4.2BSD for short) features an extensive body of software based on the "TCP/IP" family of protocols. In particular, each 4.2BSD system "trusts" some set of other systems, allowing users logged into trusted systems to execute commands via a TCP/IP network without supplying a password. These notes describe how the design of TCP/IP and the 4.2BSD implementation allow users on untrusted and possibly very distant hosts to masquerade as users on trusted hosts. Bell Labs has a growing TCP/IP network connecting machines with varying security needs; perhaps steps should be taken to reduce their vulnerability to each other.

Morris then proceeds to describe such an attack in detail, some ten years before the first widely reported instance of such an attack had occurred. One wonders whether Mitnik had seen this paper (or even had it sitting on his desk whilst the deed was being done).

In any event, the break-in caused a stir. The following month, the New York Times published an article about the attack. An investigation resulted, and Shimomura was closely involved. Twenty days later, Shimomura and the FBI tracked Mitnik to an apartment in North Carolina, the apparent source of the attack. The case made national news for weeks as the authorities sorted out the evidence they found at Mitnik's abode. Again, America's most celebrated computer outlaw was behind bars.

In my view, the case demonstrates an important point, the very same point we started with at the beginning of this chapter: As long as they are connected to the Net, anyone can be cracked. Shimomura is a hacker and a good one. He is rumored to own 12 machines running a variety of operating systems. Moreover, Shimomura is a talented telephone phreak (someone skilled in manipulating the technology of the telephone system and cellular devices). In essence, he is a specialist in security. If he fell victim to an attack of this nature, with all the tools at his disposal, the average business Web site is wide open to assault over the Internet.


In defense of Shimomura: Many individuals in security defend Shimomura. They earnestly argue that Shimomura had his site configured to bait crackers. In Chapter 26, "Levels of Attack," you will learn that Shimomura was at least marginally involved in implementing this kind of system in conjunction with some folks at Bell Labs. However, this argument in Shimomura's defense is questionable. For example, did he also intend to allow these purportedly inept crackers to seize custom tools he had been developing? If not, the defensive argument fails. Sensitive files were indeed seized from Shimomura's network. Evidence of these files on the Internet is now sparse. No doubt, Shimomura has taken efforts to hunt them down. Nevertheless, I have personally seen files that Mitnik reportedly seized from many networks, including Netcom. Charles Platt, in his scathing review of Shimomura's book Takedown, offers a little slice of reality:

Kevin Mitnick...at least he shows some irreverence, taunting Shimomura and trying to puncture his pomposity. At one point, Mitnick bundles up all the data he copied from Shimomura's computer and saves it onto the system at Netcom where he knows that Shimomura will find it....Does Shimomura have any trouble maintaining his dignity in the face of these pranks? No trouble at all. He writes: "This was getting personal. ... none of us could believe how childish and inane it all sounded."

It is difficult to understand why Shimomura would allow crackers (coming randomly from the void) to steal his hard work and excellent source code. My opinion (which may be erroneous) is that Shimomura did indeed have his boxes configured to bait crackers; he simply did not count on anyone cutting a hole through that baited box to his internal network. In other words, I believe that Shimomura (who I readily admit is a brilliant individual) got a little too confident. There should have been no relationship of trust between the baited box and any other workstation.



Cross Reference: Charles Platt's critique of Takedown, titled A Circumlocuitous review of Takedown by Tsutomu Shimomura and John Markoff, can be found at http://rom.oit.gatech.edu/~willday/mitnick/takedown.review.html.

Summary

These cases are all food for thought. In the past 20 or so years, there have been several thousand such cases (of which we are aware). The military claims that it is attacked over 250,000 times a year. Estimates suggest it is penetrated better than half of the time. It is likely that no site is entirely immune. (If such a site exists, it is likely AT&T Bell Laboratories; it probably knows more about network security than any other single organization on the Internet.)

All this having been established, I'd like to get you started. Before you can understand how to hack (or crack), however, you must first know a bit about the network. Part II of this book, "Understanding the Terrain," deals primarily with the Internet's development and design.