Red Tacton is a new Human Area Networking technology that uses the surface of the human body as a safe, high-speed network transmission path. 

   RedTacton uses the minute electric field emitted on the surface of the human body. Technically, it is completely distinct from wireless and infrared. A transmission path is formed at the moment a part of the human body comes in contact with a Red Tacton transceiver.

Physically separating ends the contact and thus ends communication Using Red Tacton, communication starts when terminals carried by the user or embedded in devices are linked in various combinations according to the user’s Communication is possible using any body surfaces, such as the hands, fingers, arms, feet, face, legs or torso. Red Tacton works natural, physical movements.

Working: -

           Using a new super-sensitive photonic electric field sensor, Red Tacton can achieve duplex communication over the human body at a maximum seed of   10 mbps.

The Red Tacton transmitter induces a weak electric field on the surface of the body. The Red Tacton receiver senses changes in the weak electric field on the surface of the body caused by the transmitter .Red tacton relies upon the principle that the optical properties of an electro-optic crystal can vary according to the changes of a weak electric field. Red Tacton detects changes in the optical properties of an electro-optic crystal using a laser and converts the result to an electrical signal in an optical receiver circuit. The transmitter sends data by inducing fluctuations in the minute electric field on the surface of the human body. Data is received using a photonic electric field sensor that combines an electro-optic crystal and a laser light to detect fluctuations in the minute electric field.

                           The naturally occurring electric field induced on the surface of the human body dissipates into the earth. Therefore, this electric field is exceptionally faint and unstable. The photonic electric field sensor developed by NTT enables weak electric fields to be measured by detecting changes in the optical properties of an electro-optic crystal with a laser beam.

Human area network: -

Welcome to yet another new series: Moving Beyond SSH. During this series we will be taking an Xdev dedicated server from nothing but SSH to a fully functional web server. Although the title of this post is contradictory, before we go beyond SSH, we must first login to SSH. That’s what we’ll be covering today.

SSH (which stands for Secure Shell) is a protocol for remotely controlling offsite devices over the Internet. Unlike its predecessor (Telnet), SSH is secure. SSH can also be used to securely transfer files to a server via the SFTP or SCP protocols.

You will be installing all the software needed for a web server onto your Xdev by issuing commands through SSH. But before we get to that, you will first need to login through SSH into your server. For this you will need your server’s IP address and password (all provided in the email sent to you when you order an Xdev) and SSH software.

Windows

If you’re running Windows (any version), you will need to download PuTTY (choose “putty.exe” on that page). There is no installation process, just run the downloaded file. Once you have run the downloaded file, find the box that is labelled Host Name (or IP Address) and enter your server’s IP address in that box. The default port 22 is fine and ensure the radio box beside “SSH” is selected. Click on the “Open” button. (see section after the Mac/Linux instructions for the rest of the directions)

Mac OS X and Linux

If you’re running Mac OS X or any distribution of Linux or Unix, you should already have the required software installed. Open up the “Terminal” application (Mac: Under Applications > Utilities. Linux/Unix: Varies, search the web if you can’t find it). Type in the following into the resulting window (replacing IP_ADDRESS with the IP address of your server):

ssh -l root IP_ADDRESS

Then press enter/return on your keyboard.

You’re Almost Logged In

After you have followed the above instructions for your Operating System, a window will appear. This will be your SSH window. The window will say something along the lines of “Do you want to accept this server’s certificate?”. Type in “yes” and hit enter/return on your keyboard. In Windows, you will now have to enter your username, which is “root”, type that in, then hit enter. In Windows, Mac and Linux, you will now have to enter your server’s password, then hit the enter/return key (it won’t appear like you’re typing anything, don’t worry, you are).

Congratulations, you have just logged into your server via SSH!

The First Thing

After logging in, the first thing you should do is to change your password. In your SSH window, type in the command:

passwd

Then, hit enter/return. After that, type in your current password, hit enter/return, type in your new password, hit enter/return and then confirm your new password (and hit enter/return).

IMPORTANT: You should use a very strong password, as if someone were to crack it, they would have full access to your server. It is also important to write down your password in a safe place, because if you forget it, it will be impossible to access your server (for both you and BlueFur staff).

Concluding

To log out of your server, type:

logout

Then press enter/return.

This week we’ll actually be moving onto installing some software to run our server. This series will go over setting up a basic LAMP stack, which includes Linux, Apache, MySQL and PHP. Today we’ll be going over installing Apache. We will be compiling this software from source instead of using an automated installer such as yum. We’re doing it this way because compiling from source gives you more customizability and it is a great learning experience for managing your server.

Okay, start out be logging into your server and changing your directory to /. Now, we need to start out be downloading Apache to our web server. First head on over to Apache’s download page and copy the URI for the .tar.gz UNIX Source download under the latest version of Apache 2.2. Now, in your SSH client:

wget URL_TO_APACHE_DOWNLOAD

Replace URL_TO_APACHE_DOWNLOAD with the URL you got on the download page. Now, we need to extract the contents of the archive that gets downloaded:

gzip -d httpd-NN.tar.gz
tar xvf httpd-NN.tar

Replace NN with the version of the download (eg. 2.2.11). Now, change your working directory to the exatracted directory (again replacing NN with the version of the download):

cd httpd-NN

Now, we need to configure Apache to install with the modules we want installed. Here’s what I would start out with:

./configure --enable-so --enable-rewrite --enable-deflate

Which will allow Apache to work with modules (instead of having everything be complied into its core), install mod_rewrite and install mod_deflate. The full list of available configure options are available here. You can append more options to the line above. If you want to be able to enable and disable any of those options in Apache’s configuration file, you can append =shared to the end of the option (with no space before). This command may take a few minutes to execute.

Next, we get the configuration options prepared to be installed:

make

This may also take a couple of minutes. Now, we can actually install Apache, which we do by running this command:

make install

Assuming you haven’t encountered any errors, Apache should now be installed. We can start it by running this command:

/usr/local/apache2/bin/apachectl -k start

You should now be able to head over to the IP address of your server and see your server… serving! Alright, now since we’ll be controlling Apache quite a bit when managing our server, let’s make its command a little shorter.

