[CS Home Page] [Top Level - All Titles] [Top Level - This Title] [Expand This View] [Collapse This View] [Previous Hit] [Next Hit] [Clear Search] [Show Frames]

Expand Search


COMPUTER 0018-9162/98/$10.00 © 1998 IEEE
Vol. 31, No. 9: SEPTEMBER 1998, pp. 34-41


Contact Rubin at AT&T Labs-Research; 180 Park Ave.; Florham Park, NJ 07932; rubin@research.att.com. Contact Geer at Certco; 55 Broad St.; New York, NY 10004; geer@world.std.com.

A Survey of Web Security

[PDF ICON]

Aviel D. Rubin AT&T Labs

Daniel E. Geer Jr. Certco

Developing security methods for the Web is a daunting task, in part because security concerns arose after the fact. The authors offer a survey of Web security issues, focusing on particular areas of concern, such as server security, mobile code, data transfer, and user privacy.

With no insult intended to the early Web designers, security was an afterthought. At the outset, the Web's highest goal was seamless availability. Today, with an internationally connected user network and rapidly expanding Web functionality, reliability and security are critical. Vendors engaged in retrofitting security must contend with the Web environment's peculiarities, which include location irrelevance, statelessness, code and user mobility, and stranger-to-stranger communication.

In this article, we present a survey of Web-specific security issues. Given the Web's rapid ascent, our offering is necessarily a mix of short-lived techniques and long-lived principles. Our focus is on security in the server and host environments, mobile code, data transport, and anonymity and privacy. We do not delve into cryptography, electronic commerce, or intrusion detection because they are not Web-specific, and they are well covered elsewhere.1,2

SERVER SECURITY

In the client-server environment, we focus on the server side because the server is the central system and the repository of information resources. The server is thus the locus of threats, whereas the client is largely out of sight. Protecting the client side from the server side is generally not an issue, except where client privacy is a concern, as we discuss below.

