Introduction

	Sign In Sign-Up

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. People across the country surf the Net using networked operating systems, oblivious to dangers common to their platform. To be blunt, most of India is going online unarmed and unprepared.

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 are classified 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.

How a user could be unaware of such utilities? The answer is simple. Think of a word processor. Just how much a user knows about it? If the user routinely write macros in a word-processing environment, he is an advanced user. 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.

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. Perhaps users 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.

Unfortunately, keeping up with the times is difficult. The software industry is a dynamic environment, and users need time to get acquainted with the latest developments. 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 me 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. DOS(Disk Operating System) 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, a default password* is the most common. Most multi-user 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 a small network cannot operate with fluidity and efficiency if advanced access restrictions are enabled. If so, user must take that chance, perhaps implementing other security procedures to compensate. In essence, these issues are the basis of security theory: user must balance the risks against practical security measures, based on the sensitivity of your network data.

Important to Note 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).

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

Normally two types of system flaws exist. 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.

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