Microsoft Commerce Server 2000 Security Review

  • Article

 

NAI Labs, The Security Research Division
Network Associates, Inc.

June 2001

Summary: This document presents the results of a security review conducted by NAI Labs, the Security Research Division of Network Associates, Inc. on a prerelease version of Microsoft Commerce Server 2000. (21 printed pages)

Contents

Executive Summary
Introduction
Commerce Server 2000 Design
Security Review Project
Security Review Results

Executive Summary

The objective of the security review was to identify weaknesses in the design or implementation of Microsoft® Commerce Server (build 1346.05) that compromise Commerce Server security.

The security review included:

  • An analysis of how the system can be configured and operated
  • A study of the impact of related operating system components, standards, and protocols
  • A consideration of the threat of compromise by malicious users

Microsoft met with the NAI Labs review team members and provided them with design documentation, training presentations, and informal interactions with product managers. The NAI Labs review team also obtained alpha releases of the Commerce Server software in object code only, with the exception of source code for server-side scripts, and a list of Microsoft's security concerns regarding the implementation of some of the Commerce Server components.

The review team conducted a comprehensive security review of the Commerce Server design and implementation, and determined the security issues and potential vulnerabilities discussed in this document. This security review does not guarantee that the review team discovered and identified all possible vulnerabilities, nor that the Commerce Server implementation is completely secure. Furthermore, the overall security of the Commerce Server implementation depends on the secure and proper design, implementation, installation, and configuration of the Commerce Server components, including Microsoft SQL Server and Internet Information Services (IIS), as well as other Microsoft Windows® 2000 features and security components.

NAI Labs reviewed the provided Commerce Server documentation and installed the Commerce Server software to better understand the implementation. The review team also installed and used the Commerce Server services to understand how they can be configured and operated, and to be able to perform penetration testing. The Commerce Server components were analyzed for vulnerabilities, which were associated with potential threats and compromises. Where possible, vulnerabilities were confirmed by performing penetration testing.

The information in this document comes from the following sources:

  • Commerce Server 2000 Help from a prerelease build
  • Commerce Server training at Microsoft
  • Windows 2000 Server Help
  • Installation and use of Commerce Server, as well as general Windows hands-on experience

NAI Labs and Microsoft devoted significant effort to this project. The NAI Labs review team worked for a period of several months and collaborated with Microsoft teams. NAI Labs believes this review has improved the final release of Commerce Server and raised the awareness of security issues within the Microsoft Commerce Server management and development teams.

As a result of its security review, NAI Labs did not find any method of fully compromising a properly configured Commerce Server installation. NAI Labs' penetration testing was unable to compromise any Commerce Server components. However, NAI Labs did identify a number of security issues, which could be considered vulnerabilities if the proper circumstances were to arise.

Introduction

This document presents the results of a security review conducted by NAI Labs, the Security Research Division of Network Associates, Inc., on Commerce Server 2000. The objective of the review was to identify weaknesses in the design and implementation that compromise the authenticity, integrity, or privacy of Commerce Server services. The remainder of the report includes the following:

  • Section 2. An overview of the features provided in Commerce Server.
  • Section 3. An overview of the security review, including the purpose, scope, methodology, and constraints.
  • Section 4. A summary of the results of the security review, including a brief description of 36 identified security issues and potential vulnerabilities of varying severity resulting from a variety of causes.

Commerce Server 2000 Design

Commerce Server leverages many existing Windows technologies and uses them to provide security. File system security, Microsoft Active Directory, Microsoft Cryptographic Application Programming Interface (CryptoAPI), Microsoft SQL Server permissions, IIS security, and Integrated Windows and Kerberos authentication are some of the technologies used extensively throughout this complex application. Commerce Server also implements some built-in security mechanisms that were not readily available in Windows 2000, such as specific authentication schemes.

Configuration, data storage, network protocols, authentication, management interface, usability, and other critical areas such as privacy are the cornerstone of a secure e-commerce site where users can confidently fulfill transactions online.

Installation

Commerce Server must be installed on systems with the Microsoft Windows 2000 Server or Microsoft Windows 2000 Advanced Server operating system. NTFS is required on the installation path for Commerce Server Setup (by default, C:\Program Files\Microsoft Commerce Server).

Microsoft has also released ready-to-use Solution Sites that you can unpack using Commerce Server Site Packager. These sites are unpacked by default in the C:\Inetpub\wwwroot folder. File system permissions for the C:\Inetpub folder are "Full Control" for everyone. Permissions are inherited from the parent folder, C:\.

Roles

Different components of Commerce Server are managed and run by different roles. The three major roles are site developers, system administrators, and business managers. Site developers are responsible for creating and tailoring e-commerce sites. System administrators are responsible for the deployment and maintenance of the software used by Commerce Server components and therefore require knowledge of Windows 2000 Server, SQL Server, and Internet Information Services 5.0. Business managers are responsible for creating and running e-commerce Web sites. To do this, they use Commerce Server Business Desk, a management tool that hides the details of Web site development. The business manager therefore needs only the knowledge of business goals, strategies, and processes.

Deployment

