Practicing what I preach: How I set up a secure e-commerce site In Part 1, we evaluate the design and implementation of the site

March  1997

Contrary to what Web-marketeers would have you believe, designing, implementing, testing, and rolling out a secure Internet commerce facility is still no mean feat. Having just completed such a task, I'm dedicating this column to exploring the hills and valleys, volcanos and chasms that such a project encompasses. Hopefully you can use the lessons learned to make your Web site implementation a smooth and easy journey.

Also in Pete's Wicked World this month: the bookstore has a a pointer to an interesting paper about spoof attacks and ways to prevent them. In the buglist, several bugs that may occur at your site that could allow root access to your servers. And, if you have Solaris security questions, visit Pete's Security FAQ. (2,000 words)

Mail this article to a friend

A long, long time ago (well, early in 1996), my company (CTI) responded to a "request for proposals" from a large New England-based bank (herein after referred to simply as, "The Bank"). The project was to be a technology proof of concept. The question was, can a bank communicate securely over the Internet with its customers? Of course, because CTI's forte is implementing Internet/intranet solutions, we responded to the request. We won the project, and then had to implement. That's when the fun started.

     There are two things to be considered with regard to any scheme. In
     the first place, "Is it good in itself?" In the second, "Can it be
     easily put into practice?"  


     --Jean-Jacques Rousseau

Therefore, there were several challenges that needed to be solved for the successful implementation of the project:

1. Incorporate secure, authenticated communication between generic Web browsers used by customers and the facility.
2. Convert the check image files into something readable by Web-based customers.
3. Securely transfer the customer information and check images between the mainframe and the new facility.
4. Architect and build a secure facility to provide this functionality, assuring enough performance to handle the expected load. Meet time and dollar budgets.

By working closely with The Bank and The Marketing Company that designed the look and feel of the Web site and managed the project, we thought we'd found solutions to these problems. The secure communication was to be provided by V-One's SmartGate software. The image translation was to be done my Xenos' Corridor product suite, and communication to the mainframe could be done via simple file transfers between the mainframe and the facility.

SmartGate
SmartGate uses public key and DES encryption to provide two-way authentication and 56-bit encrypted communications. It's application independent and runs on a variety of machines (PCs and Macs). It's also very efficient because it uses DES encryption for the majority of communications. A combination firewall/SmartGate server can be used to limit access to a facility and ensure only encrypted and authenticated connections are allowed.

The first step in setting up a SmartGate client is registration with the SmartGate server. The registration captures pertinent user information and exchanges DES keys via public key encryption. Of course the server can be configured to allow anyone to register or to restrict registration, so control is maintained over who can communicate with the server. The DES keys are the ones used to encrypt SmartGate sessions.

SmartGate client operates as a separate program on the user's machine. It's called automatically by network-aware applications. It does this by adding a shim above the TCP part of the protocol stack on the client machine. The applications on the PC then proxy through that shim. The SmartGate client determines whether or not the destination system is running the SmartGate server. If not, the connection goes through as usual. If the server is SmartGated, the client negotiates a session with the SmartGate server and creates a DES-encoded channel. The client-side keys are encrypted via a PIN. SmartGate is therefore two-party authentication: the client must have a token and a PIN before authentication occurs.

The SmartGate keys themselves are stored either on a smart card, or on a virtual smart card in the form of a file on the PC. The matching key is stored on the SmartGate server in the facility. The bottom line is that any communication sent to the appropriate port on the PC and destined for a SmartGate server site is encrypted and two-way authenticated. The client is assured that it is communicating with the stated server, and the server knows who the client is. When a connection is made from the client to the server, no login or other manual user intervention is needed. Rather, the server can greet the customer by name as soon as the SmartGate connection is made.

Corridor
The Xenos suite consists of a mainframe program which tags the mainframe format with keys that are used by a Unix-based program. The Unix program transforms this data into PDF files, which are then readable by Adobe Acrobat or the equivalent browser plug-ins. Net result: images of checks viewable via standard browsers on Microsoft Windows-based machines.

