The explosive growth of the Internet has transformed a technical playground into a many-faced entity. One of the faces of today’s Internet is that of electronic storefront. Until recently, electronic commerce suites carried large price tags to discourage the casual businessman from getting involved with electronic commerce. The advent of Open Source [OS] applications has led to free software availability to the small business. Free software is attractive to the novice, particularly when it claims to be adequate for small businesses.
The mix of technically naïve businesses and free software creates the possibility of less than secure software being deployed and used in actual commerce applications on the Internet. Without the ability to analyze the source code, businesses adopting Open Source applications place themselves at greater risk of attack by those capable of inspecting the source code for vulnerabilities if vulnerabilities do exist.
This possibility is what led to the project described in this paper. Several Open Source electronic commerce systems [CIS, MV] exist. WebStore [WS] is available from Extropia software. Extropia freely distributes the source code for WebStore under the Open Source license. For this project, WebStore was downloaded and its documentation and source code were inspected for security vulnerabilities in the areas of disclosure, integrity, and denial of service.
Section 2 presents the WebStore architecture in brief. Section 3 reviews the methodology used in evaluating WebStore for security vulnerabilities. Section 4 presents WebStore’s security features. Sections 5, 6, and 7 present the vulnerabilities found in the evaluation in the areas of disclosure, integrity, and denial of service, respectively. I suggest improvements to WebStore to correct some of the security problems discovered in Section 8. Finally, Section 9 concludes the paper with a summary of the project work done.
This section presents details of the WebStore distribution, installation, and product architecture that are relevant to the evaluation conducted. This section does not fully describe the details of WebStore, as they are peripheral to the investigation conducted in this project.
WebStore is distributed as a single downloadable tar archive that is about 500KB in size. All documentation and source come in this single tar file. The only unpacking instructions provided on the Extropia web-site are recommendations for Windows users to look for Windows-based tar tools at Shareware.com. Unfortunately, this leaves the installer no clue as to what options to use with tar to unpack the archive. After unpacking the archive, the user can read the installation instructions that clearly outline the correct options to unpack the archive.
Perl-based CGI scripts construct the WebStore application suite. These scripts work in conjunction with an already installed web server on an Internet Service Provider (ISP) or on a web server installed by the user installing WebStore. Since the package is written in Perl, the experienced Perl programmer can customize WebStore without the hassle of recompilation. Additionally, Perl provides some level of platform independence.
Knowledge of Perl is not required to install and use WebStore. The documentation provided walks the installer through the process of entering product-specific data to customize WebStore to the particular business that it is supposed to run. After this data has been entered, WebStore is ready to run in its default configuration.
The basic operation of WebStore involves keeping miniature databases, called shopping carts, of each customer’s selections while the customer is shopping. These shopping carts provide continuity to the shopper during the shopping session. At the time of purchase, an SSL-based connection is made between the server and the customer to transfer payment data. Payment information is then e-mailed to the address specified by the installer when setting up WebStore. An additional option, not selected by default, is to log the order information in an administrative log file. The sales cycle is completed when the administrator processes the order from the received e-mail or the administrative log.
Three categories of security threats are commonly used to classify most attacks on computer systems. These three categories are disclosure, integrity, and denial of service (DoS). Disclosure attacks are those that allow private information to be discovered by an unauthorized source. Integrity attacks are those that allow private information to be tampered with by an unauthorized source. Denial of service attacks are attacks in which an attacker ties up resources to prevent their legitimate use.
In my investigation, I wanted to look at WebStore for vulnerabilities in all of these categories. To assist in developing a consistent methodology, a threat tree [AM] was developed to begin the investigation. After the initial threat tree was developed, WebStore was evaluated and the threat tree was expanded in areas where specific vulnerabilities were discovered. This process was then repeated until no further vulnerabilities were discovered. The resulting threat tree is shown in Figure 1.
The process of evaluation consisted of source code and documentation review. No attempts were made in the analysis process to actually penetrate WebStore or any of the platforms that it could be installed on.
Figure 1. Threat Tree for WebStore Evaluation
In its "out of the box" configuration, WebStore does configure a set of security features when it is installed. These features target disclosure and integrity threats from users snooping around files in WebStore. Three features of WebStore in its default configuration can be considered security features. The first feature is placing an index.html file in every directory of the WebStore distribution. The second feature is providing a permissions-checking utility to verify that the WebStore installation has the correct permissions settings. Finally, the third feature oriented toward achieving a secure WebStore installation is detailed documentation in layperson’s terms explaining the function of all of the files within WebStore as well as the basic UNIX utilities used in setting up and configuring WebStore.
Placement of an index.html file in every web-visible directory prevents malicious web-surfers from discovering the names of files within the WebStore hierarchy. Without an index.html file, most web browsers provide a directory listing. This listing would show the names of administrative files, which could then be read, as they are readable by web surfers by default in the WebStore installation. WebStore recommends changing the names of these administrative files and possibly relocating them out of web-visible space, but this is a manual process and is not required to make WebStore function properly. Since it is not a requirement to better protect these sensitive files, an index.html file in every directory becomes an important security feature.
Placing an index.html file in every directory prevents disclosure of file names within a particular WebStore installation. Since WebStore is downloadable by anybody with a connection to the Internet, this may be a weak feature if a user does not build upon it by renaming sensitive files or relocating these files. As a further security feature, WebStore provides a CGI script to check a WebStore installation for correctness of permissions on the installed files. This utility can identify possible disclosure or integrity problems prior to activation of an electronic storefront on the Internet. Since most files in the WebStore system need to be able to be read and written by the web server, this tool is more useful to verify that the WebStore installation will actually work. That is, the tool is better at finding permissions that are too strict, rather than too relaxed. I discuss this problem more in the following sections on vulnerabilities.
It is arguable whether documentation is really a security feature or not. In the case of WebStore, I consider the documentation to be a very important security feature for two reasons. The first reason is that WebStore targets a market that may not have the technical knowledge to understand basic concepts in setting up WebStore. Small businesses do not generally have the budget to hire a consultant to set up their e-commerce site. This generally means that somebody unfamiliar with computing technology may end up installing WebStore. Detailed instructions benefit this type of user. The second reason is that WebStore has a fragile security structure that is easy to compromise. Additional detail in the documentation to help an installer get the installation right prevents this fragile structure from being disturbed mistakenly.
In addition to these three default security features, WebStore provides for several optional security features. These features provide additional security infrastructure, but are either disabled by default or require additional work by an installer that may or may not actually happen in practice. Since WebStore does not force a user to adopt any of these practices, they must be considered as potential security features, but cannot be grouped with the default features above.
WebStore offers seven optional security suggestions or features. The first five suggestions are designed to better protect files from disclosure or integrity attacks. The sixth feature is PGP support for customer order information, which is either sent via e-mail or logged. The final security option mentioned in the WebStore documentation is the use of Perl in "taint mode."
The WebStore security documentation states that it is good to rename the administrative files using names that are not "easily guessable" as a minimum measure to prevent malicious web-surfers from tampering with them. Another suggested protection measure for these files is to give them .cgi extensions. This will prevent a browser from displaying them. Instead, the server will attempt to run the files as a CGI script and return a server error when this fails. The final recommendation for these files is to locate them out of web-visible space, such that the server still has adequate access to them. The outside browser then cannot gain access to them through the web server, other than by normal operation of WebStore’s CGI scripts.
In addition to protecting administrative files, WebStore makes general recommendations to help protect the integrity of files. The first general recommendation is to have the system administrator disable CGI on directories that have files that WebStore must write. The second recommendation is to disable server-side includes (SSI), which generate html dynamically as pages are accessed in some instances. Variables provided within the WebStore CGI scripts facilitate the disabling of this feature. The documentation also recommends that the installer ask the server administrator to disable SSI in WebStore’s CGI directories.
PGP [PGP] provides a means of encrypting data using a public-key cryptographic system. This encryption greatly reduces the number of disclosure and integrity threat vulnerabilities on encrypted data by making it more difficult for an attacker to gain unauthorized access to the data. Making access harder to gain often discourages the casual attacker, causing him to look elsewhere for systems to exploit. The WebStore system supports PGP for encrypting customer order information. This information includes credit card data. Unfortunately, PGP is a disabled option by default. The comments in the setup file for WebStore give the reason for disabling this feature as:
"# Do we use PGP Encryption -- WARNING: This is a difficult
# option to setup. You must go into the pgp-lib.pl file
# and edit the pgp variables in the header for your specific
# setup."
The final optional security feature mentioned in the WebStore documentation is to configure WebStore’s Perl scripts to run with Perl in "taint mode." Running Perl in taint mode causes Perl to require that all user input that is to be sent to a system call be checked for validity within the script [PTaint]. Pattern-matching the provided input does this checking. Running taint mode Perl prevents malicious users from providing input that may cause the system call to behave incorrectly, and allow them unauthorized access to the system. This feature is only as good as the pattern matching specified by the user. Proper implementation of this feature requires an installer to have a detailed knowledge of Perl regular expressions and a rudimentary knowledge of Perl.
As a class, disclosure vulnerabilities represent the largest risk to an electronic commerce system. Exploits in this area generally target credit card information. For this reason, disclosure was my primary concern in this evaluation.
Several disclosure threats exist in WebStore. The threats all stem from the fact that WebStore does not encrypt data by default and that sensitive data files must be able to be read and written by the web server. The three main threat classes discovered under the disclosure sub-tree of my threat tree were network-based attacks on e-mail, attacks on the web server host, and attacks on the e-mail destination machine.
The first alarming vulnerability discovered in WebStore was that customer order information, including credit card data is sent to the WebStore administrator via unencrypted e-mail in WebStore’s default configuration. This presents an opportunity for an attacker on the network to snoop network traffic and gain unauthorized access to all order information as it passes from the server to the user’s e-mail system. This threat is dependent upon the structure of the user’s ISP or personal network. In many cases, the WebStore user may have an e-mail account on the same machine that hosts the WebStore installation. In this scenario, e-mail traffic from WebStore to the user will not reach the network. There is no warning in the WebStore documentation that this sort of vulnerability exists. Further, there is no recommendation that the user keep his or her e-mail account for orders on the WebStore server.
The next class of disclosure vulnerabilities found in WebStore is attacks on the WebStore host machine. An attacker that gains administrative access to the WebStore host will have unauthorized access to all of WebStore’s administrative files. This sort of problem is common in application development. Even if WebStore is considered secure, the composition of a WebStore installation and its host OS will be extremely difficult to secure. Numerous exploits are generally available on the Internet [RS] for the various host systems that WebStore might run on. Exploitation of the host OS is not well protected against in the WebStore architecture. In particular, WebStore does not lend itself to operation on a web server that only offers web service, since it also requires e-mail service in its default configuration.
The final disclosure vulnerability discovered in WebStore is the exploitation of the destination e-mail account machine that customer orders are sent to. In the case that these e-mails are sent unencrypted, this is another entry point for an attacker to gain access to unauthorized data.
The primary targets for an integrity attack on WebStore are the administrative files that contain pricing and product information and the record of purchase data. The two classes of integrity attack identified are giving oneself a large discount and tampering with orders before processing. This tampering can result in disabling WebStore. It can also result in destroying order records before their processing by the WebStore administrator.
Similar to the disclosure vulnerabilities mentioned in Section 5, WebStore is vulnerable to e-mail tampering in its default configuration if the server is a different machine than the administrator’s e-mail host. Again, host OS vulnerabilities are not even considered in the WebStore architecture.
The final category of vulnerability investigated was denial of service. WebStore has some unique DoS vulnerabilities. In particular, WebStore does not protect against filling of the user’s disk space with stale shopping carts and WebStore can be rendered useless by an integrity attack on the administrative files containing product data. In addition to these unique vulnerabilities, WebStore inherits the vulnerabilities of the web server and host OS that it runs on.
The first WebStore-specific DoS vulnerability is the creation of multiple shopping carts to fill the allocated server disk space. In the WebStore architecture, shopping carts are configured with a lifetime of twelve hours, by default. This lifetime is an option that an administrator can change. The lifetime of a cart must be sufficient for a customer to complete shopping. If the time limit is too short, the user will lose purchase information midway through browsing the storefront. The fact that the shopping cart is a database file kept on the web server while the user shops leads to this possible DoS attack. By creating a multitude of shopping carts to fill the allocated disk space the attacker can render the store unserviceable until the lifetime of the stale carts expires. This cycle can be repeated indefinitely once the attacker determines the lifetime of the shopping cart.
The second DoS vulnerability is an extension of an integrity attack mentioned in Section 6. If an attacker removes the product information files from the WebStore installation, the store will become unusable until these files are restored to the web server.
Finally, several TCP-based attacks exist that target web servers and host OS’s. These attacks can render WebStore unavailable for business. That is to say, WebStore inherits any vulnerability present in the web server that it runs on and the host OS that the web server runs on.
After completing my evaluation of WebStore, I have come to the conclusion that several simple improvements could greatly enhance the security of WebStore as a product. These recommendations are:
- Make PGP or some encryption agent mandatory for credit card data storage and transmission.
- Force administrative files to exist outside of web-visible space in installation instructions.
- Remove e-mail dependency from default system implementation.
- Include recommendations in documentation to run e-commerce on a "secure server".
- Make installation instructions available on the Extropia web site.
Encryption of sensitive data is considered mandatory in a web browser to web server connection. This requirement should remain in place for all communication between the web server and the WebStore administrator, as the data has not lost any of its sensitivity to disclosure. This is a significant failing in the WebStore architecture.
Allowing administrative files to exist in web-visible space is not a reasonable thing to suggest in the installation of WebStore. Changing the documentation to make relocation of these files a mandatory step in the installation process would help remove this potential source of problems.
Another default behavior that may not be in the best interest of security is the use of e-mail for communication of order data. This default immediately requires that a system be running mail services in order to support WebStore. This also causes the WebStore implementation to inherit any host OS attack threats that come with running these mail services.
Related to the previous point is the concept of running WebStore on a "secure server." The concept of the secure server relates to the concept of least privilege. By removing extraneous services from the machine hosting WebStore, the administrator can remove a significant number of attack points on that system. By hosting WebStore on a fully-featured system the number of system-related security vulnerabilities is unnecessarily increased.
The final point that I recommend is to have installation instructions available on the Extropia web site. I recommend this because the unpacking of WebStore must be done in a certain manner to preserver proper permissions on the files in the distribution. It is not obvious to the installer that this is the case until the files have already been unpacked. This can lead to an installation with permissions set incorrectly. In the best case, the WebStore application will not work correctly. In the worst case, WebStore will work correctly, but outside users will be able to compromise it via the web. Publishing these instructions so that would-be installers can plan accordingly would be very helpful in eliminating this class of error.
In this project, I downloaded and evaluated an Open Source electronic commerce server, WebStore, for security vulnerabilities in the areas of disclosure, integrity, and denial of service. Vulnerabilities were found in all three categories. Two primary problems were discovered in the evaluation process. The first problem is that WebStore does not encrypt sensitive data, such as credit card numbers, in its default installation. The second problem is that WebStore uses standard e-mail to transfer sensitive information from the WebStore application to the WebStore administrator. After evaluating the product, I made some recommendations to make the default installation of WebStore more secure and practical for use in the environment that it is designed to work in. In general, WebStore contains significant security deficiencies and I would not recommend using it in its out of the box configuration.