Commerce Server is a complex application with many components that can be used by small and large customers. Small businesses can do their own installation in-house on a small set of servers, or outsource their installation to an Application Service Provider. Large customers may have several replicated servers with load balancing, fault tolerance, and high availability, and may deploy more than one firewall to separate front-end applications from back-end applications. The following figure shows a deployment scenario for a medium-sized customer. A firewall with three network cards protects both the DMZ and the corporate network. The DMZ contains one server for management purposes (Business Desk server), one server for the Solution Site, one SQL Server, and a mail server. No firewall isolates back-end applications from front-end applications. As a result of this security review, other deployment scenarios have been considered, along with the advantages and disadvantages of each solution. Microsoft provides several deployment scenarios and guidelines in Commerce Server 2000 Help.

Figure 1. Installation with one firewall

Solution Sites

The Solution Sites consist of Commerce Server applications, which are a set of Active Server Pages (ASP) running on the IIS Web server. A particular site typically has two applications: the commerce site itself and the Business Desk application to manage the site. Solution Sites also contain site-level resources (for example, SQL Server databases containing catalog schema and product information) that support the site. Microsoft offers predefined Solution Sites for Commerce Server that are downloadable from the Web: the Retail site (B2C) and the Supplier site (B2B). Also, Commerce Server includes the Blank site, which allows developers to build a site from scratch. The Retail and Supplier sites are meant to jump start the development of e-commerce sites by providing quality production application code which can be tailored for a business' needs without having to start from scratch.

The ASP applications invoke back-end Commerce Server services (typically through Component Object Model (COM) objects) to access site-level resources and to access Commerce Server features, such as targeting and user profiling, to provide personalized content to the customer.

The customer's application is a browser that communicates with the IIS server using the HTTP protocol or the secure HTTP protocol (HTTP over SSL) to view the Solution Site pages. The Solution Site ASP applications can perform authentication using one of the following application-level authentication mechanisms:

  • AuthManager object: A COM object that can be invoked only from an ASP application and which contains, among others, the two methods, isAuthenticated and SetAuthTicket. The ASP application first calls isAuthenticated to find out if the client has already been authenticated. If the function returns FALSE, the client is redirected to a Web page to prompt for user credentials. If the user credentials are valid, the AuthManager object creates a cookie that contains the user ID, a timestamp to reflect the time the cookie was issued, and an expiration time. The cookie is sent encrypted using the Microsoft CryptoAPI. The key used for encrypting the cookie is stored in the Administration database.
  • ISAPI filter using custom forms authentication: This authentication mechanism provides autocookie support where the cookies are created with a globally unique identifier (GUID) and are used strictly for identification purposes. The method also allows a user to log in as a non-Windows (anonymous) user using anonymous thread execution.
  • ISAPI filter using Windows 2000 forms authentication: This authentication mechanism checks the user and password and creates a cookie if the password is valid. You can customize how you authenticate Microsoft Windows logins and use the Active Directory Authentication with this method of authentication.

Business Desk

Commerce Server Business Desk is the Web-based site management tool in Commerce Server that enables the business user to concentrate on the business aspects of an e-commerce site. A system administrator has to create and assign roles for each business functionality. For example, some users may be assigned the responsibility of adding or updating new products to the catalog. However, only the management or the sales department should be able to view purchase reports.

After roles have been defined, system administrators set Windows file system permissions on Business Desk ASP pages to reflect these roles. By default, everyone can access Business Desk. User and role management is done both through NTFS management and the Business Desk Partner Service feature. Business partners can be created in the Business Desk application and assigned various privileges. In that case, Commerce Server performs access control at the application level.

A business user can only view modules for which sufficient privileges have been assigned. Other modules do not show up in Business Desk for that user. For instance, if a user does not have file system privileges to access the Campaign Manager module, the Campaign Manager module is not displayed in the navigation pane.

The client application communicates with the server using the HTTP protocol. By default, the data is not encrypted across the network between the Web client and the Business Desk application, but this setting can be changed through the IIS management console. If Integrated Windows authentication is used, each HTTP request is authenticated with user account information. Business Desk users must authenticate themselves with a login name and password, which are sent using either Integrated Windows authentication or Basic authentication.

The Business Desk application is a set of ASP pages that use COM objects to connect to Commerce Server databases. These COM objects use ActiveX Data Objects (ADO) over TCP/IP sockets to connect to a SQL Server. By default, SQL Server listens on port 1433 for incoming SQL Server requests. The Business Desk application converts ADO recordsets to XML data, which is then transferred over HTTP to the client. Business Desk retrieves the Administration database connection string from the Windows registry and connects to the Administration database using SQL Server authentication. This database stores other connection strings, which are used to connect to business databases (catalogs, orders, campaigns, and so on).

Commerce Server Manager

Commerce Server Manager is a Microsoft Management Console (MMC) snap-in. System administrators use Commerce Server Manager to configure Commerce Server sites and resources. They can manage global resources available to all sites, as well as site resources pertaining to a particular site. Commerce Server Manager can also be used to access Site Packager functionality. For every ASP application of a site, Commerce Server Manager can:

  • Set the non-secure and secure host name and the corresponding IIS application.
  • Enable HTTPS, Autocookie, and Authentication filter.
  • Configure settings for all Web servers running the application.

Commerce Server Site Packager

