Catherine Allen, Security Programmer,
Australian Computer Emergency Response Team, AUSCERT,
c/- Prentice Centre,
The University of Queensland,
Brisbane, Queensland 4072
Australia.
There is an increased need to address the growing number and severity of security issues central to new and developing World Wide Web (WWW) services, especially usage involving commercial communication and transactions.
This paper examines internet security with respect to the WWW.
A number of WWW security issues are presented in three areas: server, client
and communication between server and client. Practical precautions
and solutions are suggested regarding these issues. Guidelines for protecting host systems are discussed.
This paper aims to promote an awareness of security issues in WWW site
maintainers and in general WWW users, without resorting to scare tactics.
Keywords:
World Wide Web
Security
Secure Transactions
AUSCERT
1. Introduction
This paper discusses security with respect to the World Wide Web (WWW). This paper is aimed to promote an awareness of security issues in general WWW users without resorting to scare tactics. Practical solutions and precautions for security problems are discussed.
As WWW browsers use the client-server paradigm the security problems relating to the WWW and to WWW browsers can be categorised into server problems, client problems and the need for secure communication between server and client.
The concepts and issues described in this paper apply to all operating systems,
servers and clients, although implementation differences may cause different
specific vulnerabilities. Examples used throughout this paper assume a UNIX host.
2. Server
Problems include bugs in the server software, environment, configuration, CGI scripts, data integrity and server-side-includes.
2.1. Bugs in Server Software
As the server code (often referred to as httpd) is large, it is likely to have some security vulnerabilities.
An implementation of the server which claims to be secure is the "secure" HTTP
daemon from all.net. This implementation is compact and has been specially
designed with security in mind.
It claims to be far more secure against corruption of
the server, denial of services to clients and unauthorized dissemination of information from the server than other,
standard daemons available
[Coh95].
2.2. Environment
There is no control over the environment in which the HTTP server runs. The server can be subverted by means of environment variables.
To combat this, run the server in a restricted environment. Then, if the server is subverted, the attacker cannot affect files or services outside the restricted area. Ensure that all binaries in this area are statically linked. Ensure that there are no shell scripts in this area as they require the shell to run and they may be subverted. If there is no shell in the restricted area then even if the server is subverted, the intruder will not be able to gain shell access.
On UNIX systems, it is possible to effect a restricted environment using the chroot command. This command resets the root of the file system tree to a directory so that only that directory and subdirectories within it may be accessed. Chroot to a directory which is used solely for the purpose of a single daemon. It is preferable that the directory is in a separate partition, so that there cannot be any hard links to other areas of the file system as these could be used to subvert the chroot mechanism. Please note that when the environment is restricted via chroot, all normal system files and devices are no longer accessible and provision must be made for this.
A detailed description of these modifications is beyond the scope of this paper.
2.3. Configuration
Be aware of the implications of the privileges with which the server is executed. If the server runs with superuser (or root) privileges and the server is subverted, then the intruder may be able to execute commands with root privileges.
The server should never be run with unnecessary privileges.
On UNIX systems, the server can run with the privileges of the user nobody. This user has no privileges and may not have command line (or shell) access. On non-UNIX systems, the server may run as any user with normal privileges and preferably a particular user which has no command line access.
2.4. CGI Scripts
The Common Gateway Interface (CGI) is a standard for interfacing external
applications with information servers such as HTTP or WWW servers. A CGI
script or program is a script or program written in any language that can be
executed on the system.
The server can be configured to execute only those CGI scripts which reside in the CGI binary
directory, e.g., /cgi-bin. If the ownership and
permissions are set correctly on this directory, then the average user will
not be able to create CGI programs without authorisation [CGIa].
Security risks with CGI scripts include user input, bad programming practice and server-side-includes [CGIb]. As server-side-includes also present a risk
outside CGI programs, they are described in a separate section.
User input should not be trusted [SI94]. Test for
unexpected input values
may cause the script to perform actions which were not intended by the author
special characters
may allow unauthorised access
unexpectedly large input
may cause buffer overflow or inappropriate actions
any other potential abuses.
Bad programming practice on UNIX systems includes the use of [CGIb]:
eval
can be subverted to allow an attacker to run an arbitrary command
popen() and system()
can be subverted easily to allow shell access.
There are many ways to fork processes within programming and scripting
languages. Within perl, open() to a pipe (i.e., open(OUT, "|program $args");),
backticks (i.e., `command`), exec, eval and the regular expression modifier /e all may fork a process.
Within C and C++, the popen() call forks a process. The ability to fork a process may allow an intruder to subvert the script or program [Pau95].
Attacks on the server via CGI scripts include mailing information to the
attacker (e.g., the password file, a map of the file system, or system
information from /etc), starting a logon server on a high port which allows the attacker to telnet to the machine, and many denial of service attacks [Paul95].
2.5. Data Integrity
If the server is subverted to allow intruder access to the files which contain the HTML code defining a WWW site then the information releaseed to the WWW may be modified. Depending on the nature of the organisation which runs the WWW site, this may be a serious matter. For example, if a Bank or Government were to run a WWW site which explained their policies, then it would be imperative that the text is not modified in an unauthorised manner.
To guard against this, the server host should be secured against a good
security policy [Mcm]. The AUSCERT UNIX Security Checklist [Aus95b] gives
specific instructions to improve the security of a UNIX host. If the server
host is compromised using a network service other than HTTP, the HTML files may
still be compromised.
On a UNIX system, if the server runs as user nobody and if the files containing
the HTML code are owned by root and are writable only by root then an intruder
would not be able to modify the information released to the WWW unless the
intruder had gained root access to the server host.
One way to ascertain whether the files containing the HTML code have been
modified is to use the Tripwire package [Tri94].
Tripwire creates a database of the ownership,
permissions, most recent modification date and content digest of a set of
files. The attributes and files recorded can be configured to suit each host.
This database can then be held offline so that it cannot be compromised.
Tripwire can be run periodically to test the current attributes and contents
of the files against their recorded attributes and contents. The system
administrator will be notified of any differences. It is advisable to run
Tripwire nightly on all hosts.
2.6. Server-Side-Includes
Server-Side-Include (SSI) describes a method of executing commands on the
server. These programs are executed when the page that contains them is loaded.
The server can be configured to parse for SSI commands in all
documents, some documents (usually those ending in .shtml) or no documents.
The default is to parse no documents.
The SSI commands are placed in HTML comments and are prepended with a #. For example:
<!-- #exec cgi="file.cgi"-->
The output of
the command is inserted into the document at the relative position of the command within the HTML code.
Legal SSI commands include #exec and #include. The server can be configured
to allow or disallow specific commands.[Kru]
If the SSI is subverted, it could be possible to run arbitrary programs on the
server with the privileges of the account under which httpd is run. Again,
this emphasises the need to run httpd as nobody and to run it in a chrooted
environment.
3. Client
The main client problems are automatic application launches, bugs in client software, embedded commands and the potential ability to bypass firewalls.
3.1. Automatic Application Launches
One of the more powerful aspects of WWW browsers that they will present information to the user in an immediately useful form.
Applications are launched automatically so, for example, sound files can be played automatically, postscript documents displayed automatically and so on. Some of the applications which are launched automatically are very powerful. For example, Ghostview includes file system commands. These applications run on arbitrary input which is provided by the server (which is potentially hostile from the client's viewpoint). As such, these applications can be subverted to allow unauthorised entry to the client machine.
The locations of the applications to be automatically launched can be configured
in the client. Allow only "sanitised" applications to be launched
automatically.
Most clients can be configured to disable the display of particular data types
or to disable the passing of those data types to external viewers. It is
advisable that at least the MIME and PL (perl) data types be disabled.
3.2. Bugs in Client Software
Browsers are large programs and as such can be expected to include security vulnerabilities. A serious vulnerability was found in NCSA HTTP Daemon V1.3 which
was subsequently patched.
Always run the latest version of the client software.
3.2.1. NCSA HTTP Daemon V1.3 Vulnerability
This vulnerability allowed commands to be embedded in a given URL.
Most client software, including the NCSA HTTP Daemon, can be
configured to show the URL pointed to by a link in a document while the mouse
pointer is situated over the link. It is always best to check the URL pointed
to by a link before clicking on the link. Things to look for include the
semicolon (;) character.
The fix for this vulnerability is described in the CERT Advisory CA-95:04
[Cer95] which is currently available from the AUSCERT FTP site.
Register with AUSCERT to be informed of fixes for security vulnerabilites as
these vulnerabilities are discovered [Aus95a].
3.3. Firewall Considerations
As the HTML specification allows protocols other than
HTTP (e.g., FTP, TELNET, RLOGIN), it may be used to bypass the filters
normally applied to those protocols by a firewall.
This can be rectified by using an HTTP proxy which filters the relevant
protocols as required [Dal94].
4. Secure Transactions
The main problem in communicating between server and client is that usually all data is transmitted over the Internet in clear text. Neither the client nor the server has any control over the route which the data takes through the Internet and neither neccessarily controls which other machines may have access to that data by means of network sniffers. If sensitive data is passed between the server and the client (e.g., credit card information) then the ability to provide secure transactions is required.
As the WWW becomes more widely used for commercial purposes, there will be a
larger requirement for communication which guarantees data integrity, data
confidentiality and user authentication.
General solutions for these
requirements have been proposed and currently include the Basic Protection
Scheme, the Public Key Protection Scheme, Digest Access Authentication and the
Simple Digest Security Scheme.
Current
implementations include NCSA's Secure HyperText Transfer Protocol (S-HTTP) and Secure Mosaic which are currently on trial in CommerceNet community,
Netscape's Secure Socket Layer (SSL) and CERN's Shen.
4.1. General Solutions
4.1.1. Basic Protection Scheme
Step 1. Server sends an unauthorized status [AL93a].
When the server receives a request without an Authorization:
field to access a protected document, it sends an Unauthorized 401
status code and a set of WWW-Authenticate: fields containing
valid authentication schemes and their scheme-specific parameters.
Step 2. Client authenticates itself.
The browser prompts for username and password. This is sent with the next
request in the Authorization: field.
Step 3. Server checks authentication and authorization.
If successful, then the server will send the document to the client.
4.1.2. Public Key Protection Scheme
This scheme is similar to the Basic Protection Scheme, but requires that the
username and password be encrypted with the public key of the server and that
documents be encrypted during communication over the Internet [AL93b].
Step 1. Server sends an unauthorized status.
In addition to the work done in the Basic Protection Scheme, the WWW server
also sends its public key in the WWW-Authenticate: header field of
the reply. If the client had given the Authorization: field
already with the request, then the scheme continues at step 3.
Step 2. Client authenticates itself.
The browser prompts for a username and password and then generates a random
encryption key. It concatenates these with the browser's IP address and a
timestamp, encrypts the string with the server's public key and encodes it into
printable characters. The encoded encrypted string is sent with the next
request in the Authorization: field.
Step 3. Server checks authentication and authorization.
The authorization string is decrypted and checked. The document will not
be sent if the IP address given does not match the requesting address. The
document will not be sent if the timestamp is not the same as the current
server time, within some limits in order to avoid replay attacks.
Step 4. Server sends an encrypted reply.
This is a binary file (not printable), as output by the encryption
procedure, in order to save time, space and bandwidth.
Step 5. Client decrypts the reply from the server.
4.1.3. Digest Access Authentication
This scheme is based on a simple challenge-response paradigm, like the Basic
Access Authentication scheme, but is designed to be more secure. It
challenges using a nonce value. A valid response contains the MD5
checksum of the password and the given nonce value. Thus, the password is
never sent over the Internet in clear text [HFH95].
4.1.4. Simple Digest Security Scheme
This scheme does not require the use of patented or export restricted
technology. As with the Basic Protection Scheme, an initial request is sent
without authentication and a new connection is established to communicate the
authentication parameters [Cern].
4.2. Implementations
4.2.1. Secure HyperText Transfer Protocol (S-HTTP)
Secure HTTP (S-HTTP) provides secure communication mechanisms between
an HTTP client-server pair in order to enable spontaneous commercial
transactions for a wide range of applications. It is designed
to provide a flexible protocol that supports multiple orthogonal
operation modes, key management mechanisms, trust models, cryptographic
algorithms and encapsulation formats through option negotiation
between parties for each transaction [RS94].
4.2.2. Secure Socket Layer (SSL)
The SSL Protocol is designed to authenticate the server and optionally the
client. It can negotiate an encryption algorithm and session key and
authenticate a server before any data is transmitted. All data is encrypted
before it is transmitted.
The SSL protocol provides channel security. The channel is private, authenticated and reliable [Hic95].
4.2.3. Shen
The Shen scheme provides for three separate security related mechanisms [Hal]:
Weak Authentication with low maintenance overhead and without patent or export restrictions
Strong Authentication via public key exchange
Strong Encryption of message content
5. Response to Security Incidents
The Australian Computer Emergency Response Team, AUSCERT, provides a single
trusted point of contact in Australia for the AARNet
community to deal with computer security incidents and their prevention.
As such, AUSCERT is uniquely placed to advise organisations about internet computer security, including WWW issues.
AUSCERT has collated and developed a comprehensive range of security packages and documentation which assist systems administrators to improve the security of
hosts, sites and networks.
If a security incident occurs, AUSCERT staff are available to provide advice and assistance with the co-ordination of the response to the security incident.
It is strongly recommended that all AARNet Members, Affiliates and
Associates of AARNet register with AUSCERT. Registration is free for all
AARNet Members and Affiliates and is restricted to Australian sites and
organisations only [Aus95c].
AUSCERT will respond to a call from any person within an organisation
regarding an incident and will attempt to assist that person with their problem. However, AUSCERT will only discuss security matters, particularly those of a sensitive nature, with an authorised contact established throught the registration process. Normally, incidents relating to that site will be reported to the organisation through the authorised contact mailing list.
If sensitive incident or vulnerability information is to be sent to
AUSCERT via electronic mail, it is advisable that the e-mail be encrypted.
AUSCERT can support a shared DES key and PGP.
AUSCERT currently uses PGP to digitally sign all official outgoing electronic
mail. The PGP system is being used because it is currently the most widely
deployed signature system available. Newer systems may be adopted as the relevant legislation and technologies change.
6. Conclusion
Several security issues have been raised and relevant, practical solutions suggested. Some mention has been made of the services which AUSCERT provides to aid the Australian Internet community with prevention of and response to security incidents.
7. References
[AL93a]
AL: Basic Protection Scheme Proposal, December 1993, http://www.w3.org/hypertext/WWW/AccessAuthorization/Basic.html
[AL93b]
AL: Public Key Protection Scheme Proposal, December 1993, http://www.w3.org/hypertext/WWW/AccessAuthorization/Pubkey.html
No author or date information: Simple Digest Security Scheme, http://www.w3.org/hypertext/WWW/Protocols/HTTP/digest_specification.html
[CGIa]
No author or date information: Common Gateway Interface, http://hoohoo.nsca.uiuc.edu/cgi/intro.html
[CGIb]
No author or date information: Writing Secure CGI Scripts, http://hoohoo.ncsa.uiuc.edu/cgi/security.html
[Coh95]
Cohen, Dr F.: Why is thttpd Secure?, http://all.net/ManAl/white/whitepaper.html
[Dal94]
Dalva, D. I.: Security and the World Wide Web, June 1994, http://www.tis.com/Home/NetworkSecurity/WWW/Article.html
[Hal]
Hallam-Baker, P. M.: Shen: A Security Scheme for the World Wide Web, undated, http://www.w3.org/hypertext/WWW/Shen/ref/security_spec.html
[HFH95]
Hostetler, Franks, Hallam-Baker, Luotonen, Sink and Stewart: A Proposed Extension to HTTP: Digest Access Authentication, Internet Draft, March 1995, http://ds.internic.net/internet-drafts/draft-ietf-http-digest-aa-01.txt
[Hic95]
Hickman, K. E. B.: The SSL Protocol, February 1995, http://home.mcom.com/info/SSL.html
McMillan, R.: Site Security Policy Development, undated, ftp://ftp.auscert.org.au/Site.Security.Policy.Development.wp.Z
[Pau95]
paulp@cerf.net: Safe CGI Programming, March 1995, http://www.primus.com/staff/paulp/cgi-security/safe-cgi.txt
[RS94]
Rescorla E. and Schiffman A.: The Secure HyperText Transfer Protocol, Internet Draft, December 1994, http://www.commerce.net/information/standards/drafts/shttp.txt
[SI94]
Smith, D. and Indulska, J.: Enhancing Security of Unix Systems, Proceedings of the AUUG94 Conference, p79-88.
[Tri94]
Tripwire version 1.2, August 1994, ftp://ftp.auscert.org.au/pub/coast/tools/unix/Tripwire/*
8. The Author
Catherine Allen
Catherine Allen has been a Security Programmer with the Australian Computer Emergency Response Team (AUSCERT) since August 1994. She has three years experience in the information technology industry, specialising in computer systems security and system administration. She has contracted to a number of commercial organisations providing technical consultation in security and service provision. Her experiences range from assisting sites with computer security issues and analysis of computer security vulnerabilites to researching and writing security advisories designed to assist system administrators to prevent intrusion. Her experience within AUSCERT places her in a unique position to analyse and present trends in computer security incidents on the internet in Australia.
Catherine was previously employed by the Prentice Centre at The University of Queensland as a system administrator for VMS and UNIX machines, including contract and facilities management work.
Catherine holds an Honours Degree in Computer Science from the James Cook University of North Queensland. She also holds a Bachelor of Science Degree with a double major in Computer Science and Mathematics from the same University.
