FEATURES
Continued

Web Server: SECURITY LOCKDOWN

by MICHAEL LEE

The servers we tested at the University of Wisconsin labs accommodate most forms of access control for individual Web pages. For example, Netscape Communications Corp. can control access with either an .htaccess file in the directory, or through special directives that can be configured in its Access Control administration page. The administrative page lets you put all of your access control information in a place. It's easier to manage than keeping track of the .htaccess files i n every directory on the server.

Odd Places to Find Data Not only can users have access to data they shouldn't have, server-based applications can run amuck. Make sure that you program Common Gateway Interface (CGI)-bin and Java applets intelligently. They are the major source of security holes in most systems. Make sure your CGI scripts only accept data they are supposed to accept, and be careful when "shelling out" to other local programs on your server, such as sendmail or grep.

If a Web server or browser crashes on a Unix system, it can leave a core file, which contains debugging information for programmers. On the ser ver end, the best way to control this is to restrict access to the server machine to trusted individuals only. For Web clients, be sure to remove any core files when your browser crashes. Anywhere that sensitive information is stored or transmitted can be a potential hazard.

You must be careful to ensure that no sensitive data passes across the network in the clear. Th is includes passwords sent via protocols other than HTTP, such as telnet or rlogin. A solution for shell access for Unix users, a kin telnet, is SSH, the Secure Shell. Information on the Secure Shell can be found at www.cs.hut.fi/ssh. It establishes a secure interactive session across the network, and can be used for remote administration of your Web server.

Authentication, Integrity and Privacy You've added access control, users and groups to your Web server, but have not yet prevented outsiders from intercepting the data in transit. If your browser is located elsewhere on the Internet, someone between the browser and server can watch the information going across the wire, capturing passwords, user and group names and any other information you pass among the machines. Later, the interceptor can use this information to pretend to be whomever he or she learned about. He or she also could intercept transmissions midstream, make modifications and send them on to the destination undetected.

To p revent this sort of network sniffing attack, you could introduce secure protocols that use encryption. With encryption, the interceptor will be unable to decipher data you're passing.

Security protocols work on different network layers and use different encryption algorithms, but share several concepts. The client and server communicate in such a manner that someone watching the communication on the network is unable to decipher what the client and server are saying to each other. Authentication, using certificates, makes sure the data hasn't been altered or forged. During a secure transmission, the client and server use information, called keys, known only to them to encrypt the data. Depending on the configuration, the client and server can use a shared key to transmit data, a public-private key pair or a combination of the two.

Data encrypted with a public key can be decrypted only with the corresponding private key, and vice versa. If Alice wants to send Bob a secret message, Alice can use Bob' s public key to encrypt the message and then send it to him. Bob can use his private key to decrypt the message, and since Bob is the only person who knows his private key, he can be assured that no one else reads the message. Only the private key can decrypt the data that was encrypted using the public key.

Shared-key algorithms are faster, but it's difficult to ensure that the keys will be exchanged without interception from a rogue party. So public-private key encryption is used to exchange a shared key. From that point on, the shared key is used to encrypt.

CGI-Bin: Busting Bugs And Break-Ins

The NCSA version 1.5 server from the National Computer Security Association and Apache 1.0.3 from Apache Group httpd programs were packaged with a sample Common Gateway Interface (CGI)-bin program that makes it possible for remote users to steal local files on your server, including the /etc/pa sswd file. This hole was publicized as a CERT advisory on March 20, where it was reported that the hole was being actively exploited. The CGI-bin program, phf, was created with a utility function, called escape_shell_command(), in a C utility file called util.c. The escape_shell_command() function was created to prevent people using CGI-bin programs from passing special meta-characters to local programs the CGI-bin program can run through a system() call. It is easier for CGI-bin programmers to call Unix or shell utilities that already have been written than to rewrite them into the CGI-bin program. However, early versions of this function contain a vulnerability that is fairly easy to exploit.CERT recommends that anyone using this version of the escape_shell_command() call replace it with the patched version. The patched version of the util.c utility file is available from the NCSA and Apache Group. If you're using the old version, you're susceptible to attacks. Even if you're not using NCSA or Apache, and have borrowed this programming library or the phf executable, you're still susceptible. Check your Web server today. It won't take long, and it may save you some real headaches in the future.

The phf bug was recently exploited at the University of Wisconsin-Madison. Jeff Savoy, the university's network investigator, gave site administrators three pieces of advice: Check your log records frequently; don't run your server as root; and shadow your password file. If these sites had shadow passwords enabled, the encrypted password in the password file probably would not have been stolen.