We describe security issues using a Unix-based Apache server as an exemplar. The Apache server is based on the server at the National Center for Supercomputing Applications (NCSA) and is the most widely deployed server (for more on Apache, see http://apache.org/). CERN's server is almost parallel to the Apache server and is well documented. Sadly, many commercial servers have diverged from each other and from the Internet's de facto standards. There is no way for us to cover them all. However, regardless of what Web-server software is running, some things are common, such as security configuration, authentication and access issues, and methods of dealing with active content.

Configuration basics

The biggest cause of security problems is bad management. In distributed systems, the first place management affects security is in the system's configuration. A bad system configuration can mean disaster. If configuration is not controlled, it is difficult to express management policy in the system's operational characteristics. As system complexity increases, the problem becomes acute: The inability to make systems conform to policy ensures increasing disarray and the exploitable holes that result.

The Web-server configuration file lives in the server root. Configuration files are composed entirely of directives and explanatory comments. A directive is just a keyword that the HTTP daemon recognizes, followed by arguments. Directives are insensitive to case and white space. They control which file contains user names and passwords and which file contains group names and passwords, as well as access to the files in the document tree, including default permissions and how to override them locally.

Setting up roots

A Web server has two root directories: the server root, which contains the server's control information; and the document root, which contains the content and is usually a subdirectory of the server root. The document root is where a browser goes if the URL contains only the server's name[mdash]such as http://web.mit.edu/. Configuration files for both the server root and the document root are sensitive and must be visible only on a need-to-know basis.

The most common mistake system administrators make is to run a Web server as root. Binding the conventional WWW port number[mdash]privileged port 80[mdash]requires root privilege at the outset, but running the Web server as root thereafter creates vulnerability.

The most common fix here is to run the Web server as nobody, but if other programs are also running as nobody, privileges can intermix. Thus, the best practice is to run the server as a genuine user, say, Webserver, with both a unique user ID and membership in a group, such as "WWW." Typically, the home directory of user, Webserver, is the server root and contains the document root. Only the WWW group should have read access to the server log and server configuration files.

With this method, the Web server's configuration file specifies which user to actually run as[mdash]that is, the server performs a "suid Webserver" (sets its user ID as Webserver) after the HTTP daemon has bound the HTTP-privileged port. The owner of the Web-server binary is irrelevant and must not have the suid bit set. By assuming the identification and privileges of a user other than the user who owns the executable, the program can turn privileges on and off, as well as assume the identity of other users. In this way, the Web server runs with a group ID read access to all the files it needs, but it does not have write access to itself or its own configuration files. Under such a regime, a compromised Web server will not lead to deeper penetration of the host system.

Local control issues

A server-side include is HTML code that pulls either a file or the output of a command into the output stream when the user requests the URL containing the page. In other words, it is dynamic rather than static content. The include contains one of three related calls:

Server-side includes can be very useful, but they can also be computationally expensive, demolish portability, and open security holes. If they are necessary, the best practice is to disable the execute feature.

Many of a Webmaster's security directives can be overridden on a per-directory basis. As with server-side includes, the convenience of being able to make local exceptions to global policy is offset by the threat of a security hole being introduced in a distant subdirectory[mdash]which could be controlled by a hostile user. As with server-side includes, Webmasters should disable a subdirectory's ability to override top-level security directives unless that override is required.

Authentication

Web services depend on name services. If a hostile party gains control of the name service, any security based solely on correlating names and network addresses will be for naught.

Basic authentication is simply a conventional username and password that is passed openly across a network. This creates the obvious risk of password capture. To control access on a per-directory or per-server basis, a user name can be combined with IP addresses. In this way, a server can evaluate file permission from the bottom up[mdash]that is, it looks for directives first in the local directory, then in the enclosing directory, and so on, back to the document root. This is the reverse of how most file systems work.

Like basic authentication, digest authentication verifies that both parties know a shared secret (a password), but here the verification is done without sending the password openly. Digest authentication uses a simple challenge to verify a password: response exchange. In this approach, the digest scheme challenges the user using a nonce value[mdash]a one-time authenticator (usually a large random number). A valid response contains a checksum (by default, the MD5 checksum) of the username, the password, the given nonce value, the HTTP method, and the requested URL.

To authenticate the server to its clients, public-key identity certificates can be used in the transport layer. Although not yet widely adopted, client certificates can also be used to authenticate clients to the server. The use of public-key identity certificates assumes a pervasive, highly available public-key infrastructure, including both certifying authorities to issue certificates and revocation authorities to revoke them. This infrastructure does not exist, and is perhaps only possible on a smaller scale, such as within an organization.

When documents are delivered by means of FTP, the FTP daemon (ftpd) is typically set up as an anonymous FTP server. In this case, anonymous actually means unauthenticated. Internet Security System's "Anonymous FTP FAQ" thoroughly documents security issues related to the use of anonymous FTP. At a minimum, system administrators should run a good quality FTP daemon and make sure it is chroot'd. If the FTP area overlaps with or duplicates the HTTP area, uploads must be segregated from served content. Any Web server will automatically read or execute certain filenames in any directory they serve. A clever attacker will merely use FTP to put a command where the HTTP daemon is sure to find it.

Scripting

Nearly all Web servers must deal with some type of active content. Common Gateway Interface, or CGI, is a sort of metalanguage, or middleware, that allows the interoperability such content requires. The core idea is sound and proven[mdash]a platform-independent programming language for scripts. In a sense, CGI is to programming what HTML is to documents.

The only requirement on a CGI-reachable language is that it must use the same environment variables as the HTTP daemon, and it must read from stdin and write to stdout. Because CGI talks to programs, it includes arguments to send and return-values to receive; both are carried either in the URL or in HTML forms. Non-script-aliased CGI means that CGI programs might appear in any directory if they have the proper filename extension. Script-aliased CGI means that CGI programs might appear only in an explicitly named directory, typically the subdirectory /cgi-bin in the server root. This is the more common approach for a security-minded site.

The server evaluates all URLs from left to right: The protocol component tells how to connect to the server and, once there, the server serially evaluates each piece of the path component. As soon as a leading substring of the URL evaluates to a runnable script or a displayable document, the remainder of the URL is handed to the document as an argument. This is called additional path information.

CGI scripts are usually written in Perl, Tcl, Java, Python, or C. Regardless of how many Web pages a server hosts, it runs every CGI script as the same user. Thus, CGI scripts written by different individuals run under the same user identity and all such scripts have the same permissions with respect to each other.

Many celebrated system intrusions can be traced to the attacker sending data that a program cannot handle. As a Web-specific example, consider forms. It is relatively common to have some master form, such as an order blank, and to send the form to the user with some data already included (perhaps in hidden fields). The user fills out the rest of the form and then posts it to the server, which takes some action based on the form's contents, such as processing an order for a Dilbert coffee mug. An even modestly clever attacker might modify the hidden fields to get, say, 50 Dilbert mugs for the price of one. Another variation is to modify a system command's arguments. CGI scripts in any of the common languages (Perl, C, and C++) can be taken advantage of in this way, unless the input data is carefully scrubbed.

SECURING THE HOST

Host security focuses on the host system's configuration and operational practices and provides a foundation for server security.

Basic threats

Challenges in host system security include complexity, access control, and accountability.

The Webmaster should audit the host system regularly and increase the frequency of audits if the host system changes often and in substantive ways. Any system popular enough to be generally dangerous typically has both commercial audit and do-it-yourself freeware such as COPS,8 TAMU,9 and Tripwire.10 Given the Web's burgeoning importance, audit systems can check the more obvious Web-server security issues as well. This is a good area for Webmasters to work closely with system administrators.

Notification and recovery

Notification services, which keep running lists of se-curity incidents, play a vital role in host security. Such well-known groups as the Computer Emergency Response Team (CERT) and the Computer Incident Advisory Capability (CIAC) publish bulletins for Webmasters and system administrators. The World Wide Web Consortium provides a similar, though less formal, service. The sidebar, "Three Vulnerabilities," presents examples of common intrusions reported to CERT.

Another host-security tool is an event-management system, which responds to some types of events with evasive action. These systems are deployed mainly in demanding production environments, although several commercial and freeware event-management systems are available.

Finally, because intrusions are inevitable, recovery must be considered. If a Webmaster suspects penetration, it is better to err on the side of prudence. There are a few morning-after resources available. The best place to start is with a checklist for intrusion handling. For Web services that must be available, issues typical of any data center are likely to be reflected on the Web service.

SECURING DATA TRANSPORT

There are two fundamentally different ap-proaches to securing data in transit. In the network-layer approach, the encryption and authentication is added directly into the networking stack so that traffic is protected without requiring the application to incorporate it. Traffic reaching the remote system is automatically decrypted and verified by the remote system's networking stack before the operating system passes it to the server application. In the application-level approach, the application itself is modified so that traffic is encrypted before it is submitted to the operating system and network layer. It is then decrypted by the receiving server application.

Both approaches have their advantages and disadvantages, and they can be implemented simultaneously. Transaction security is vulnerable at both ends of a secured connection. Credit card information sent across the Web using an application-layer secure transaction is vulnerable to theft once it has been transferred to the remote server. It is also vulnerable at the user's keyboard or within the application itself. On the other hand, attackers can defeat network-level transaction security by exploiting transitive trust and host-security flaws to steal data before it is securely transmitted over the network. For the Web, application-layer security is the better choice because it makes it easier to define the trust boundaries between transacting agents.

SSL protocol

The best candidate for application-layer security is Netscape Communications Secure Socket Layer (SSL) protocol, which is currently in its third revision. The SSL protocol is stream-based, which means it consists of an initial handshake phase in which secure communications are established, followed by an application-to-application dialog (with encryption applied to the data) and a closing handshake.

How it works. When the client connects, the server and client exchange hello messages to establish the protocol version in use, define optional encryption algorithms, exchange keys, and define optional data-compression parameters. The server and client can also mutually request X.509 certificates for authentication, including a complete chain of certificates leading to a certification authority. The client generates the bulk encryption keys and sends them to the server encrypted with the server's public key from its certificate. A total of four keys are used, with separate pairs for client-to-server and server-to-client communication.

Once SSL completes the initial handshake, it enters into an opaque data mode, in which application data is passed in encrypted, sequenced chunks, each including a cryptographic checksum to prevent tampering. Multiple encryption algorithms including RC4 and DES are supported. Following the interaction, they perform a completion handshake and close the connection. Netscape has clearly designed SSL to be a generic protocol, so it can serve applications other than just HTTP, including (potentially) e-mail and database access. If the Netscape vision is realized, SSL could become a ubiquitous security layer for many different application types.

SSL problems. The first two versions of SSL had numerous shortcomings that prevented its wide use, particularly for applications involving substantial risk or funds transfer. For example, the SSL implementations did not use client-side certificates for authentication. Instead, the server authenticated itself to the browser, but there was no reliable mechanism for customer identification. This meant that SSL was mostly used to set up a secure link over which a password was exchanged. Conceptually and technically, this was extremely inelegant. SSL suffered a number of widely publicized flaws including protocol flaws and serious deficiencies in its random key-generation routines.

To make matters worse, the freely available version of Netscape Navigator only includes the RC4 encryption algorithm with 40-bit keys, in compliance with US export-control regulations. Several individuals set up brute-force attacks against the 40-bit keys and announced the results, creating a public doubt about SSL's security. However, this is not a failing of SSL, but rather an outcome of the government regulations. The only fix for this problem is to require customers to purchase the US-only version of Navigator[mdash]which includes SSL Digital Encryption Standard (SSL/DES). Of course, requiring users to purchase Navigator completely defeats the reason many companies want to use SSL: the large installed base of free Navigator versions.

SSL possibilities. Netscape is currently formulating a programming interface for integrating SSL directly into Winsock2.0. Because Winsock operates at a virtual session layer, Netscape's proposal adds a few calls to the Winsock management routines that allow any program to request that a connection negotiate SSL security as either a client or a server. The additions to the specification would be completely unintrusive to existing applications, but would let future applications take advantage of security with the addition of a single function call. If this capability is completed and becomes widely used, it will provide capabilities similar to network-level transaction security on an application-by-application basis.

SSL has garnered significant user support, primarily because of the large Navigator client base. Most commercial Web-server packages support SSL, and many free Web servers include hooks for integrating SSL. To encourage developers to embed SSL in their applications, Netscape has made a reference implementation, SSL-ref, available for download.

Security and export controls

As the SSL experience shows, export controls are a big issue in application-layer transaction security. If users must rely on cryptography that can be broken quickly by a motivated attacker, well-designed security protocols are irrelevant. The legal requirement to use poor quality encryption is a barrier to the growth of electronic commerce over public networks.

However, because government encryption policies in some countries are increasingly subjected to political and legal challenges, the situation seems destined to change. If it doesn't, we might eventually see a booming business in offshore development of software modules that can be incorporated into export-restricted software.

Export-control politics are one of the single largest factors influencing the security[mdash]or rather, insecurity[mdash]of protocols for Web transaction security. It is hard enough to get vendors to agree on standards without having the government actively working to cripple the results.

MOBILE CODE SECURITY

Mobile code comprises general-purpose executables that run in remote locations. That such general-purpose scripts can run on any Internet-connected computer opens up a world of possibilities for distributed applications. However, such functionality comes at a price. From a security perspective, nothing is more dangerous than a global, homogeneous, general-purpose interpreter. The fact that this interpreter is part of a browser[mdash]a large, notoriously buggy software package[mdash]only increases the risks.

There are basically three practical techniques to secure mobile code: sandboxing, code signing, and firewalling. The sandbox method limits the executable's privileges to a small set of operations. The code signing method checks to see if the executable's source is trustworthy. A combination of these two methods was implemented in JDK 1.211 and Netscape's Communicator.12 The firewalling approach limits the programs a client can run based on the executables' properties.

Aside from these approaches, there is growing interest in a technique called proof carrying code,13 where mobile programs carry a proof that certain properties are satisfied. This technique is still in the theoretical stage. It is uncertain as yet whether it can be used, for example, to manage access control between Java applets and client resources.

ANONYMITY AND PRIVACY

Information about a user's activity on the Web is increasingly being recorded and disseminated. Thus, as Web functionality increases, gains achieved in convenience are counterbalanced by privacy losses. Users are often unaware of the deficit. Web users leave a data shadow, with information about what they read, where they shop, what they buy, whom they correspond with, and so on.

Cookies, for example, let stateless servers outsource state information to client storage. Thus, a high-volume server can track a significant amount of information about a user's browsing habits. Multiple servers in collaboration can build up even more information. Many targeted advertising companies share information about user profiles and build massive databases containing users and their data shadows.

Attempts to introduce technology to protect user privacy include mixes,14 proxy mechanisms, and Crowds.15

David Chaum's mixes were originally introduced to counter traffic analysis. The same technology has since been adopted to provide anonymous e-mail16 and anonymous Web browsing.17 A mix is a process with a corresponding public-key pair. It accepts messages, decrypts them, and forwards them. A mix network can also be used, where each mix removes an encryption layer and messages are source-routed through the mix network to the destination.

Mixes are well suited to the problem of anonymous e-mail. When users select a set of trusted remailers (e-mail mixes), the message recipient cannot tell where the message originated. There are many such remailers available for use today (see the list at http://www.cs.berkeley.edu/~raph/remailer-list.html). Mixes are not as well suited for synchronous communication, such as Web browsing, because collaboration between the first and last mix can reveal the identity of both sender and receiver, based on the content and timing of requests. Also, the use of public-key cryptography impedes the performance of such a system. It remains to be seen whether wide-scale adoption of mixes for Web browsing is possible.

A more lightweight approach to privacy is to interpose a well-known proxy between clients and all servers. The proxy rewrites all client requests so that the end server has no way of identifying the origin of requests. This is the approach taken by the Anonymizer ( http://www.anonymizer.com/) and Lucent Personalized Web Assistant.18 Unfortunately, unless encryption is used, a system administrator or anyone who can eavesdrop on the local network can still observe all content on the link between a client and server. Furthermore, proxy administrators must be trusted not to store or reveal user-activity information.

When users browse the Web in Crowds, any action they take is attributed to the crowd as a whole, thus offering individual users relative anonymity. The Crowds system runs on Windows and Unix platforms and has been deployed on the Internet. Crowds was analyzed against various adversaries[mdash]such as local eavesdroppers, system administrators, groups of collaborating crowd members, and end servers[mdash]and to our knowledge is the only method to date that provides some formal guarantees of anonymity.

CONCLUSION

The state of Web security is abysmal. The mushrooming number of security vendors is decreasing the average quality of their wares; only a few vendors can deliver security that is invisible and inescapable. Yet, if we had fewer vendors to begin with, our fate might have been similar to having a few farmers plant the same strain of corn. Thus far, the Web's inherent tendency to diversity and innovation has spared us a security monoculture (and the inherent risks therein). The trend toward a unified public-key infrastructure with regulatory icing should be watched with this in mind.

Web security mechanisms are a collection of clever, ad hoc efforts to retrofit security into a system whose popularity overwhelmed its original design. There is evidence, however, that use of the Web for business will inevitably result in a more serious approach to security. Public-key technology's unique applicability to stranger-to-stranger communication and the Web's relentless blurring of the intramural-extramural distinction strongly favor PKI as the skeleton on which Web security will hang. A trust management paradigm for securing Web commerce will give way to a risk management one in proportion to the value of the transactions moving on the Web. This will, in a sense, solve the otherwise thorny problem of good security in a user community burgeoning too fast to be anything but skill-poor.

Several online security resources are available, from Lincoln D. Stein's fine advice ( http://www.genome.wi.mit.edu/WWW/faqs/www-security-faq.html) to the very helpful aggregation and dissemination work at Rutgers University and Purdue University's Coast Laboratory to the Internet Engineering Task Force's Site Security Handbook.19 The security areas we have discussed here[mdash]server and host environments, data transport, mobile code, and anonymity and privacy[mdash]are very active, but the amount of investment already sunk into these areas is steadily raising the bar on how good a new idea must be before implementation is worthwhile. These are interesting times.

References


1. A.D. Rubin, D. Geer, and M.J. Ranum, Web Security Sourcebook, John Wiley & Sons, New York, 1997.
2. A. Menezes, P. van Oorschot, and S. Vanstone, Handbook of Applied Cryptography, CRC Press, Boca Raton, Fla., 1997.
3. US Dept. of Defense, "Trusted Computer System Evaluation Criteria," National Computer Security Center, DoD 5200.28-STD, Dec. 1985.
4. S. Garfinkel and E. Spafford, Practical UNIX Security, O'Reilly & Associates, Sebastapol, Calif., 1991.
5. D. Curry, UNIX System Security[mdash]A Guide for Users and System Administrators, Addison Wesley Longman, Reading, Mass., 1992.
6. B. Lampson et al., "Authentication in Distributed Systems: Theory and Practice," ACM Trans. Computer Systems, Nov. 1992, pp. 265-310.
7. J.G. Steiner, C. Neuman, and J.I. Schiller, "Kerberos: An Authentication Service for Open Network Systems," Proc. Winter 1988 General Conf., Usenix Assoc., Berkeley, Calif., 1988, pp. 191-202.
8. D. Farmer and E.H. Spafford, "The COPS Security Checker System," Proc. Summer 1990 General Conf., Usenix Assoc., Berkeley, Calif., 1990, pp. 165-170; ftp://info.cert.org/pub/tools/cops/.
9. D.R. Safford, D.L. Schales, and D.K. Hess, "The TAMU Security Package: An Ongoing Response to Internet Intruders in an Academic Environment," Proc. Fourth Security Symp., Usenix Assoc., Berkeley, Calif., 1993, pp. 91-118; ftp://net.tamu.edu/pub/security/TAMU/.
10. G.H. Kim and E.H. Spafford, "The Design and Implementation of Tripwire: A File System Integrity Checker," Tech. Report CSD-TR-93-071, Purdue University Coast Laboratory, West Lafayette, Ind., Nov. 1993; ftp://info.cert.org/pub/tools/tripwire/.
11. L. Gong et al., "Going Beyond the Sandbox: An Overview of the New Security Architecture in the Java Development Kit 1.2," Proc. USENIX Symp. Internet Technologies and Systems, Usenix Assoc., Berkeley, Calif., 1997, pp. 103-112.
12. D.S. Wallach, D. Blafanz, D. Dean, and E.W. Felten, "Extensible Security Architectures for Java," Proc. 16th ACM Symp. Operating Systems Principles, ACM Press, New York, 1997.
13. G.C. Necula and P. Lee, "Safe Kernel Extensions Without Run-Time Checkin," Proc. Second Symp. Operating Systems Design and Implementation, Unix Assoc., Berkeley, Calif., 1996, pp. 229-243.
14. D. Chaum, "Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms," Comm. ACM, Feb. 1981, pp. 84-88.
15. M.K. Reiter and A.D. Rubin, "Crowds: Anonymous Web Transactions," ACM Trans. Information Systems Security, Apr. 1998; see also http://www.research.att.com/projects/crowds.
16. C. Gulcu and G. Tsudik, "Mixing E-mail with Babel," Proc. 1996 Internet Society Symp. Network and Distributed System Security, IEEE CS Press, Los Alamitos, Calif., 1996, pp. 2-16.
17. P.F. Syverson, D.M. Goldschlag, and M.G. Reed, "Anonymous Connections and Onion Routing," Proc. 1997 IEEE Symp. Security and Privacy, IEEE CS Press, Los Alamitos, Calif., 1997, pp. 44-54.
18. E. Gabber et al., "How to Make Personalized Web Browsing Simple, Secure, and Anonymous," tech. report, May 1997; see also http://www.lpwa.com/.
19. D.L. Oppenheimer, D.A. Wagner, and M.D. Crabb, Site Security Handbook, RFC 1244/FYI:8, IETF, 1991.

Aviel D. Rubin is a senior technical staff member at AT&T Labs-Research in the secure systems research department and an adjunct professor of computer science at New York University, where he teaches cryptography and computer security. He is the co-author of the Web Security Sourcebook (John Wiley & Sons, 1998). Rubin received a BS, an MSE, and a PhD from the University of Michigan, all in computer science and engineering. He has served on several program committees for major security conferences and as the program chair for the 1998 Usenix security conference. He will also be the program chair for the 1999 Usenix technical conference.

Daniel E. Geer Jr. is vice president of Certco, LLC, a market leader in digital certification for electronic commerce. He has a long history in network security and distributed computing management as an entrepreneur, consultant, teacher, and architect. He is the co-author of the Web Security Sourcebook.

Three Vulnerabilities

Cory F. Cohen CERT Coordination Center

Shawn V. Hernan CERT Coordination Center

Derek K. Simmel CERT Coordination Center

On the basis of incidents reported to the CERT Coordination Center during 1996 and 1997, we identified three vulnerabilities that left systems open to the most frequent and serious attacks. Even long after we published alerts describing these vulnerabilities and their corresponding patches, intruders continued to exploit them to gain unauthorized access. For example, the first known public discussion of the phf vulnerability1 was in February of 1996, but CERT/CC received reports of incidents involving phf through July of this year.

PHF VULNERABILITY

The phf vulnerability is named after a seldom used but often installed example cgi-bin script that was distributed with several Web servers, including Apache. The vulnerability lets an intruder execute arbitrary commands with the privileges of the Web server.2 Using user-supplied arguments, the phf script constructs a command that the OS executes as if it were entered at a shell prompt. Early versions of the script attempted to guard against shell metacharacters such as ";" and "&", which might cause the command to appear as two commands. Unfortunately, these versions of the script failed to consider that the newline character[mdash]which is a shell command separator[mdash]might be included in the input supplied by the user. By embedding a command following a newline in the input to the vulnerable phf script, an attacker succeeds in getting the Web server to execute that command.

Because this vulnerability is commonly exploited to display a copy of the /etc/passwd file, some sites mistakenly believe that if they use strong passwords or shadow passwords, an intruder is unable to use the phf vulnerability to gain access. However, an intruder can choose to execute commands that compromise security in other ways. Other sites assume that even if an intruder can capture and decipher passwords, they are still safe, since their firewall blocks inbound telnet, ftp, or similar kinds of connections. Unfortunately, many of these sites permit arbitrary outbound connections. Therefore, intruders can use the xterm command to open a terminal window on their displays, giving them access to a shell on the Web-server host. From there, they can attempt to gain greater privileges or access to other machines.

Intruders might not even need to probe your site to know if the phf script is accessible, as it might already appear in the indices of popular Internet search engines. More than 650 phf-related incidents involving thousands of hosts have been reported to the CERT/CC since the publication of CERT advisory CA-96.06 in March 1996. Many sites had simply installed the example cgi-bin scripts and accepted the default configuration of their Web-server software without question. If they had excluded anything they did not explicitly require, most of the vulnerable phf scripts would not have been installed and exploited.

INN VULNERABILITY

Some site managers rely on vigilance and chance to defend their networks. By closely monitoring sources of security information and acting on the information quickly, they believe that they are immune to attacks. Some types of vulnerabilities, however, spread faster than people can respond to them. One example is the INN vulnerability, named after a vulnerable implementation of a Usenet News (NNTP) server.

A now-outdated version of the INN news server contains a vulnerability that lets intruders execute a command with news-server privileges by crafting a particular type of message.3 By using the Usenet news-distribution mechanism, a message containing an exploit rapidly reaches news servers all over the world. Consequently, numerous vulnerable sites can be damaged before even the most vigilant system administrators can respond.

Unless your firewall is preconfigured to recognize and stop this vulnerability, it can propagate behind your firewall before you have time to respond. One incident reported to the CERT/CC involved the compromise of 2,000 to 5,000 hosts. Many of these hosts were compromised within a few hours after the intruder released an exploit message to a single news server.

IMAP VULNERABILITY

Certain implementations of Internet Message Access Protocol let intruders execute commands with IMAP-server privileges.4 Vulnerable IMAP servers statically allocate space to hold the username; by providing a username that exceeds the buffer length, an intruder can cause the IMAP server to execute any code.

Some sites filter at their network perimeter only those services that present a known risk or that let remote users gain access, like telnet. These sites might overlook services such as IMAP. Unfortunately, some operating systems install a vulnerable version of an IMAP server by default.

Intruders looking for vulnerable IMAP servers have run many large scans of the Internet involving tens of thousands of hosts. There is some circumstantial evidence that indicates that groups of intruders are cooperating to scan large portions of the Internet and are exchanging information about vulnerable hosts.

CERT advisory CA-97.09 was released in April 1997. Between September and December of that year, more than 20 percent of incidents reported to CERT/CC involved the IMAP vulnerability. A similar vulnerability,5 described in the July 1998 CERT advisory CA-98.09, shares many of the characteristics of the original IMAP vulnerability and might become just as widely exploited.

References


1. J. Myers, "CGI Security: Escape Newlines," Bugtraq Archives, Feb. 1996; http://geek-girl.com//bugtraq/1996_1/0036.html.
2. IBM Emergency Response Service, "ERS-SVA-E01-1996:002.1," Feb. 1996; http://www.ers.ibm.com/tech-info/advisories/sva/1996/.
3. CERT Coordination Center, "CERT Advisory CA-97.08," Feb. 1997; http://www.cert.org/advisories/CA-97.08.innd.html.
4. Secure Networks Inc., "Remote Vulnerability in imapd and ipop3d," Mar. 1997; at http://www.secnet.com/sni-advisories/imap.advisory.03.02.97.html.
5. CERT Coordination Center, "CERT Advisory CA-98.09," July 1998; http://www.cert.org/advisories/CA-98.09.imapd.html.

Cory F. Cohen is a member of the technical staff at the CERT Coordination Center.

Shawn V. Hernan is a member of the technical staff at the CERT Coordination Center, where he leads the vulnerability handling group.

Derek K. Simmel is a member of the technical staff in the Networked Systems Survivability Program at the Software Engineering Institute.