Commerce Server Site Packager is a tool used to package a site, applications, and resources into a single file, which enables the site to be moved to and deployed on another computer. Site Packager packages an entire site including the parts associated with Internet Information Services (IIS) and SQL Server databases, and parts stored in the file system. It packages the resource property settings that are in the Administration database. For global resources, the only information that is packaged is the information that a site-level resource exists. Most resources have objects that save data along with the configuration information. Connection strings, however, are not packaged because they are different on every computer. When packaging applications, Site Packager searches the IIS metabase on the local computer, and finds the physical folder that is the root for that application. It then starts at that folder and packages all of the subfolders into a new file with a ".pup" extension. Site Packager preserves certain settings in IIS such as authentication settings, access permissions, and ASP pages.

Site Packager preserves most IIS configuration settings for each file and folder. This includes IIS security permissions. It is possible to enable or disable individually each IIS authentication mechanism: allow anonymous access, Integrated Windows authentication, Certificate authentication, Basic authentication and Digest authentication.

Site Packager also preserves application protection settings and rights to execute a script.

Site Packager does not preserve Windows file system permissions. This can pose a security threat, especially for ASP pages that should be executed only by system administrators or business managers. For example, the Solution Sites include the Bdrefresh.asp page, which clears the catalog cache when executed. This could be used as a denial-of-service attack if site users can run this page.

Commerce Server Administration Database

Although your Commerce Server site may consist of multiple computers, the configuration data for the resources for all computers is stored centrally in a single SQL Server database. This Administration database is created automatically during the first installation of Commerce Server and named MSCS_Admin by default. In Setup, you specify the SQL Server computer where the Administration database is created. When installing Commerce Server on additional computers, the SQL Server machine containing the Administration database must be specified. By setting up all the computers to point to this central Administration database, all the Commerce Server computers can be managed from a central console. A single Administration database can be used by all your Commerce Server sites. Alternatively, each server can use its own Administration database. The storage of connection strings and passwords in clear text for all Commerce Server databases in the Administration database is particularly security sensitive.

The Windows registry contains the connection string to access the Administration database. This connection string is used by Commerce Server components before accessing other databases. The main connection string is encrypted using CryptoAPI and a fixed private key independent of any outside parameters. Upon availability of this connection string, all other connection strings can be accessed in the Administration database.

Many components need to access this connection string, including Commerce Server Manager, Solution Site applications, Business Desk application, and Commerce Server Direct Mailer.

Another object, AppConfig, wraps several calls to the three administration objects and makes several standard administration values available. The AppConfig object is also called from ASP pages.

Figure 2. Administration connection string

Data Warehouse

The Commerce Server Data Warehouse is a central database that contains a large amount of data collected from several different data sources, such as Web server log files, the Commerce Server databases, and any other data sources that can be specified. The purpose of the Data Warehouse is to combine all the data from the multiple sources into one common structure, giving the data consistency for the purposes of business analysis. When profile data is initially captured, it is first stored in the Commerce Server databases and the Web server logs. The profile data is imported into the Data Warehouse on a regular basis, as scheduled by the system administrator, by running Data Transformation Services (DTS) tasks. DTS is a SQL Server component used to import, export, and transform data from different data sources.

There is both a physical (underlying) store for the Data Warehouse and a logical schema that provides an understandable view of the data in the Data Warehouse. Commerce Server automatically builds the physical store for the Data Warehouse in SQL Server. When a developer creates code to access or change data in the Data Warehouse, the developer interacts with the logical schema. When Commerce Server processes access data in the Data Warehouse, the processes access the data through the physical schema.

Predictor Resource

The Predictor resource consists of a powerful data-mining engine that provides the business user with predictive capabilities based on the aggregate properties of the entire visitor population that visits your site. You can use this resource to build complex prediction models by specifying what needs to be predicted.

Direct Mailer

Commerce Server Direct Mailer is a Windows 2000 service that is optionally installed with Commerce Server. It is used to target users by sending personalized electronic mail as part of campaigns to sell products to increase market share, introduce new products, or retain customers.

List Manager

List Manager is a Windows 2000 service that creates, deletes, imports, exports, copies, and merges lists of user records. The List Manager can import data from flat files, an SQL Server database, the Data Warehouse, and Predictor resource segments. You can export a list to a flat file and an SQL Server database. The List Manager is used by Direct Mailer to construct lists of users for sending targeted electronic mail.

Profiling System

The Profiling System stores profile definitions, such as user profiles, catalog profiles, and organization profiles. The Profiling System stores profiles by storing their profile instance data (for example, user data and data for any business entities, such as catalogs, products, customers, and organizations).

Product Catalog System

The Product Catalog System is a set of four COM objects that interact with a SQL Server database and expose a powerful API for storing, retrieving, and organizing all of your products. Three Business Desk modules use the COM objects API: the Catalog Designer, the Catalog Editor, and the Catalog Sets modules. You use the Catalog Designer module to define product properties (for example, size, color, and weight), product definitions (for example, book ISBN, title, and author) and category definitions (for example, department, region, and manufacturer), all of which make up the catalog schema. The Catalog Editor module supports adding, editing, and deleting products and categories, as well as importing and exporting catalogs. You can also use this module to define multiple catalogs per site and category hierarchies. The Catalog Sets module supports the creation and modification of catalog sets, where a catalog set is a group of one or more catalogs that are made available to different users or organizations.

Security Review Project

Purpose & Scope

The focus of the investigation was to find vulnerabilities (such as in data authenticity, integrity, and privacy) in Commerce Server, based on a detailed understanding of how the system is configured and operated by design and how Commerce Server components have been deployed.