cd /bin
ln -s /usr/local/apache2/bin/apachectl apachectl

Which will allow up to control Apache in this shortened form:

apachectl -k start

This week we’ll be going over how to install Webmin, a web-interface for system administration. We’ll be using it to configure our DNS, as it is much easier than creating the configuration files manually.

Start out by downloading the latest version of the .tar.gz of Webmin, over on the downloads page. Then decompress and unpack the file.

wget http://prdownloads.sourceforge.net/webadmin/webmin-1.450.tar.gz
gunzip webmin-1.450.tar.gz
tar xf webmin-1.450.tar

Replace 1.450 with the Webmin version you downloaded. We can now change our working directory to the directory we just extracted:

cd webmin-1.450

Now, we can run the Webmin setup script. It is a shell script, so it will prompt us for some configuration options in our SSH window.

./setup.sh /usr/local/webmin

It will ask you a couple of questions, most of which you can just hit “enter” to, to use the default. You’ll need to choose a username and password for accessing the Webmin panel. You can answer “y” when it asks if you want Webmin to load of boot.

Once you have finished installing Webmin, you can access the Webmin panel at http://SERVER_IP:10000/ in your browser. Login using the username and password you choose during the Webmin setup.

- – - – - – - – - – - – - – - – - – -

• The script sshprep.sh:

#!/bin/bash
cat ~/.ssh/id_dsa.pub | ssh root@${1} "(mkdir .ssh 2>/dev/null; chmod 700 .ssh && cat - >> .ssh/authorized_keys ) && chmod 600 .ssh/authorized_keys"

- – - – - – - – - – - – - – - – - – -

• It simply copies your public key on remote host (into ~/.ssh/authorized_keys) and makes all arbitrary “paperwork” for us. Example usage:

bash# sshprep.sh xtest02.domain.com
root@xtest02.domain.com's password:

• After this, you’re no longer obligated to type any password there:

bash# ssh xtest02.domain.com
You have new mail.
Last login: Wed Oct 22 01:41:21 2009
bazh#

Secure Sockets Layer (SSL) is the most widely used technology for providing a secure communication between the web client and the web server.Most of us are familiar with many sites such as Gmail, Yahoo etc. using httpsprotocol in their login pages.When we see this, we may wonder what’s the difference between http and https.In simple words HTTP protocol is used for standard communication between the Web server and the client. HTTPS is used for a SECURE communication.

What exactly is Secure Communication ?

Suppose there exists two communication parties A (client) and B (server).

Working of HTTP

When A sends a message to B, the message is sent as a plain text in an unencrypted manner.This is acceptable in normal situations where the messages exchanged are not confidential.But imagine a situation where A sends a PASSWORD to B.In this case, the password is also sent as a plain text.This has a serious security problem because, if an intruder (hacker) can gain unauthorised access to the ongoing communication between A and B , he can see the PASSWORDS since they remain unencrypted.This scenario is illustrated using the following figure

Now lets see the working of HTTPS

When A sends a PASSWORD (say “mypass“) to B, the message is sent in an encrypted format.The encrypted message is decrypted on B’s side.So even if the Hacker gains an unauthorised access to the ongoing communication between A and Bhe gets only the encrypted password (”xz54p6kd“) and not the original password.This is shown below

How is HTTPS implemented ?

HTTPS is implemented using Secure Sockets Layer (SSL).A website can implement HTTPS by purchasing an SSL Certificate.Secure Sockets Layer (SSL) technology protects a Web site and makes it easy for the Web site visitors to trust it. It has the following uses

1. An SSL Certificate enables encryption of sensitive information during online transactions.
2. Each SSL Certificate contains unique, authenticated information about the certificate owner.
3. A Certificate Authority verifies the identity of the certificate owner when it is issued.

How Encryption Works ?

Each SSL Certificate consists of a Public key and a Private key. The public key is used to encrypt the information and the private key is used to decrypt it.When your browser connects to a secure domain, the server sends a Public key to the browser to perform the encryption.The public key is made available to every one but the private key(used for decryption) is kept secret.So during a secure communication, the browser encrypts the message using the public key and sends it to the server.The message is decrypted on the server side using the Private key(Secret key).

How to identify a Secure Connection ?

In Internet Explorer, you will see a lock icon  in the Security Status bar. The Security Status bar is located on the right side of the Address bar.You can click the lock to view the identity of the website.

In high-security browsers, the authenticated organization name is prominently displayed and the address bar turns GREEN when an Extended Validation SSL Certificate is detected. If the information does not match or the certificate has expired, the browser displays an error message or warning and the status bar may turn RED.

So the bottom line is, whenever you perform an online transaction such as Credit card payment, Bank login or Email login always ensure that you have a secure communication.A secure communication is a must in these situations.Otherwise there are chances of Phishing using a Fake login Page.

Before I examine different types of holes, I’d like to define the term hole. A hole is any feature of hardware or software that allows unauthorized users to gain access or increase their level of access without authorization. I realize this is a broad definition, but it is accurate. A hole could be virtually anything. For example, many peculiarities of hardware or software commonly known to all users qualify as holes. One such peculiarity (perhaps the most well known)is that CMOS passwords on IBM compatibles are lost when the CMOS battery is shorted, disabled, or removed. Even the ability to boot into single-user mode on a workstation could be classified as a hole. This is so because it will allow a malicious user to begin entering interactive command mode, perhaps seizing control of the machine.

So a hole is nothing more than some form of vulnerability. Every platform has holes, whether in hardware or software. In short, nothing is absolutely safe.

 

---

NOTE: Only two computer-related items have ever been deemed completely hole free (at least by national security standards). One is the Gemini processor, manufactured by Gemini Computers. It has been evaluated as in the A1 class on the NSA’s Evaluated Products List. It is accompanied by only one other product in that class: the Boeing MLS LAN (Version 2.1). Check out both products at http://www.radium.ncsc.mil/tpep/epl/.

---

