|
|
Hacking and cracking are activities that generate intense public interest. Stories of hacked servers and downed Internet providers appear regularly in national news. Consequently, publishers are in a race to deliver books on these subjects. To its credit, the publishing community has not failed in this resolve. Security books appear on shelves in ever-increasing numbers. However, the public remains wary. Consumers recognize driving commercialism when they see it, and are understandably suspicious of books such as this one. They need only browse the shelves of their local bookstore to accurately assess the situation.
Books about Internet security are common (firewall technology seems to dominate the subject list). In such books, the information is often sparse, confined to a narrow range of products. Authors typically include full-text reproductions of stale, dated documents that are readily available on the Net. This poses a problem, mainly because such texts are impractical. Experienced readers are already aware of these reference sources, and inexperienced ones are poorly served by them. Hence, consumers know that they might get little bang for their buck. Because of this trend, Internet security books have sold poorly at America's neighborhood bookstores.
Another reason that such books sell poorly is this: The public erroneously believes that to hack or crack, you must first be a genius or a UNIX guru. Neither is true, though admittedly, certain exploits require advanced knowledge of the target's operating system. However, these exploits can now be simplified through utilities that are available for a wide range of platforms. Despite the availability of such programs, however, the public remains mystified by hacking and cracking, and therefore, reticent to spend forty dollars for a hacking book.
So, at the outset, Sams.net embarked on a rather unusual journey in publishing this book. The Sams.net imprint occupies a place of authority within the field. Better than two thirds of all information professionals I know have purchased at least one Sams.net product. For that reason, this book represented to them a special situation.
Hacking, cracking, and Internet security are all explosive subjects. There is a sharp difference between publishing a primer about C++ and publishing a hacking guide. A book such as this one harbors certain dangers, including
If any of these dangers materialize, Sams.net will be subject to scrutiny or perhaps even censure. So, again, if all of this is true, why would Sams.net publish this book?
Sams.net published this book (and I agreed to write it) because there is a real need. I'd like to explain that need for a moment, because it is a matter of some dispute within the Internet community. Many people feel that this need is a manufactured one, a device dreamt up by software vendors specializing in security products. This charge--as the reader will soon learn--is unfounded.
Today, thousands of institutions, businesses, and individuals are going online. This phenomenon--which has been given a dozen different names--is most commonly referred to as the Internet explosion. That explosion has drastically altered the composition of the Internet. By composition of the Internet, I refer to the cyberography of the Net, or the demography of cyberspace. This quality is used to express the now diverse mixture of users (who have varying degrees of online expertise) and their operating systems.
A decade ago, most servers were maintained by personnel with at least basic knowledge of network security. That fact didn't prevent break-ins, of course, but they occurred rarely in proportion to the number of potential targets. Today, the Internet's population is dominated by those without strong security knowledge, many of whom establish direct links to the backbone. The number of viable targets is staggering.
Similarly, individual users are unaware that their personal computers are at risk of penetration. Folks across the country surf the Net using networked operating systems, oblivious to dangers common to their platform. To be blunt, much of America is going online unarmed and unprepared.
You might wonder even more why Sams would publish a book such as this. After all, isn't the dissemination of such information likely to cause (rather than prevent) computer break-ins?
In the short run, yes. Some readers will use this book for dark and unintended purposes. However, this activity will not weaken network security; it will strengthen it. To demonstrate why, I'd like to briefly examine the two most common reasons for security breaches:
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:
2. Name that folder and now the moment you've all been waiting for.
3. Right-click that folder and choose Rename.
4. Rename the folder we proudly present for your viewing pleasure.
5. Right-click the folder and choose Rename.
5. Rename the folder The Microsoft Windows 95 Product Team!.
6. Open that folder by double-clicking it.
The preceding steps will lead to the appearance of a multimedia presentation about the folks who coded Windows 95. (A word of caution: The presentation is quite long.)
Unfortunately, keeping up with the times is difficult. The software industry is a dynamic environment, and users are generally two years behind development. This lag in the assimilation of new technology only contributes to the security problem. When an operating-system- development team materially alters its product, a large class of users is suddenly left knowing less. Microsoft Windows 95 is a good example of this phenomenon. New support has been added for many different protocols: protocols with which the average Windows user might not be familiar. So, it is possible (and probable) that users might be unaware of obscure network utilities at work with their operating systems.
This is especially so with UNIX-based operating systems, but for a slightly different reason. UNIX is a large and inherently complex system. Comparing it to other operating systems can be instructive. DOS contains perhaps 30 commonly used commands. In contrast, a stock distribution of UNIX (without considering windowed systems) supports several hundred commands. Further, each command has one or more command-line options, increasing the complexity of each utility or program.
In any case, in the active state of insecurity in shipped software, utilities are enabled and this fact is unknown to the user. These utilities, while enabled, can foster security holes of varying magnitude. When a machine configured in this manner is connected to the Net, it is a hack waiting to happen.
Active state problems are easily remedied. The solution is to turn off (or properly configure) the offending utility or service. Typical examples of active state problems include
Of the examples listed, default passwords is the most common. Most multiuser operating systems on the market have at least one default password (or an account requiring no password at all).
The passive state 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
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:
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:
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.
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.
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).
I hope this chapter clearly articulates the reasons I wrote this book:
There is also another, one that is less general: I wanted to narrow the gap between the radical and conservative information now available about Internet security. It is significant that many valuable contributions to Internet security have come from the fringe (a sector seldom recognized for its work). To provide the Internet community with a book of value, these fringe elements had to be included.
The trouble is, if you examine security documents from the fringe, they are very grass roots and revolutionary. This style--which is uniquely American if nothing else--is often a bit much for square security folks. Likewise, serious security documents can be stuffy, academic, and, to be frank, boring. I wanted to deliver a book of equal value to readers aiming for either camp. I think that I have.
© Copyright, Macmillan Computer Publishing. All rights reserved.