The scope of the security review included the following:

  • Analysis of the design of Commerce Server components
  • Study of the impact of related and dependent operating system component functionality, including SQL Server, IIS server, and Active Directory
  • Impact of known issues with the design of standard protocols (for example, Integrated Windows and SSL authentication)
  • Penetration testing, where feasible, of vulnerabilities

The security review considered the threat of data authenticity, integrity, and privacy being compromised by malicious users and administrators. The review also considered the same threats conducted by an attacker who has constructed a compromise that can take place transparent to normal user or administrative actions. Specifically the analysis considered the following:

  • Active modification of wire contents by an attacker
  • Passive sniffing and offline analysis of traffic by an attacker
  • HTTP/ISAPI authentication protocol-specific attacks
  • Attacks by computer or domain administrators who have design and implementation knowledge, or attacks that could occur if an administrator were to run a Trojan horse or virus on the system
  • Attacks by domain authenticated users who have design and implementation knowledge, or attacks that could occur if an authenticated user were to run a Trojan horse or virus on the system
  • Attacks by unauthenticated users (for example, users who visit a site anonymously) who have design and implementation knowledge

The scope of the security review included only the analysis of the design and implementation of the Commerce Server components previously mentioned. It did not include any other Windows 2000 components.

The security review included a limited amount of penetration testing meant to apply whatever tools, techniques, and knowledge of Windows 2000, SQL Server, and network protocols to discover and potentially exploit vulnerabilities in the design and implementation of Commerce Server 2000.

The security review team was provided with Windows 2000 Server and Windows 2000 Advanced Server, SQL Server 7.0 with Service Pack 2, and a prerelease build of Commerce Server (build 1346.05).

Methodology

A team comprised of NAI Labs technical staff members with extensive experience evaluating secure systems and performing detailed security reviews conducted the security review.

The review team performed the following work:

  • The objective and scope of the security review was jointly determined to include an analysis of Commerce Server in object code only, with the exception of source code for server-side scripts. The review did not include the review of any other Windows components, such as IIS, Active Directory, or Windows 2000.
  • The review team attended a Microsoft Commerce Server training session to gain knowledge of the product functionality, learn about the security design and implementation, and discuss potential security weak points. The review team talked to program managers, developers, and technical support, and reviewed presentation material and online help files.
  • The team obtained a detailed understanding of how the Commerce Server services were implemented by installing and configuring Commerce Server, and unpacking the Solution Sites in a testbed of four hosts.
  • The team obtained an understanding of how the Commerce Server services are configured and operated by installing and using the Commerce Server services and Solution Sites in different configurations.
  • The team prepared an "as-built" functional security specification reflecting the NAI Labs team's understanding of the security functionality as designed and implemented in the Commerce Server software. The specification was based on knowledge NAI Labs gained during the training session, and by installing, configuring, and running Commerce Server in a testbed.
  • An ongoing dialogue between NAI Labs and Microsoft was established to discuss issues and questions that were raised during the initial phase of the review. Microsoft provided valuable input that helped the review team better understand the security design and implementation. The as-built functional security specification and potential security issues were discussed during a final design review meeting with Microsoft Commerce Server program managers.
  • The review team analyzed the design and implementation for weaknesses and vulnerabilities. The scope of the analysis included both high-level and low-level security considerations. The team analyzed how the architecture could impact the security of Commerce Server; examined information flows and data storage to identify potential weaknesses in data protection; considered installation, configuration and deployment issues; and studied several deployment scenarios for small and large businesses. The team also analyzed the specific case of e-commerce site outsourcing, where a third party hosts several commerce sites, potentially on the same server. Lower level analysis included a review of the use of secure protocols protecting data along network paths, data storage protection mechanisms, as well as what malicious users could attempt to do to Commerce Server by sending viruses, Trojan horses, or carefully crafted or random input to the server. The team also performed an analysis of the Solution Sites ASP source code, having in mind that an attacker can have complete access to the ASP source code by downloading it from the Microsoft Web site. Methods and filters used to perform user authentication and authorization were also analyzed.
  • The review team performed penetration tests, when possible, to test weaknesses and vulnerabilities. This testing included using analysis tools and exploits available online, commercial analysis tools such as the Network Associates CyberCop scanner and the Custom Audit Scripting Language (CASL), sending crafted and random input to Commerce Server, both as a non-registered and registered user, and creating scripts to attempt to retrieve critical data from the servers.
  • Issues and vulnerabilities found during the security review and penetration testing are documented in this report. Other issues were found but are not documented in this report because Microsoft fixed them before releasing Commerce Server. (In those cases, NAI Labs documented the issues, Microsoft development teams fixed the issues, and Microsoft provided feedback to show the remedy for each issue. NAI Labs and Microsoft then jointly determined that the issues had been fixed).
  • The security review team presented all the issues and vulnerabilities during a final review meeting with Microsoft Commerce Server program managers. Discussions followed concerning helping customers with deployment and configuration guidelines documents, improving the security of Commerce Server and fixing security issues, improving the process of the security review, raising the security awareness of development teams and customers, and performing ongoing security reviews to continuously improve the security of new releases.

Security Review Constraints