You might draw the conclusion that no computer system is safe and that the entire Net is nothing but one big hole. That is incorrect. Under the circumstances, you should be wondering why there aren’t more holes. Consider that the end-user never takes much time to ponder what has gone into making his system work. Computer systems (taken holistically) are absolute wonders of manufacturing. Thousands of people are involved in getting a computer (regardless of platform) to a retail location. Programmers all over the world are working on applications for any given platform at any given time. Everyone from the person who codes your calendar program to the dozen or so folks who design your firewall are all working independently. Under these circumstances, holes should be everywhere; but they aren’t. In fact, excluding holes that arise from poor system administration, security is pretty good. The problem is that crackers are also good.

The Vulnerability Scale

There are different types of holes, including

• Holes that allow denial of service
• Holes that allow local users with limited privileges to increase those privileges without authorization
• Holes that allow outside parties (on remote hosts) unauthorized access to the network

These types of holes and attacks can be rated according to the danger they pose to the victim host. Some represent significant dangers that can destroy the target; others are less serious, qualifying only as nuisances. Figure 15.1 shows a sort of “Internet Richter scale” by which to measure the dangers of different types of holes.

FIGURE 15.1.
The holes index: dangers that holes can pose.

Holes That Allow Denial of Service

Holes that allow denial of service are in category C, and are of low priority. These attacks are almost always operating-system based. That is, these holes exist within the networking portions of the operating system itself. When such holes exist, they must generally be corrected by the authors of the software or by patches from the vendor.

For large networks or sites, a denial-of-service attack is of only limited significance. It amounts to a nuisance and no more. Smaller sites, however, may suffer in a denial-of-service attack. This is especially so if the site maintains only a single machine (and therefore, a single mail or news server). Chapters 3, “Hackers and Crackers,” and 8, “Internet Warfare,” provide examples of denial-of-service attacks. These occur most often in the form of attacks like syn_flooding. An excellent definition of denial-of-service attacks is given in a popular paper called “Protecting Against TCP SYN Denial of Service Attacks”:

Denial of Service attacks are a class of attack in which an individual or individuals exploit aspects of the Internet Protocol suite to deny other users of legitimate access to systems and information. The TCP SYN attack is one in which connection requests are sent to a server in high volume, causing it to become overwhelmed with requests. The result is a slow or unreachable server, and upset customers.

 

---

Cross Reference: Check out “Protecting against TCP SYN Denial of Service Attacks” online at http://www.proteon.com/docs/security/tcp_syn.htm.

---

The syn_flooder attack is instigated by creating a high number of half-open connections. Because each connection opened must be processed to its ultimate conclusion (in this case, a time-out), the system is temporarily bogged down. This appears to be a problem inherent in the design of the TCP/IP suite, and something that is not easily remedied. As a CERT advisory on this subject notes:

There is, as yet, no generally accepted solution to this problem with the current IP protocol technology. However, proper router configuration can reduce the likelihood that your site will be the source of one of these attacks.

This hole, then, exists within the heart of the networking services of the UNIX operating system (or nearly any operating system running full-fledged TCP/IP over the Internet). Thus, although efforts are underway for fixes, I would not classify this as a high priority. This is because in almost all cases, denial-of-service attacks represent no risk of penetration. That is, crackers cannot harm data or gain unauthorized levels of privilege through these means; they can just make themselves nuisances.

 

---

Cross Reference: Good papers available on the Net can give you a clearer picture of what such a denial-of-service attack entails. One is “Security Problems in the TCP/IP Protocol Suite” by Steve Bellovin, which appeared in Computer Communication Review in April 1989. Find it at ftp://research.att.com/dist/internet_security/ipext.ps.Z.

---

Although UNIX is notorious for being vulnerable to denial-of-service attacks, other platforms are not immune. For example, as I will discuss in Chapter 16, “Microsoft,” it is possible to bring certain NT distributions to a halt simply by Telnetting to a particular port and issuing a few simple characters. This forces the CPU to race to 100 percent utilization, thus incapacitating the machine altogether.

There are other forms of denial-of-service attacks. Certain denial-of-service attacks can be implemented against the individual user as opposed to a network of users. These types of attacks do not really involve any bug or hole per se; rather, these attacks take advantage of the basic design of the WWW.

For example, suppose I harbored ill feelings toward users of Netscape Navigator. (Don’t laugh. There are such people. If you ever land on their pages, you will know it.) Using either Java or JavaScript, I could effectively undertake the following actions:

1. Configure an inline or a compiled program to execute on load, identifying the type of browser used by the user.

2. If the browser is Netscape Navigator, the program could spawn multiple windows, each requesting connections to different servers, all of which start Java applets on load.

In fewer than 40 seconds, the target machine would come to a grinding halt. (Oh, those with more than 64MB of RAM might survive long enough for the user to shut down the processes. Nonetheless, the average user would be forced to reboot.) This would cause what we technically classify as a denial-of-service attack.

 

---

Cross Reference: One good reference about denial-of-service attacks is “Hostile Applets on the Horizon” by Mark D. LaDue. That document is available at http://www.math.gatech.edu/~mladue/HostileArticle.html.

---

These types of denial-of-service attacks are generally lumped into the category of malicious code. However, they do constitute a type of DoS attack, so I thought they were worth mentioning here.

 

---

NOTE: Not every denial-of-service attack need be launched over the Internet. There are many types of denial-of-service attacks that occur at a local level, perhaps not even in a network environment. A good example is a well known file locking denial-of-service attack that works on the Microsoft Windows NT platform. Sample code for this attack has been widely distributed on security mailing lists. The code (when compiled) results in a program that will take any file or program as a command-line argument. This command-line argument is the target file that you wish to lock. For example, it might be WINWORD.EXE or even a DLL file. The file will remain completely locked (inaccessible to any user) for the length of time specified by the cracker. During that period, no one–not even the administrator–can use the file. If the cracker sets the time period to indefinite (or rather, the equivalent thereof), the only way to subvert the lock is to completely kill that user’s session. Such locking programs also work over shared out drives.

---

