totse.com | Maximum Security: A Hacker's Guide to Protecting Your Internet Site and Network

NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.

My acknowledgments are brief. First, I would like to acknowledge the folks at Sams, particularly Randi Roger, Scott Meyers, Mark Taber, Blake Hall, Eric Murray, Bob Correll, and Kate Shoup. Without them, my work would resemble a tangled, horrible mess. They are an awesome editing team and their expertise is truly extraordinary.

Next, I extend my deepest gratitude to Michael Michaleczko, and Ron and Stacie Latreille. These individuals offered critical support, without which this book could not have been written.

Also, I would like to recognize the significant contribution made by John David Sale, a network security specialist located in Van Nuys, California. His input was invaluable. A similar thanks is also extended to Peter Benson, an Internet and EDI Consultant in Santa Monica, California (who, incidentally, is the current chairman of ASC X12E). Peter's patience was (and is) difficult to fathom. Moreover, I forward a special acknowledgment to David Pennells and his merry band of programmers. Those cats run the most robust and reliable wire in the southwestern United States.

The author describes himself as a "UNIX propeller head" and is a dedicated advocate of the Perl programming language, Linux, and FreeBSD.

After spending four years as a system administrator for two California health-care firms, the author started his own security-consulting business. Currently, he specializes in testing the security of various networking platforms (breaking into computer networks and subsequently revealing what holes lead to the unauthorized entry) including but not limited to Novell NetWare, Microsoft Windows NT, SunOS, Solaris, Linux, and Microsoft Windows 95. His most recent assignment was to secure a wide area network that spans from Los Angeles to Montreal.

The author now lives quietly in southern California with a Sun SPARCStation, an IBM RS/6000, two Pentiums, a Macintosh, various remnants of a MicroVAX, and his wife.

In the late 1980s, the author was convicted of a series of financial crimes after developing a technique to circumvent bank security in Automatic Teller Machine systems. He therefore prefers to remain anonymous.

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

The possibility of angering vendors that have yet to close security holes within their software

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:

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 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.
6. Rename the folder The Microsoft Windows 95 Product Team!.
7. 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

Sample networking programs 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 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 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

Allow crackers to exploit that weakness (or improper operation) to damage or gain control of a system

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 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:

When the affected application is comprehensively tied to the operating-system source

When the application is third-party software and that third party has poor support, has gone out of business, or is otherwise unavailable In these instances, a patch (or other solution) can provide temporary relief. However, for this system to work effectively, all users must know that the patch is available. Notifying the public would seem to be the vendor's responsibility and, to be fair, vendors post such patches to security groups and mailing lists. However, vendors might not always take the extra step of informing the general public. In many cases, it just isn't cost effective.

Once again, this issue breaks down to knowledge. Users who have 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.

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.

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.

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.

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.

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).

To generally heighten public awareness of the need for adequate security 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.

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? 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:

Evolutionary ordering (where each chapter arises, in some measure, from information in an earlier one)

Developmental ordering (where you travel from the very simple to the complex) 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.)

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:

If you are charged with understanding in detail a certain aspect of security, follow the notes closely. Full citations appear in these notes, often showing multiple locations for a security document, RFC, FYI, or IDraft. Digested versions of such documents can never replace having the original, unabridged text.

The end of each chapter contains a small rehash of the information covered. For extremely handy reference, especially for those already familiar with the utilities and concepts discussed, this "Summary" portion of the chapter is quite valuable.

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 next sections describe the book's various parts. Contained within each description is a list of subjects covered within that chapter.

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

Why I wrote this book
Why you need security
Definitions of hacking and cracking
Who is vulnerable to attack

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 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

Who created the Internet and why
How the Internet is designed and how it works
Poor security on the Internet and the reasons for it
Internet warfare as it relates to individuals and networks

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 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

Password crackers
Trojans
Sniffers
Tools to aid in obscuring one's identity
Scanners
Destructive devices, such as e-mail bombs and viruses

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 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

Microsoft
UNIX
Novell
VAX/VMS
Macintosh
Plan 9 from Bell Labs 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

Root, supervisor, and administrator accounts
Techniques of breaching security internally
Security concepts and philosophy

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

Definition of a remote attack
Various levels of attack and their dangers
Sniffing techniques
Spoofing techniques
Attacks on Web servers
Attacks based on weaknesses within various programming languages

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

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:

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.

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.

Protect your network
Learn about security
Crack an Internet server
Educate your staff
Write an informed article about security
Institute a security policy
Design a secure program
Engage in Net warfare
Have some fun

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.

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.

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 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

The WHOIS Database--This database contains all the names and network numbers of hosts (or machines) permanently connected to the Internet in the United States (except *.mil addresses, which must be obtained at nic.ddn.mil).

The Directory of Directories--This is a massive listing of nearly all resources on the Internet, broken into categories.

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

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:

The intruder gains access and nothing more (access being defined as simple entry; entry that is unauthorized on a network that requires--at a minimum--a login and password).

The intruder gains access and seizes control of a compartmentalized portion of the system or the whole system, perhaps denying access even to privileged users.

The intruder does NOT gain access, but instead implements malicious procedures that cause that network to fail, reboot, hang, or otherwise manifest an inoperable condition, either permanently or temporarily. 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.

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 1 Information 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.

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:

A C language compiler
A C++ language compiler
A SmallTalk interpreter
A BASIC interpreter
A Perl interpreter
Tools for FORTRAN
Tools for Pascal
A common LISP interpreter

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:

Internet Security Scanner (ISS)
Strobe
Network Security Scanner (NSS)
identTCPscan
Jakal

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.

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.

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).

In the CIA case, a cracker seized control on September 18, 1996, replacing the welcome banner with one that read The Central Stupidity Agency. Accompanying this were links to a hacker group in Scandinavia. 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.

In the DoJ incident (Saturday, August 17, 1996), a photograph of Adolf Hitler was offered as the Attorney General of the United States.

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:

During a period spanning from July, 1995 to March 1996, a student in Argentina compromised key sites in the United States, including those maintained by the Armed Forces and NASA.

In August, 1996, a soldier at Fort Bragg reportedly compromised an "impenetrable" military computer system and widely distributed passwords he obtained.

In December, 1996, hackers seized control of a United States Air Force site, replacing the site's defense statistics with pornography. The Pentagon's networked site, DefenseLINK, was shut down for more than 24 hours as a result. 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.

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.

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.

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 (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.

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.

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.

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:

The target was a security specialist who had written special security tools not available to the general public.

The method employed in the break-in was extremely sophisticated and caused a stir in security circles.

The suspicion was, from the earliest phase of the case, that Mitnik (then a wanted man) was involved in the break-in.

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:

One must determine the trust relationships between machines on the target network.

One must determine which of those trust relationships can be exploited (that is, which of those machines is running an operating system susceptible to spoofing).

(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 w

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

by Anonymous