The NAI Labs review team conducted a comprehensive security review of Commerce Server design and implementation, resulting in the issues and vulnerabilities identified and described in this report. This does not guarantee that all the possible issues and vulnerabilities were discovered and identified. The overall security of the Commerce Server implementation depends on the secure and proper design, implementation, installation, and configuration of the Commerce Server components, including SQL Server and IIS, as well as other Windows 2000 features and security components. These products support a number of different installation options and scenarios that make it difficult to analyze all possibilities.

Several issues affected the security review and penetration testing. The review team was provided with multiple versions of the Windows 2000 and Commerce Server executables during the review. NAI Labs understands that changes are expected during the development phase of a product; nonetheless, it is difficult to provide a complete and accurate analysis on a "moving target." Some scenarios could not be tested due to installation issues with prerelease versions of the product.

Security Review Results

As a result of its security review, NAI Labs did not find any method of fully compromising a properly configured Commerce Server installation. The penetration testing was unable to fully compromise any Commerce Server components. However, NAI Labs did identify a number of security issues, which could be considered vulnerabilities if the proper circumstances were to arise.

During the security review, it was discovered that a number of the issues and potential vulnerabilities appeared to result from a few general areas of the Commerce Server security architecture design approach. These areas include:

  • The storage, protection, and use of connection strings and passwords for accessing SQL Server databases
  • The network topology used to deploy Commerce Server
  • The lack of privileged user or role definitions to perform specific Commerce Server tasks

Issues and Vulnerabilities

Commerce Server issues and vulnerabilities were grouped into the following functional areas:

  • Firewall and Commerce Server deployment
  • SQL Server authentication and database access
  • IIS authentication, execution, and protection
  • Windows ACLs
  • Business Desk

This document also summarizes the penetration testing performed as a part of the security review and the penetration test results.

Firewall and Commerce Server Deployment

Although most of the issues identified in this section require malicious operation under administrator privileges to create a compromise in security, NAI Labs believes the risks associated with these issues are legitimate because users routinely operate their systems (for better or worse) with administrator privileges. Many systems will commonly operate in this manner and potentially encounter malicious software. It is recommended that Windows 2000 system administrators understand the methods of preventing malicious software from compromising a system, such as described in the document "CERT® Advisory CA-1999-02 Trojan Horses," located at http://www.cert.org/advisories/CA-1999-02.html.

Firewall Deployment

There are several ways in which an organization would install firewalls to protect Commerce Server from attacks. NAI Labs suggested single, two-, and three-firewall solutions for small, medium, and large installations, respectively, each with relative advantages and disadvantages.

The single firewall deployment consists of a tri-homed bastion separating a DMZ, the Internet, and the internal network. Advantages for this solution are a single firewall to manage, the internal network does not depend on the DMZ for Internet access, and it is easily implemented into existing architectures. However, SQL Server computers are not separated from IIS servers, it increases the potential impact of IIS server breaches, and the communications between SQL Server computers and IIS servers are in clear text. Furthermore, some firewalls do not support three separate interfaces.

In the two-firewall solution, a second firewall is placed between the DMZ and the production management network. The production management network is more isolated, and the number of machines directly accessible from the Internet is minimized, but there is an increased cost and management for two firewalls and Business Desk users must be on the production management network.

The third solution has three firewalls, which places the internal network behind the production management network and the DMZ is further split. In this solution, Business Desk users can operate from the internal network but there is an increased cost and management of three firewalls.

Microsoft Response

Commerce Server 2000 Help includes several topics about deployment with firewalls. For more information, see Commerce Server 2000\Getting Started\Planning Your Commerce Server Installation\Planning For Deployment in Commerce Server 2000 Help.

Application Service Providers

When Application Service Providers deploy Commerce Server, most of the infrastructure is owned by a third party and may be shared among several customers. Communication paths go over unsecure links such as the Internet. Business Desk users could be located in the company intranet, but the Business Desk server is collocated at the Application Service Provider's facilities. An Application Service Provider may decide to install two or more customers on the same host, especially when the provider hosts small customers. This poses configuration issues that have security implications.

The Administration database stores information for multiple sites. If the Application Service Provider uses that database to store information for multiple customers, then a malicious customer could read or modify database entries for another customer, because Commerce Server administration objects give access to the configuration data of all sites in the Administration database. If the Administration database is shared amongst several customers, one customer can modify another customer's databases, including the Administration database and the Solution Sites databases.

Microsoft Response

Commerce Server does not support shared hosting scenarios. For more information, see Commerce Server 2000\Getting Started\Planning Your Commerce Server Installation\Planning For Deployment\Large Site Configuration in Commerce Server 2000 Help.

Active Directory*—*Domain Controllers

Because business users probably already have accounts on a domain controller, system administrators are likely to use these accounts and assign them to Business Desk roles. The IIS server where the Business Desk application runs must be able to communicate with a domain controller. Another alternative is to set up a domain controller specifically for Business Desk. System administrators will face deployment issues and may have to make trade-offs between security, ease-of-use, and the amount of day-to-day management tasks.

Consider the following example: in a deployment scenario such as the one described previously in Figure 1, Business Desk users are corporate users and therefore already have accounts on a corporate domain controller. The administrator must either replicate users on the Business Desk server in the DMZ or let Active Directory go through the firewall. Replicating users on the Business Desk server can result in additional offline synchronization procedures and administrative tasks, and inconsistencies between replicated user databases. This could also render the system more vulnerable if the firewall is configured to let Active Directory go through. For instance, an attacker compromising the IIS server might be able to access and tamper with the list of corporate users.