One particularly irritating denial-of-service attack (which is being incorporated into many Windows 95 cracking programs) is the dreaded CHARGEN attack. CHARGEN is a service that runs on port 19. It is a character generator (hence the name) used primarily in debugging. Many administrators use this service to determine whether packets are being inexplicably dropped or where these packets disappear before the completion of a given TCP/IP transaction. In any event, by initiating multiple requests to port 19, an attacker can cause a denial-of-service attack, hanging the machine.

Holes That Allow Local Users Unauthorized Access

Still higher in the hole hierarchy (class B) are those holes that allow local users to gain increased and unauthorized access. These types of holes are typically found within applications on this or that platform.

 

---

NOTE: In Figure 15.1, I point to an unshadowed passwd file as a possible class B problem, and in truth, it is. Nonetheless, this is not an application problem. Many such nonapplication problems exist, but these differ from hard-line class B holes. Here, hard-line class B holes are those that occur within the actual code of a particular application. The following example will help illustrate the difference.

---

A local user is someone who has an account on the target machine or network. A typical example of a local user is someone with shell access to his ISP’s box. If he has an e-mail address on a box and that account also allows shell access, that “local” user could be thousands of miles away. In this context, local refers to the user’s account privileges, not his geographical location.

sendmail

A fine example of a hole that allows local users increased and unauthorized access is a well-known sendmail problem. sendmail is perhaps the world’s most popular method of transmitting electronic mail. It is the heart of the Internet’s e-mail system. Typically, this program is initiated as a daemon at boot time and remains active as long as the machine is active. In its active state, sendmail listens (on port 25) for deliveries or other requests from the void.

When sendmail is started, it normally queries to determine the identity of the user because only root is authorized to perform the startup and maintenance of the sendmail program. Other users with equivalent privileges may do so, but that is the extent of it. However, according to the CERT advisory titled “Sendmail Daemon Mode Vulnerability”:

Unfortunately, due to a coding error, sendmail can be invoked in daemon mode in a way that bypasses the built-in check. When the check is bypassed, any local user is able to start sendmail in daemon mode. In addition, as of version 8.7, sendmail will restart itself when it receives a SIGHUP signal. It does this restarting operation by re-executing itself using the exec(2) system call. Re-executing is done as the root user. By manipulating the sendmail environment, the user can then have sendmail execute an arbitrary program with root privileges.

Thus, a local user can gain a form of root access. These holes are quite common. One surfaces every month or so. sendmail is actually renowned for such holes, but has no monopoly on the phenomenon (nor is the problem indigenous to UNIX).

 

---

Cross Reference: For information about some commonly known sendmail holes, check out http://info.pitt.edu/HOME/Security/pitt-advisories/95-05-sendmail-vulnerabilities.html and http://www.crossroads.fi/~tkantola/hack/unix/sendmail.txt.

---

Older versions of sendmail contain a weakness in the buffer (you will learn a little bit about the buffer/stack scenario in the following paragraphs). As such, one used to be able to crack the system by invoking the debug option in sendmail and overflowing the buffer. This was done with the -d option. A similar problem surfaced regarding sendmail’s communication with the syslog daemon (another buffer overflow problem).

These types of holes represent a serious threat for one reason: If a local user successfully manages to exploit such a hole, the system administrator may never discover it. Also, leveraged access is far more dangerous in the hands of a local user than an outsider. This is because a local user can employ basic system utilities to learn more about the local network. Such utilities reveal far more than any scanner can from the void. Therefore, a local user with even fleeting increased access can exploit that access to a much greater degree. (For that matter, the local user is behind your firewall, meaning he is free to conduct his affairs without further complications.)

 

---

NOTE: Holes in programs like sendmail are especially significant because these programs are available to all users on the network. All users must have at least basic privileges to use the sendmail program. If they did not, they would have no way to send mail. Therefore, any bug or hole within sendmail is very dangerous.

---

The only real comfort with respect to these types of holes is that there is a much greater chance of identifying the offender, particularly if he is inexperienced. If the system administrator is running strong logging utilities, the offender will need a fair amount of expertise to escape detection.

Other Class B Holes

Most class B holes arise from some defect within an application. There are some fairly common programming errors that lead to such holes. One such error concerns the character buffer in programs written in C (hence, the dreaded buffer overflow). Buffer overflow is defined on the Jargon File as

What happens when you try to stuff more data into a buffer (holding area) than it can handle. This may be due to a mismatch in the processing rates of the producing and consuming processes (see overrun and firehose syndrome), or because the buffer is simply too small to hold all the data that must accumulate before a piece of it can be processed.

 

---

Cross Reference: The Jargon File is a wide collection of definitions, which cover strange and colorful terms used in computer lingo or slang (technospeak). All new Internet users should peruse the Jargon File because it reveals the meanings of many acronyms and other slang terms referred to in Usenet newsgroups and general discussion areas on the Internet. A good HTML version of the Jargon File is located at http://nmsmn.com/~cservin/jargon/alpha.html.

---

Rather than exhaustively treat the subject of buffer overflows, I will briefly describe problem here. The purpose of this explanation is to familiarize you with a rather ingenious technique of gaining unauthorized access; I hope to do so without an endless examination of the C language (C is covered more extensively in Chapter 30, “Language, Extensions, and Security”).

Programs written in C often use a buffer. Flatly stated, a buffer is an abstraction, an area of memory in which some type of text or data will be stored. Programmers make use of such a buffer to provide pre-assigned space for a particular block or blocks of data. For example, if one expects the user to input his first name, the programmer must decide how many characters that first name buffer will require (how many letters should be allowed in that field, or the number of keystrokes a user can input in a given field). This is called the size of the character buffer. Thus, if the programmer writes:

char first_name[20];

he is allowing the user 20 characters for a first name. But suppose the user’s first name has 35 characters. What happens to the last 15 characters? They overflow the character buffer. When this overflow occurs, the last 15 characters are put somewhere in memory, at another address (an address the programmer did not intend for those characters to go to). Crackers, by manipulating where those extra characters end up, can cause arbitrary commands to be executed by the operating system. Most often, this technique is used by local users to gain access to a root shell. Unfortunately, many common utilities have been found to be susceptible to buffer overflow attacks.

Programmers can eliminate this problem through careful programming techniques. I am not suggesting here that programmers should provide error checking for each and every character buffer written; this is probably unrealistic and may be waste of time. For although these defects can certainly place your network at risk, the cracker requires a high level of skill to implement a buffer overflow attack. Although the technique is often discussed in cracking circles, few actually have the programming knowledge to do it.

 

---

NOTE: Failure to include checks for buffer overflows have caused some of the very problems I have already discussed, such as sendmail holes.

---

The buffer overflow issue is nothing new; it has been with us at least since the days of the Worm. Eugene Spafford, as I have already noted, was one of the first individuals to conduct a purposeful analysis of the Worm. He did so in the now-famous paper, “The Internet Worm: An Analysis.” Spafford’s paper is undoubtedly the best source of information about the Worm.

In page 4 of that document, Spafford observes that the Morris Worm exploited a vulnerability in the fingerd daemon (the daemon that listens for and satisfies finger requests directed to port 79). The fingerd program utilized a common C language function known as gets(), which performs the simple task of reading the next line of input. gets() lacked any function to check for bounds, or incoming input that could potentially exceed the buffer. Thus, Morris was able to overflow that buffer and reportedly push other code onto the stack; this code provided the Worm with needed system access. Spafford observes that this vulnerability was well known in programming communities, even then. He further explains that functions that fail to check for potential overflows should not be used. Yet even today, programs are written with the same, basic flaws that allowed the Worm to travel so far, so fast.

Holes That Allow Remote Users Unauthorized Access (Class A)

Class A holes are the most threatening of all and not surprisingly, most of them stem from either poor system administration or misconfiguration. Vendors rarely overlook those holes that allow remote users unauthorized access. At this late stage of the game, even vendors that were previously not security minded have a general grasp of the terrain.

The typical example of a misconfiguration (or configuration failure) is any sample script that remains on the drive, even though the distribution docs advise that it be removed. One such hole has been rehashed innumerable times on the Net. It involves those files included within Web server distributions.

Most Web server software contains fairly sparse documentation. A few files may exist, true, and some may tout themselves as tutorials. Nonetheless, as a general rule, distributions come with the following elements:

• Installation instructions
• The binaries
• In some rare cases, the source
• Sample configuration files with comments interspersed within them, usually commented out within the code
• Sample CGI scripts

To the credit of those distributing such software, most configuration files offer a warning regarding sample scripts. Nonetheless, for reasons of which I am uncertain, not everyone heeds those warnings (at least one government site recently cracked had this problem). In any case, these scripts can sometimes provide an intruder from the void with access ranging from limited to root.

Probably the most talked-about hole of this kind is the vulnerability in a file called test-cgi, distributed with early versions of the Apache Web Server distribution. This file contained a flaw that allowed intruders from the void to read files within the CGI directory. If your test-cgi file contained the following line, you were probably vulnerable:

echo QUERY_STRING = $QUERY_STRING

As noted in the article titled “Test-CGI Vulnerability in Certain Setups”:

All of these lines should have the variables enclosed in loose quotes (“). Without these quotes certain special characters (specifically `*’) get expanded where they shouldn’t. Thus submitting a query of `*’ will return the contents of the current directory (probably where all of the cgi files are).

 

---

Cross Reference: Find “Test-CGI Vulnerability in Certain Setups” online at http://www.sec.de/sec/bug.testcgi.

---

Interestingly, no sooner than this advisory (and others like it) circulated, it was found that:

Test-CGI in the Apache 1.1.1 distribution already has the required:

echo QUERY_STRING = "$QUERY_STRING"

However, it does not have the necessary quotes around the

"$CONTENT_TYPE"

string. Therefore it’s still vulnerable in its default configuration.

 

---

Cross Reference: The previous paragraph is excerpted from an article titled “Vulnerability in Test-CGI” by Joe Zbiciak. It can be found online at http://geek-girl.com/bugtraq/.

---

Problems like this are common. For example, one HTTP server on the Novell platform includes a sample script called convert.bas. The script, written in BASIC, allows remote users to read any file on the system.

This problem sometimes involves more than just a sample script; sometimes it involves the way scripts are interpreted. For example, version 1.0 of Microsoft’s Internet Information Server (IIS) contains a hole that allows any remote user to execute arbitrary commands. The problem is that the IIS HTTP associates all files with a *.bat or *.cmd extension to the program cmd.exe. As explained by Julian Assange (author of Strobe), the problem is not restricted to IIS:

The First bug allows a user to access any file on the same partition where your wwwroot directory exists (assuming that IIS_user has permission to read this file). It also allows execution of any executable file on the same partition where your scripts directory exists (assuming that IIS_user has permission to execute this file). If cmd.exe file can be executed then it also allows you to execute any command and read any file on any partition (assuming that IIS_user has permission to read or execute this file)…Unfortunately Netscape Communication and Netscape Commerce servers have similar bugs. Similar things can be done with Netscape Server if it uses BAT or CMD files as CGI scripts.

Naturally, these holes pose a significant danger to the system from outside sources. In many cases, if the system administrator is running only minimal logs, these attacks may go unrecorded. This makes it more difficult to apprehend the perpetrators.

 

---

NOTE: To be fair, most UNIX implementations of HTTPD do provide for recording of the requesting IP address. However, even given this index to go by, identifying the actual perpetrator can be difficult. For example, if the attacker is coming from AOL, the call will come from one or more of AOL’s proxy machines in Reston, Virginia. There could be hundreds of potential suspects. Using the ACCESS.LOG file to track a cracker is a poor substitute for more comprehensive logging and is only of real value when the attacker is coming from a small local ISP.

---

You can readily see, then, why programs like scanners have become such an important part of the security scheme. Scanners serve the vital purpose of checking for these holes. The problem is, of course, that for a scanner to include the capability to scan for a particular vulnerability, that vulnerability must already be well known. Thus, although security programmers include such holes as scan options in their programs, they are often several months behind the cracking community. (Also, certain holes–such as the syn_flooding hole that allows denial-of-service attacks–are not easily remedied. Such holes are imperfections that system administrators must learn to live with for the moment.)

What makes the situation more difficult is that holes on platforms other than UNIX take more time to surface. Many NT system administrators do not run heavy logs. To report a hole, they must first have some evidence that the hole exists. Moreover, newer system administrators (of which a higher percentage exists amongst the IBM-compatible set) are not well prepared for documenting and reporting security incidents. This means that time passes before such holes are presented, tested, re-created in a test environment, and ultimately, implemented into scanners.

 

---

NOTE: Microsoft users cannot count on Microsoft to instantly enlighten users as to potential problems. In my opinion, Microsoft’s record of publicizing holes has been very poor. It seems to do so only after so many people know about the hole that there is no other choice but to acknowledge it. While a hole is still obscure, Microsoft personnel adamantly deny the existence of the flaw. That situation is only now changing because the hacking (not cracking) community has called their bluff and has initiated the process of exposing all holes inherent within the Microsoft platform.

---

There is also the question of quality. Five years ago, software for the Internet was coded primarily by the academic communities. Such software had bugs, true, but the quality control worked quite differently from today’s commercial schemes. In those days (they seem so distant now!), a product was coded by and released from some CS lab. Several hundred (or even several thousand) people would download the product and play with it. Bug reports would flow in, problems would be addressed, and ultimately, a slow but progressive process of refinement would ensue.

In the current commercially charged climate of the Internet, applications of every type are popping up each day. Many of them are not subjected to a serious analysis for security flaws within the code (no matter how fervently their proponents urge otherwise). In fact, it is common to see the same programming errors that spawned the Morris Worm.

To demonstrate this point, I will refer to the buffer overflow problem. As reported in a 1995 advisory on a vulnerability in NCSA HTTPD (one of the world’s most popular Web server packages):

A vulnerability was recently (2/17/95) discovered in the NCSA httpd Release 1.3. A program which will break into an HP system running the precompiled httpd has been published, along with step by step instructions. The program overflows a buffer into program space which then gets executed.

 

---

Cross Reference: The previous paragraph is excerpted by a paper by Elizabeth Frank, and can be found online at http://ernie.sfsu.edu/patch_desc.html.

---

According to the CERT advisory (“NCSA HTTP Daemon for UNIX Vulnerability”) that followed:

Remote users may gain unauthorized access to the account (uid) under which the httpd process is running.

As explained in Chapter 9, “Scanners,” many individuals unwittingly run HTTPD as root. Thus, this vulnerability would provide remote users with root access on improperly configured Web servers.

Other Holes

In the preceding paragraphs, I named only a few holes. This might give you the erroneous impression that only a handful of programs have ever had such holes. This is untrue. Holes have been found in nearly every type of remote access software at one stage or another. The list is very long indeed. Here is a list of some programs that have been found (over the years) to have serious class A holes:

• FTP
• Gopher
• Telnet
• sendmail
• NFS
• ARP
• Portmap
• finger

In addition to these programs having class A holes, all of them have had class B holes as well. Moreover, in the class B category, dozens of other programs that I have not mentioned have had holes. Finally, a good number of programs have class C holes as well. I will be addressing many of these in upcoming chapters.

The Impact of Holes on Internet Security

Now that you have read a bit about some common holes, the next step is to know what impact they can have on Internet security. First, know this: Any flaw that a cracker can exploit will probably lead to other flaws. That is, each flaw (large or small) is a link in the network chain. By weakening one link, crackers hope to loosen all the other links. A true cracker may use several techniques in concert before achieving even a modest goal. If that modest goal can be achieved, other goals can also be achieved.

For example, perhaps a cracker is working on a network on which he does not have an account. In that instance, he must first acquire some form of access to the system (access above and beyond whatever diagnostic information he may have culled from SATAN, ISS, or other scanners). His first target, then, might be a user on that network. If he can compromise a user’s account, he can at least gain shell access. From that point on, other measures may be taken.

 

---

NOTE: I recently reviewed logs on a case where the cracker had gained control of a local user’s account. Unfortunately for the cracker, he did not pick his target well. The unwary user was a complete newbie and had never, ever used her shell account. LAST logs (and other auditing materials) revealed this immediately. So what we had was a dial-up customer who had never used her shell account (or even built a Web page) suddenly compiling programs using a C compiler from a shell account. Hmm. Next time, that cracker will be more choosy about whose account he commandeers.

---

Is This Hole Problem As Bad As They Say?

Yes and no. Holes are reported to a variety of mailing lists each day. Nonetheless, those holes vary in severity. Many are in the class C category and not particularly important. As an interesting experiment, I decided to categorize (by operating-system type) all holes reported over a two-month period.

 

---

NOTE: In my experiment, I excluded all non-UNIX operating systems (I treat non-UNIX operating systems later in this chapter). I did this to be fair, for by sampling a bug mailing list that concentrates primarily on UNIX machines, I would give an erroneously bad image of UNIX and an erroneously good image of non-UNIX systems. This is so because UNIX mailing lists only occasionally receive security advisories on non-UNIX systems. (Although there is now a cross-over because other systems are more commonly being used as server-based platforms for the WWW, that cross-over amounts to a trickle).

---

Instead of indiscriminately picking instances of a particular operating system’s name and adding this to the tables (for example, grabbing every posting that referred to the syslog hole), I carefully sifted through each posting. I chose only those postings that reported the first instance of a hole. All trailing messages that discussed that hole were excluded. In this way, only new holes were added to my data. Furthermore, I pulled only the first 50 on each operating system. With one minor exception that I explain later, I had no reason to assume that the percentage would be greatly influenced by pulling 100 or 1,000.

I must advise you of one final point. Figure 15.2 shows an astonishing number of holes in HP-UX (Hewlett Packard’s OS). This prevalence of HP-UX holes is largely due to a group called “Scriptors of Doom.” These individuals have concentrated their efforts on finding holes indigenous to HP-UX. They have promised “one hole a week.” Because of their activity, HP-UX appears to have security problems that are more serious than other operating systems of a similar ilk. This is not really the case. That settled, please examine Figure 15.2.

Note that Sun (Solaris), AIX, and FreeBSD were running neck and neck, and that IRIX had just slightly fewer holes than Linux. But which of these holes were serious security risks? Which of these–per platform–were class B or class A vulnerabilities? To determine this, I reexamined the data from Figure 15.2 and excluded all vulnerabilities that could not result in local or remote users gaining root access. Table 15.1 lists the results.

FIGURE 15.2.
Survey of reported operating system holes in October-December 1996.

Table 15.1. Operating system holes that allowed root access.

Still, this information could be misleading, so I analyzed the data further. All of the listed operating systems were vulnerable to at least one bug present in their counterparts. That is, at least one bug was common to all operating systems sampled. After excluding these holes, the average was 2.5 holes per platform. AIX fell completely out of the running at that stage, having a total value of 0. Does this mean that AIX is the safest platform? No. It simply means that this two-month period spawned few advisories relevant to AIX.

This brings me to an important point. You may often see, particularly on Usenet, individuals arguing over whether Solaris is tighter than AIX or whether Linux is tighter than FreeBSD and so forth. These arguments are exercises in futility. As it happens, all operating systems have their holes. Long-term examination of reporting lists reveals that advisories go in cycles. Were I to sample another period in time, AIX might be the predominate victim. There is no mysterious reason for this; it breaks down to the nature of the industry. When a hole is discovered in sendmail, for example, it is not immediately clear as to which platforms are affected. Determining this takes time. When the hole is confirmed, a detailed description is posted to a list, and chances are that more than half of all machines running sendmail are affected. But when holes are discovered in proprietary software, any number of things can happen. This might result in a one-month run of advisories on a single platform.

 

---

NOTE: This sometimes happens because proprietary software may have multiple file dependencies that are inherent to the distribution, or there may be multiple modules created by the same programming team. Therefore, these executables, libraries, or other files may share the same basic flaws. Thus, there may be a buffer overflow problem in one of the executable programs in the package, and additionally, one of the library implementations is bad. (Or even, systems calls are poorly implemented, allowing commands to be pushed onto the stack.) If a proprietary package is large, problems could keep surfacing for a week or more (maybe even a month). In these cases, the vendor responsible looks very bad; its product is a topic of furious discussion on security lists for an extended period.

---

Holes on Other Platforms

Analyzing holes on other platforms is more difficult. Although vendors maintain documents on certain security holes within their software, organized reporting (except in cases if virus attacks) has only recently become available. This is because non-UNIX, non-VAX systems have become popular server platforms only in the last two years.

Reporting for these holes has also been done (up until recently) by individual users or those managing small networks. Hard-line security professionals have traditionally not been involved in assaying, for example, Microsoft Windows. (Oh, there are hundreds of firms that specialize in security on such platforms, and many of them are listed in this book. Nonetheless, in the context of the Internet, this has not been the rule.)

 

---

NOTE: That rule is about to change. Because security professionals know that Microsoft Windows NT is about to become a major player, reporting for NT holes will become a more visible activity.

---

Discussions About Holes on the Internet

Finding information about specific holes is simple. Many sites, established and underground, maintain archives on holes. Established sites tend to sport searchable indexes and may also have classic security papers ranging back to the days of the Worm. Underground sites may have all of this, as well as more current information. The majority of holes, in fact, are circulated among cracking communities first. For information about locating these resources, see Appendix A, “How to Get More Information.” To whet your appetite, a few sites and sources for information about security holes follow.

World Wide Web Pages

You’ll find loads of information about holes on numerous Web pages. Following are some that you should check out.

CERT

The Computer Emergency Response Team was established after the Internet Worm debacle in 1988 (young Morris scared the wits out of many people on the Net, not the least of which were those at DARPA). CERT not only issues advisories to the Internet community whenever a new security vulnerability becomes known, it

• is on call 24 hours a day to provide vital technical advice to those who have suffered a break-in
• uses its WWW site to provide valuable security information available, both new and old (including papers from the early 1980s)
• publishes an annual report that can give you great insight into security statistics

The real gold mine at CERT is the collection of advisories and bulletins. You can find these and other important information at http://www.cert.org (see Figure 15.3).

FIGURE 15.3.
The Computer Emergency Response Team (CERT) WWW site.

Department of Energy Computer Incident Advisory Capability

CIAC was also established in 1989, following the Morris Worm. This organization maintains a database of security related material intended primarily for the U.S. Department of Energy. The CIAC site is one of the best sources for security information. In addition to housing tools, this site also houses a searchable archive of security advisories. Moreover, CIAC provides to the public a series of security papers. Also, CIAC now utilizes the Adobe PDF file format, so the papers it provides are attractive, easily navigated, and easily formatted for printing. PDF format is, in my opinion, far superior to PostScript format, particularly for those not running UNIX.

Important information provided by CIAC to the public includes the following:

• Defense Data Network advisories
• CERT advisories
• NASA advisories
• A comprehensive virus database
• A computer security journal by Chris McDonald

CIAC is located at http://ciac.llnl.gov/ (see Figure 15.4).

FIGURE 15.4.
The Computer Incident Advisory Capability WWW site.

The National Institute of Standards and Technology Computer Security Resource Clearinghouse

The NIST CSRC WWW site (see Figure 15.5) is a comprehensive starting point. NIST has brought together a sizable list of publications, tools, pointers, organizations, and support services.

FIGURE 15.5.
The NIST CSRC WWW site.

The Forum of Incident Response and Security Teams (FIRST)

FIRST is a really a coalition of many organizations, both public and private, that work to circulate information on and improve Internet security. Some FIRST members are

• DoE Computer Incident Advisory Capability (CIAC)
• NASA Automated Systems Incident Response Capability
• Purdue University Computer Emergency Response Team
• Stanford University Security Team
• IBM Emergency Response Service
• Australian Computer Emergency Response Team

The interesting thing about FIRST is that it exercises no centralized control. All members of the organization share information, but no one exercises control over any of the other components. FIRST maintains a list of links to all FIRST member teams with WWW servers. Check out FIRST at http://www.first.org/team-info/ (see Figure 15.6).

FIGURE 15.6.
The FIRST WWW site.

The Windows 95 Bug Archive

The Windows 95 Bug Archive is maintained at Stanford University by Rich Graves. To his credit, it is the only truly comprehensive source for this type of information. (True, other servers give overviews of Windows 95 security, but nothing quite like this page.) This archive is located at

• http://www-leland.stanford.edu/~llurch/win95netbugs/archives/

Mr. Graves is a Network Consultant, a Webmaster, an Apple Talk specialist, and a master Gopher administrator. He has painstakingly collected an immense set of resources about Windows 95 networking (he is, in fact, the author of the Windows 95 Networking FAQ). His Win95NetBugs List has a searchable index, which is located here:

• http://www-leland.stanford.edu/~llurch/win95netbugs/search.html

The site also features an FTP archive of Windows 95 bugs, which can be accessed via the WWW at this locale:

• http://www-leland.stanford.edu/~llurch/win95netbugs/archives/

The ISS NT Security Mailing List

This list is made available to the public by Internet Security Systems (ISS). It is a mailing list archive. Individuals post questions (or answers) about NT security. In this respect, the messages are much like Usenet articles. These are presented at the following address in list form and can be viewed by thread (subject tag), author, or date.

• http://www.iss.net/lists/ntsecurity/

From this address, you can link to other security mailing lists, including not only Windows NT-related lists, but integrated security mailing lists, as well. You also have the option of viewing the most recent messages available.

Such lists are of great value because those posting to them are usually involved with security on an everyday basis. Moreover, this list concentrates solely on Windows NT security and, as such, is easier to traverse and assimilate than mailing lists that include other operating systems.

One particularly valuable element of this page is that you can link to the Windows NT Security Digest Archive Listing. This is a comprehensive database of all NT postings to the security list. Appendix A provides a description of various methods to incisively search these types of archives using agents. For the moment, however, it suffices to say that there are some very talented list members here. Even if you visit the list without a specific question in mind, browsing the entries will teach you much about Windows NT security.

 

---

Cross Reference: ISS is also the vendor for a suite of scanning products for Windows NT. These products perform extremely comprehensive analyses of NT networks. If your company is considering a security assessment, you might want to contact ISS (http://iss.net).

---

The National Institutes of Health

The Computer Security Information page at the National Institutes of Health (NIH) is a link page. It has pointers to online magazines, advisories, associations, organizations, and other WWW pages that are of interest in security. Check out the NIH page at this locale:

• http://www.alw.nih.gov/Security/security.html

This is a big site. You may do better examining the expanded index as opposed to the front page. That index is located here:

• http://www.alw.nih.gov/Security/tcontents.html

The Bugtraq Archives

This extraordinary site contains a massive collection of bugs and holes for various operating systems. The Bugtraq list is famous in the Internet community for being the number one source for holes.

What makes Bugtraq so incredibly effective (and vital to those studying Internet security) is that the entire archive is searchable. The information can be searched so incisively that in just a few seconds, you can pin down not only a hole, but a fix for it. The archive search index offers several choices on the type of search.

One important amenity of the Bugtraq list is that it is not inundated with advertisements and other irrelevant information. The majority of people posting to the list are extremely knowledgeable. In fact, the list is frequented by bona fide security specialists that solve real problems every day. Chris Chasin, the host of Bugtraq, defines the list as follows:

This list is for *detailed* discussion of UNIX security holes: what they are, how to exploit, and what to do to fix them. This list is not intended to be about cracking systems or exploiting their vulnerabilities. It is about defining, recognizing, and preventing use of security holes and risks.

In my opinion, Bugtraq is the Internet’s most valuable resource for online reporting of UNIX-based vulnerabilities. Visit it here:

• http://www.geek-girl.com/bugtraq/search.html

The Computer and Network Security Reference Index

This index is another fine resource page. It contains links to advisories, newsgroups, mailing lists, vendors, and archives. Check it out at

• http://www.telstra.com.au/info/security.html

Eugene Spafford’s Security Hotlist

This site can be summed up in five words: the ultimate security resource page. Of the hundreds of pages devoted to security, this is the most comprehensive collection of links available. In contrast to many link pages whose links expire, these links remain current. Check it out on-line at

• http://www.cs.purdue.edu/homes/spaf/hotlists/csec-top.html

 

---

NOTE: Note to Netscape users: Spaff’s page utilizes fundamental Web technology to spawn child windows. That means that for each link you click, a new window is spawned. New users may be unfamiliar with this method of linking and may be confused when they try to use the Back button. The Back button does not work because there is no window to go back to. If you plan to try multiple links from Spaff’s page, you will need to kill each subsequent, child window to get back to the main list. If you fail to do this (and instead minimize each window) you will soon run out of virtual memory.

---

Mailing Lists

Table 15.2 contains a list of security-related mailing lists that often distribute advisories about holes. Most are very useful.

 

---

CAUTION: Remember when I wrote about the large volume of mail one could receive from such a list? Beware. Subscribing to a handful of these lists could easily result in 10-30MB of mail per month.

---

 

 

---

TIP: If a list has a sister list that calls itself a digest, subscribe to the digest instead. Digests are bundled messages that come periodically as a single file. These are more easily managed. If you subscribe to three or four lists, you may receive as many as ten messages an hour. That can be overwhelming for the average user. (You’ll see messages from distraught users asking how to get off the list. These messages usually start out fairly civil, but end up as “Get me off this damn list! It is flooding my mailbox!”)

---

Table 15.2. Mailing lists for holes and vulnerabilities.

Summary

In this chapter, you have learned a bit about holes. This knowledge will serve you throughout the remainder of the book, for I discuss various holes in many chapters.

In closing, if you are new to security, the preceding pages may leave you with the sense that a hole is evidence of vendor incompetence. Not so. Vendor-based holes may take a long time to fix. If the vendor is large, this may expand into weeks or even months. Development teams in the corporate world work much like any other body. There is a hierarchy to be traversed. A software programmer on a development team cannot just make a material alteration to a program because he or she feels the need. There is a standardized process; protocols must be followed. Perhaps even worse is when the flaw exists in some standard that is administrated by a committee or board. If so, it may be a long, long time before the hole is fixed.