The Proposal
With these two tools in hand, the rest of the goals were within reach. Unfortunately, both tools were in the late stages of development. Welcome to the bleeding edge.

Figure 1 shows our first proposed architecture.

In this architecture, the facility was separate from the Internet by a firewall. It was also separated from the current bank computers by a firewall. Customers would be mailed the SmartGate software (and possibly a browser) to be installed on their machines. They would use a virtual smart card for key storage. The client machine would then talk to the facility through the Internet firewall. First stop would be the authentication server for SmartGate server authentication and decryption. The Web requests would then hit the application server, where the Web server software would communicate with a database to store customer state, customer preferences, check images, and usage information. This database would be fed by files transferred from the mainframe via the administration firewall. (The Xenos software was assumed to run entirely on the mainframe.) Customer service reps would have PCs and physical smart cards (read by a card reader on each PC) and be granted access based on those cards.

The proposed facility was based on Sun workstations and servers. Based on the estimated traffic to the site, an UltraServer 4000 as proposed as the application server. This server was to run the Netscape Commerce Server and Oracle. A SPARC Storage Array (SSA) was included to store the check images. Because the images were going to be kept on line for three months, the storage requirements were significant. Based on estimates, 10 gigabytes of disk space would be needed in the first year to store the statements.

     Mankind always sets itself only such tasks as it can solve; since,
     looking at the matter more closely, we will always find that the task
     itself arises only when the material conditions necessary for its
     solution already exist or are at least in the process of formation.

     --Karl Marx

Bug of the Month Club
In the category "yet another significant breaking" (YASB, I guess), the machine holding the master source code for FreeBSD, a free version of Berkeley Unix, was penetrated. The cracker(s) attained root access to the system and left behind Trojan horses to trap incoming and outgoing passwords and create backdoors to allow further access. Fortunately, due to the way in which the FreeBSD source code is distributed and managed, it would have been very difficult for a back door to be slipped into FreeBSD. In fact, examination of the code so far shows no signs of tampering. The break-in itself was apparently fairly easy to accomplish, due to the fact that the machine had several known security holes left unblocked and unpatched. For the complete details, check out the Usenet article. There is a serious security hole in INN version 1.5.0 that allows arbitrary execution on machines on which it runs. The details are available in CERT advisory 97.08. There is also a bug in a CGI script that ships with some Web servers. The script is called nph-test-cgi_script and is designed to return information about the Web server. The script's bug allows viewing of listings of files that shouldn't be readable by Web clients. The servers affected include NCSA HTTPd and older versions of Apache. See the CERT advisory (97.07) for more details. Another serious bug is related to the rlogind daemon. This bug allows execution of arbitrary programs on the target system. Because rlogind is set-uid root, the programs run as root. Not good. The bug is caused by monkeying with the TERM variable that is sent along with other information by the rlogin program. The TERM variable, when stored by rlogind, can overwrite buffers and cause arbitrary program execution. Details again are from CERT, in advisory 97.06. In even more discouraging news, there's a bug in talkd that allows arbitrary program execution as root. The exploit involves concocting DNS information that is read by the program upon connection request. The exploit information has been published and is being used. Check out the CERT advisory.

The Bookstore
Secure Networks Inc. published an interesting paper that contains details of a spoofing attack based on source routing. The way to avoid the spoof is to turn of source routing, and the paper includes details about doing just that for a variety of operating systems. The paper is recommended reading.

Next Month
Next month concludes the description of the design and implementation of the secure Internet commerce facility.

Resources

• Past Security
  /sunworldonline/common/swol-backissues-columns.html#security
• Also check out the SunWorld Site Index for stories on Web server security
  /sunworldonline/common/swol-siteindex.html#websec
• Related network security stories
  /sunworldonline/common/swol-siteindex.html#netsec
• Peter Galvin's Solaris Security FAQ
  /sunworldonline/common/security-faq.html

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-03-1997/swol-03-security.html
Last modified: