Cover V10, I05
Article
Figure 1
Figure 2

may2001.tar


Preparing for the Script-Form Attack

Gilbert Held

Today we live in an electronic era, with the use of the Internet growing by leaps and bounds. Along with this growth, we have unfortunately witnessed an increase in the distribution of viruses, denial-of-service (DoS) attacks, and the break-in and modification of home pages on Web servers operated by government agencies, commercial organizations, and academia. The purpose of this article is to acquaint readers with a relatively new type of network-based attack that can cost your organization money. I will describe what I call a "script-form" attack; I will first examine how this attack can occur, and some prevention methods.

Overview

The Web has changed the way many businesses operate. The Web is a valuable place to obtain information and to shop. In addition to mailing brochures, many organizations highly automate their Web presence. Thus, brochure requests generate lists of mailing labels that require little human intervention. When you consider the cost of postage, it is quite possible that every form filled out by an Internet surfer winds up costing more than five dollars when the cost of the brochure, the envelope, and the postage are included as factors.

While it is often difficult to explain the logic behind network attacks, we know they occur and although I'm hard-pressed to determine why anyone would cause an organization to spend needless funds shipping brochures around the world, it is a vulnerability to consider. Because we live in an era of automation, the repeated completion of a form by a script using a database of names and addresses represents a "script-form" attack and is the focus of this article.

I examined several Web sites offering books, brochures, and other literature. The creation of a script to execute a form was easy to accomplish. According to the FBI, because no break-in to a computer actually occurs, this attack may not be punishable under existing computer law. However, various postal regulations and local fraud statutes may be violated when the value of mailings reaches a level defined by a statute. In any event, rather than depend up the law for a remedy after the fact, taking some appropriate steps now can result in preventing your organization from becoming the victim of a script-form attack.

How the Attach Operates

I considered several Web sites for my examples. Because the motto of Lexus is "in the relentless pursuit of perfection", I thought the Lexus Web site would be a good test location. Thus, I've used that site to illustrate the fundamentals of the attack method and see whether the site was programmed to avoid this type of attack.

Figure 1 illustrates the top portion of the form generated by the Lexus Web site when a surfer requests a brochure. The visitor enters a name, email address, and can then select up to two brochures. Clicking on the button labeled "Request Brochure" results in a new screen, which uses some of the previously entered information to fill entry boxes. The visitor is required to enter a mailing address, indicate whether they wish to be contacted via email, and provide information about the vehicle currently owned, and which vehicle they are considering. The top portion of the second screen is shown in Figure 2.

In Figures 1 and 2, note that many fields and the selection of entries from drop-down menus are optional. To complete this form, I used the name of my dog, "Gizmo", giving him the last name "Best". Because my dog does not have an email account, I clicked the box to decline future emails. If you scroll to the bottom of the screen shown in Figure 2, you will see the "Reset" and "Submit" buttons. Clicking on the latter results in the submission of the forms and the arrival of two brochures for Gizmo to sniff and use for training beyond the subject of this article.

Now that I've described how to complete a form to request a brochure, I'll discuss how this apparently safe and harmless promotion of products can result in an opportunity for hackers. Assume someone decides to create a script and a database of ten names, addresses, and fake email addresses. Because most Web forms represent a front-end to a back-end database, most Web sites simply either compare the name and address entered on the form to the entries on the database, or perform a matching operation based on an email address. Thus, it is not too difficult to fool the Web site database and request multiple brochures.

Returning to the hacker's database, suppose the script cycles through it, selecting one name and then using each of the addresses and email addresses to generate ten brochure requests. Next, the second name in the database is selected, and each of the ten addresses is used to create ten additional brochure requests. By the time the last name cycles through the address-matching algorithm, the ten names and addresses can be used to generate 100 requests. If instead of 10 names 100 or 1000 were used, the number of unique requests can considerably increase.

What happens if the database also checks email addresses? Wouldn't this put a stop to all requests after the first ten? Yes, but note that it is very easy to perform string manipulation. Thus, the first time through the cycle each email address could include a numeric prior to the "at" (@) sign that separates a user's email name from the domain name. A simple algorithm then could be used to update each email address so that it would appear to be unique (e.g., gbest1@yahoo.com, gbest2@yahoo.com, and so on).

Another area that deserves a bit of elaboration is address checking. Some organizations implement address checking to ensure that multiple brochures are not sent to the same address. Thus, changing "Gizmo" to "Bismo" would preclude a new set of brochures being mailed to a common address. Unfortunately, there is a very easy method that can be used to bypass pure address checking. Since addresses are commonly compared as strings, the suffix of an apartment number can be used to throw off the entire address checking mechanism. To verify this fact, I modified the apartment number associated with my dog's address and approximately one week later received a sufficient number of brochures to paper train a family of pets. Thus, the relentless pursuit of perfection does not appear to have achieved perfection.

Because the hacker may not care if all the brochures are actually delivered, another addressing technique is incremental addressing. Under incremental addressing, the attacker foils address checking by incrementing house numbers, such as 4736, 4737, 4738, and so on.

There are many form-processing loopholes that make a script-form attack a viable tool for a hacker, but let's look at prevention measures. In doing so, we can start off with some common sense.

Prevention Measures

A script-form attack can be highly successful and cause financial distress when a company loses sight of how its operations perform. For example, if your organization receives an average of 50 brochure requests per day and suddenly that number jumps to 1000 or more, something may be amiss. Thus, daily reports concerning brochure requests or an exception report indicating when requests exceed a certain predefined threshold can serve as a good warning mechanism.

Database Considerations

A second important area is the mechanism used to ensure your organization has a brochure request database and to correctly check that database prior to electronically fulfilling the request. For example, some organizations that I researched either do not maintain a brochure request database or, if they do, their software does not access the database. At one site, I submitted a dozen requests for a brochure using the same name and address and approximately a week later watched the mailman try to squeeze 12 packages into my mailbox.

Preventive Medicine

Although there are numerous variations that can be used in a script-form attack that can drive a programmer mad, there are certain checks that can negate the potential effect of this type of attack. One method to consider is an IP address check between successive requests occurring in a short period of time. For example, assume the IP address 198.78.46.8 is used for issuing a series of brochure requests. While possible, it's unlikely that the use of the Dynamic Host Control Protocol (DHCP) by an organization that is assigned the Class C network address of 198.78.46.0 dynamically assigned that address to two Web surfers that just happened to request a brochure from your organization. Instead, successive brochure requests using the same IP address but different names or mailing addresses can be suspected of a script-form attack.

While IP address checking between successive brochure requests is a valuable weapon, it is not foolproof. A person could take advantage of DHCP and disconnect from the Internet after each brochure request, then re-dialing and reconnecting to the Internet would result in a new IP address. Someone capable of programming a script-form attack probably has sufficient knowledge to place the script within a program that initiates an Internet connection, issues the brochure request, disconnects, and then repeats the sequence again and again. Thus, a bit more effort may be required to minimize the vulnerability of your organization to a script-form attack.

Minimizing Vulnerability

Because every form to request a brochure requires a name and address, those variables represent the best form entries to check. Assuming your organization maintains a brochure request database, coding should be developed to check the street address using string manipulation. For example, assume the hacker entered address if 4736 Oxford Road Apt 21. Through string manipulation, you should temporarily strip any address entry after Road, Circle, Drive, or any normal single family address. Then, your software should perform a search of the database against the entries "4736 Oxford Road" and "Oxford Road". That search should be case-insensitive to prevent any moving sequence of capital letters adversely effecting the matching process.

If a match occurs against the current brochure database for 4736 Oxford Road, it is possible the address is an apartment or an office building. Thus, a good program would incorporate a checking algorithm that continues the scan of the database when a match occurs. Because it is possible that several people in a large apartment complex or office building could request brochures, you probably want to allow some repeated requests from the same basic address. However, if those requests become excessive, it might be a good idea to either generate an exception report or place a limit on the number of brochure requests that will be sent to a basic address. Similarly, suppose you obtain a match for "Oxford Road" in the same zip code. While it's possible two or more people on Oxford Road with the same zip code request a brochure on the same day, what is the probability of ten requests, or a hundred, or more? Thus, another cutoff when a street name match occurs within the same zip code is recommended. However, instead of simply not letting the requested proceed, a message asking them to call in their request might be helpful.

Summary

The script-form attack does not appear to violate current Federal security laws because there is no actual break-in into a computer system. However, a sufficient number of brochure requests could violate both local and postal statutes as it represents a fraud upon the Web site operator. Rather than waiting for legal representation to determine your organization's rights in the wake of an attack, it is best to consider preventative measures to minimize the potential for such an attack. Thus, as the old adage states, "proper planning prevents poor performance", and in the case of marketing on the Web, it can also save your bottom line.

Gilbert Held is an internationally known award-winning author and lecturer. Gil is the author of over 40 books and 250 technical articles. Some of Gil's recent publications include Cisco Security and Cisco Access List Field Guide, both co-authored with Kent Hundley and published by McGraw Hill. Gil's new book, Bulletproofing TCP/IP Networks, will be published by John Wiley & Sons during the first quarter of 2001. Gil can be reached via email at: gil_held@yahoo.com.