Microsoft Response

For information about deployments, including Active Directory, see Commerce Server 2000\Getting Started\Planning Your Commerce Server Installation\Planning For Deployment in Commerce Server 2000 Help.

Log File Transfer

Commerce Server does not provide a method to transfer log files from the IIS server to the server where the Data Warehouse database exists. Currently, log files can be stored in the Data Warehouse by having the Data Warehouse on the same server as the IIS server, or by mounting network drives. Other methods, such as offline transfers, must be implemented by the administrator. One solution is to install two network cards on the IIS server, one for IIS traffic and the other one for management purposes. With this solution, a compromise of the IIS server may result in a compromise of the network attached to the other network card. If the attacker is able to perform passive sniffing on the network, sensitive data contained in the log file could be exposed.

Microsoft Response

Log files should be transferred from the source to a secure location. For more information, see Commerce Server 2000\Deploying Your Site\Securing Your Site\Securing Log Files in Commerce Server 2000 Help.

SQL Server Authentication and Database Access

Database Connection Strings

The main administration connection string is encrypted in the Windows registry. A user cannot directly retrieve the connection string by looking up the registry. However, this connection string must be made available to scripts running on the IIS server, which use it as a means of authentication to the SQL Server computer and gaining access to Commerce Server databases. If an attacker can upload a script, it may be possible to retrieve connection strings and get access to back-end databases.

The Commerce.SiteConfigReadOnly COM object can be used to access connection strings. This COM object hides the steps of going through the Windows registry, decrypting the Administration database connection string and calling the SQL Server database to retrieve secondary connection strings. A connection string contains the password to a SQL Server login in the clear. Because users tend to use the same password for multiple purposes, there is a chance that a SQL Server login password is the same as a Windows account password. This could be used to further mount an attack on the target system.

One weakness with the current scheme is that the connection string is made available to the ASP page. The implementation of the COM object provides the script with the connection string, but this is not strictly necessary.

In order for this attack to succeed, the attacker must be able to upload a script to the Web server. This is not easy to do in practice, but the attacker can use many different methods: social engineering, Trojan horses, viruses, and improper IIS configuration. For instance, the attacker can look for an IIS directory that has the 'Write' permission enabled, which allows uploading a script through the HTTP PUT command.

Microsoft Response

It is important to implement and deploy a production Internet site appropriately. For more information, see Commerce Server 2000\Deploying Your Site\Securing Your Site in Commerce Server 2000 Help.

SQL Server Clear-Text Password

The password for SQL Server authentication is in the clear. A network sniffer may be able to read the password as it travels over the network. Using the current method, it is not possible to distinguish an administrator from a site user. It is not possible to use SQL Server auditing to track user actions based on login names, because both administrators and site users share the same login. The SQL Server databases could be compromised by either an insider using a network sniffer to retrieve the SQL Server password or by an outsider using an uploaded ASP script to gather and use the SQL Server connection strings.

The integrity of the SQL Server databases could be compromised, resulting in modification of commerce site data, such as the modification (lowering) of product prices for the benefit of an attacker and/or the bringing down of the entire site by deleting all SQL Server commerce databases. The attacker could also tamper with SQL Server Agent, backup procedures, database maintenance plans, and logging.

SQL Server Administrative Login

By default, the "sa" SQL Server login has the sysadmin fixed server role, which gives it full access to SQL Server databases, including system databases. Using the sa login is not necessary to connect to Commerce Server databases. An account with the fewest privileges should be used instead. Of course, it is very important to follow the usual password rules for the SQL Server login, such as changing the password regularly and not using simple passwords.

The sa SQL Server login password can be compromised by an outside attacker by retrieving the connection strings, if the attacker can successfully upload scripts to the IIS server, or by an inside attacker using a network sniffer on the local network where the sa password is sent in the clear. The SQL Server password might then be used to compromise the SQL Server databases. The integrity of the SQL Server databases, including the system databases could be compromised.

Microsoft Response

It is a good practice to use a SQL Server login other than "sa" for authentication to the Commerce Server SQL Server databases. For information about the minimum privileges required to access Commerce Server databases, see Commerce Server 2000\Deploying Your Site\Securing Your Site\Providing Access to Commerce Server Resources and Commerce Server 2000\Deploying Your Site\Securing Your Site\Using the sa SQL Server Administrative Login in Commerce Server 2000 Help.

Database Files Permissions on SQL Server 7.0

By default, the Everyone account has full control access to the physical files that comprise SQL Server databases. Anyone with access to the SQL Server computer can tamper with these files as long as SQL Server does not lock the file. Note that many parts of the physical storage specifications are well documented. An attacker could tamper directly with the database, without having to go through SQL Server.

Direct attacks on the SQL Server databases, such as modifying and deleting the databases, can be performed by taking advantage of the open access to the database files, assuming that the attacker has access to the local network and computer where the databases are stored. For example, in SQL Server 7.0, the default ACL for the MSCS_Admin.mdf file (Administration database) allows the Everyone account full control. If the SQL Server computer is not running, the database could be modified if the format of the file is known. Even if the SQL Server computer is running, the database could be deleted for a denial-of-service attack.

The SQL Server databases are vulnerable to attacks by any inside user who has access to the local network and computer where the SQL Server databases reside, or by an outside attacker who is able to remotely execute file commands or scripts on the database computer.

Microsoft Response

SQL Server 2000 modifies the access control lists (ACLs) on the physical database files if the disk is formatted with NTFS. If you are using SQL Server 7.0, it is a good practice to secure the physical database files with the appropriate access control entries (ACEs) for your needs.

SQL Server Database Connection Differentiation

Business users, administrators, and site users share the same SQL Server login to access the database. There is therefore no accountability of who might have abused the login for auditing purposes.

Microsoft Response

This is a limitation of the current release of Commerce Server 2000. For more information, see Commerce Server 2000\Deploying Your Site\Securing Your Site\Differentiating Access to Resources in Commerce Server 2000 Help.

Commerce Site User Data not Encrypted

Commerce site user profile data is not encrypted within the SQL Server databases. A compromised SQL Server database could let an attacker masquerade as one or more site users or steal private information.

Microsoft Response

The Commerce Server Profiles resource does not encrypt data stored within the profiles databases. It is important, therefore, to secure access to the SQL Server databases appropriately. For more information, see Commerce Server 2000\Deploying Your Site\Securing Your Site\Providing Access to Commerce Server Resources in Commerce Server 2000 Help.

IIS Authentication, Execution, and Protection

AuthManager Cookie Replay Attack

There are no provisions against a cookie replay attack. The cookie stores the user ID, an authentication flag, the last login date and time, and the time window. An attacker could sniff the network and grab a cookie that was generated by the AuthManager object for another user. The attacker can use the cookie to impersonate another user while the time window is still valid. An attacker can potentially perform all the actions that a site user normally performs.

Microsoft Response

This scenario is highly unlikely, and it is an inherent design limitation to the use of cookies by Internet Web sites.

Windows ACLs

Windows Services Passwords Can Be Recovered

It is possible to retrieve Windows service account names and passwords from the registry. Commerce Server includes the Direct Mailer, List Manager, and Predictor Windows services. If these services run under the Administrator account, the attacker could get the administrator password. Retrieving service account names and passwords can only be done while running in the context of a Windows account with the SeDebugPrivilege privilege. By default, only administrators have this privilege, so it should not compromise the security of the system. However, an attacker could send a virus or a Trojan horse, or exploit a vulnerability in IIS, and retrieve the passwords for Windows services. If the attack were successful, the attacker would be able to retrieve a list of services running on the host. Because many services run in the context of the Local System or Administrator accounts, the attacker could gain maximum privileges.

Microsoft Response

The Commerce Server services should be run under the context of an appropriate Windows account. This account is specified during Setup and can be changed afterward using the Services MMC snap-in. For more information, see Commerce Server 2000\Deploying Your Site\Securing Your Site\Limiting Access to Commerce Server Services in Commerce Server 2000 Help.

Integrated Windows Authentication

Several versions of Integrated Windows authentication are supported by Windows 2000: LanManager is much weaker than NTLMv1, which in turn is weaker than NTLMv2. An attacker could force a communication to use the weakest algorithm. Integrated Windows authentication is used to authenticate users in several cases. For instance, it is used to authenticate users between a Business Desk client and a server. An attacker could force a Business Desk user to use the weakest Integrated Windows authentication algorithm, and then decode the passwords in less time that it would take with NTLMv2. The attacker would have to intercept a packet sent by the IIS server and modify it so that NTLMv2 would be removed from the list of acceptable providers. The client would have no way to detect that this particular packet had been modified. With current hardware and software, an attacker can break a password that has been encrypted using NTLMv1 in a reasonable amount of time. The attacker could then impersonate a legitimate user.

Microsoft Windows 98 does not support NTLMv2 in the default configuration. When IIS provides a list of acceptable authentication mechanisms, NTLMv2 is the preferred choice, then NTLMv1, followed by LanManager. Therefore, a Business Desk user running Windows 98 would use NTLMv1. In that case, the job of an attacker would be even easier because he or she would not have to intercept and tamper with the packets. An attacker could steal a password and then use it to impersonate another user.

Microsoft Response

A Windows policy can be used to protect against this issue. For more information, see Commerce Server 2000\Deploying Your Site\Securing Your Site\Enabling Only the Most Secure Version of Integrated Windows Authentication in Commerce Server 2000 Help.

"Users" Group Can Read/Execute any Commerce Server File

Any user in the "Users" group is able to execute files installed by Commerce Server. This includes Commerce Server administrative tasks. For instance, a user can create, modify, or delete a virtual root using the Commerce.AdminIIS COM object. A user can also retrieve the administrator password to the SQL Server database.

The following COM objects provide administrative privileges:

  • Commerce.AdminEventLog: write logs
  • Commerce.AdminFiles: create/delete folders and files
  • Commerce.AdminIIS: add/delete virtual directories
  • Commerce.AdminSecurity: manage file permissions

Any user on the Commerce Server computer has access to the Commerce Server components. Any user on the Internet can access those Commerce Server components through an ASP page that refers to those Commerce Server components. This is a threat only if the attacker can upload scripts on the server, which is unlikely.

Microsoft Response

It is important to implement and deploy a production Internet site appropriately. For more information, see Commerce Server 2000\Deploying Your Site\Securing Your Site in Commerce Server 2000 Help.

Catalog Denial of Service

Because Site Packager does not preserve ACLs, the Bdrefresh.asp file on the IIS server is accessible by everybody. Simply pointing to that file will clear the cache. Anyone who knows the URL and parameters for that page could cause the cache to be cleared. This could be the basis for a denial-of-service attack. The performance of the site could decrease dramatically if the attacker frequently causes various caches on the server to be refreshed. It is possible that any attacker on the Internet or internal to the production machine could disrupt service.

Microsoft Response

The Bdrefresh.asp file and other files should have security measures applied on live production Internet Web sites. For more information, see Commerce Server 2000\Deploying Your Site\Securing Your Site\Limiting Access to Your Site in Commerce Server 2000 Help.

Site Packager Does Not Preserve File System ACLs

Site Packager does not preserve Windows file system ACLs. In order to protect sensitive files, site developers and system administrators may have to create users and roles, and set file permissions on specific files. A site developer could create such roles and apply file permissions on the development platform. When the site has been thoroughly tested, it is packaged using Site Packager, and later installed on production computers. However, Site Packager does not preserve file system security settings, which means that by default, these settings are not applied on the production site. Administrators must reapply file system security settings, or developers must provide additional scripts to perform this task. Administrators might forget to set permissions after they have moved the package several times from staging to production. Scripts provided by developers may contain errors. If permissions are not set properly, an attacker could be able to view sensitive files.

Microsoft Response

Although Site Packager does not preserve file ACLs when packaging a site, it does preserve IIS security settings. Also, Site Packager provides scripting hooks that can be used to secure files before, after, or during unpacking. For more information, see Commerce Server 2000\Deploying Your Site\Using Site Packager\Site Packager Reference Information and Commerce Server 2000\Deploying Your Site\Using Site Packager\Using Scripts with Site Packager in Commerce Server 2000 Help.

Business Desk

Basic Authentication*—*Business Desk

Basic authentication and Integrated Windows authentication are the two acceptable authentication mechanisms for the Business Desk application. An attacker could force a Business Desk user to use Basic authentication and then retrieve that user's password. When a Business Desk user double-clicks on the icon for the HTML Application (HTA), Internet Explorer sends an anonymous HTTP request to the Web server. The server responds with an access denied error code and also provides acceptable authentication methods (Basic and Integrated Windows). The attacker can intercept that packet and remove the Integrated Windows method from the list of acceptable methods. The browser will then use Basic authentication, thus sending the password base-64 encoded. The attacker simply has to decode the password, which is a straightforward process. An attacker can also modify the client configuration (either by direct access to the computer or by sending a Trojan horse or a virus) in order to disable Integrated Windows authentication in Internet Explorer. It is possible for an attacker to place himself or herself between the Business Desk server and Business Desk client and gain unauthorized access to the Business Desk management system. This vulnerability combined with other circumstances, such as using the same password for Administrator on the server itself, would make it possible for full compromise and control of the server.

Microsoft Response

It is recommended that Business Desk not be accessible on the Internet unless absolutely necessary. If Business Desk must be accessed over the Internet, it is recommended that it be accessible only with a Secure Sockets Layer (SSL) encrypted connection.

Business Desk Client*—*Server Communication Integrity

The communication between a Business Desk client and a Business Desk server is not encrypted. An attacker could eavesdrop on the communication and/or alter the integrity of the data. An insider could easily install a packet sniffer on the corporate network and grab Business Desk user accounts and passwords.

If the site is farmed out or if the Business Desk user is connecting from the Internet, the communication path uses public networks and an attacker could grab passwords from the Internet.

By default, Business Desk is installed on the same host as the Solution Site and is accessible from the Internet. This could be exploited either by an attacker who would try to guess weak passwords or by a legitimate user on whose communication an attacker would eavesdrop.

Users enter connection strings to configure List Manager through Business Desk. These connection strings could be captured. There is a chance the string contains an administrator password to the SQL Server database.

Microsoft Response

It is recommended that Business Desk not be accessible on the Internet unless absolutely necessary. If Business Desk must be accessed over the Internet, it is recommended that it be accessible only with an SSL encrypted connection.

Risk Mitigation

NAI Labs has identified the following precautions that users and administrators can perform to mitigate many of the risks identified in this report:

  • In order to prevent customers from accessing other customers' resources, Windows file permissions should be set very tightly. A customer should have access only to a limited set of management functions. In particular, the customer should have permissions only on the files for his or her Solution Site.
  • Instead of using the default IUSR account that is created by IIS for anonymous access, each customer should be assigned a specific account.
  • Tell administrators to have different Domain Controllers (DCs) for each site.
  • Add granularity to the Commerce Server environment to allow for shared domains.
  • Minimize users operating with local administrator privileges. Users should minimize the amount of time they spend operating using local administrator privileges. Many of the identified issues are only of concern when operating under a local Administrator account, not when operating under User or Power User accounts. By minimizing the time spent operating with administrator privileges, the user reduces the chance of invoking a malicious process (a virus or worm, for example) that can undermine Commerce Server protection.
  • Install the latest Microsoft security patches and updates. Microsoft frequently distributes critical and recommended security updates that protect against identified vulnerabilities. Administrators should regularly obtain and install security updates as soon as they are available.

© Microsoft Corporation. All rights reserved.