Incident 2 Teaching Note

The Bombay Martini Bet:
How Did a CPA Firm’s Assurance Team Phreak a Non-networked
Information System of a High Tech Client Needing a "Wake Up Call"?

John E. Howland, Department of Computer Science, Trinity University

Bruce Sidlinger, Sidlinger Computer Corporation

Table of Contents

Introduction to the Incident 2 Solution

Solution to Incident 2

Bruce Sidlinger's Account of the Actual Incidents

Teaching Note Comments From Bruce Sidlinger


Introduction to the Incident 2 Solution

The key incidents in this case actually transpired. Except for Bruce Sidlinger, all people and events are disguised. Bruce was indeed a "newly minted Trinity University graduate." The incidents of the case transpired under somewhat different circumstances than are described in the fictional case. The fictional case is intended to make students think about broad issues of information security, information fraud, and information warfare.

Solution to Incident 2

In the context of Incident 2 as described above, the solution entails phreaking information systems staff to install an "upgrade" disk for the operating system or key software. The steps in the phreaking solution are listed below:

Bruce Sidlinger Wrote the Following Account of the Actual Incidents

Sidlinger Computer Corporation (SCC) was hired by the CEO of a Texas corporation to assess the vulnerability of its VAX/VMS-based DP shop. The DP manager was overconfident of the invulnerability of the security procedures in effect and one goal was to quickly invade the system as a much-needed "wake-up call." This invasion had to be accomplished from the outside as the "sporting proposition" made by Bruce to the CEO was that there would be no charge unless SCC's invoice was delivered to the CEO via *internal* corporate e-mail within the week.

The DP manager was aware of the test and was consequently on special alert. The DP manager's defensive actions included turning off all modems, suspending access to the computer room by cleaning personnel, etc., etc.

The afternoon after Bruce's meeting with the CEO he coincidentally received via FedEx from Digital Equipment Corporation (for SCC's own VAX/VMS system, which was under DEC software support) a FedEx box containing a 9-track magtape with an official Digital label reading "VAX/VMS Mandatory Security Update" as well as a cover letter on Digital stationery advising customers to "install immediately." Receiving a shipment such as this from DEC was a relatively normal occurrence at DEC shops at the time. However, on this particular occasion, it promised a trivially easy method of invasion.

Bruce read the contents of the tape onto disk, enhanced DEC's installation procedure (which was simply ASCII DCL, the VMS scripting language) to also send an invoice to the CEO's e-mail account, installed a write ring on the same DEC tape, and copied everything back. He placed the official DEC tape and cover letter inside a fresh FedEx box, threaded a blank FedEx airbill into SCC's (DEC) line printer, prepared an identical airbill (DEC's return address & FedEx account number) except with the audit customer as the addressee, then dropped his creation into the FedEx depository in front of the local DEC office. (Companies often use home office airbills when shipping from branch offices and FedEx allows this.)

The customer received the shipment and (after checking with DEC by telephone to make sure there really was a mandatory update!) immediately installed it.

Invoice delivered.


Teaching Note Comments From Bruce Sidlinger

On July 26, Bruce Sidlinger sent the following email message to Bob Jensen and John Howland:

Hello, Dr. Jensen (& Dr. Howland). Below is my stab at fulfilling your request for teaching notes. I hope this is still in time to be of use - I apologize for the delay.

Not as an excuse, since I should have started earlier, but for your information, I will tell you what I have been up to this month: A day or two after sending you my June 29th e-mail projecting that I would make my original commitment date, I received a call from the CEO of [XXXXX a large international car rental company]. He told me that they were 9 days into a conversion of their main computer system (serving all of their U.S. and Mexico counters and offices as well as the [XXXXX} reservations system). The conversion had gone terribly wrong and they had been out of service for those 9 days at a cost of $250/minute for the down [XXXXX} connection and an average total loss of about $1500-$2000/minute. The original system designers as well as the manufacturer were out of ideas and the original system had been decommissioned so the conversion was somewhat irreversible. My name had been suggested by two different sources (including the hardware vendor) as a possible "fixer".

He asked me to forgo packing, leave my Manhattan Beach house immediately, and catch the next available flight from LAX to [city YYYY]. They met me at the airport and we proceeded directly to their computer facility, where I worked for the next 29 straight hours, at which point the [XXXXX} connection was restored. Since then, I have been on a 20 hours awake/4 hour's asleep continuous-effort schedule. I have restored service to the 400 most-critical locations. At this, the three-week point, I still have an enormous effort remaining.

Last night I told them I *had* to take a couple of hours off to write what you will find below. Realistically, this is the best I can do and hopefully you can use it as-is or else feel free to edit it or have it edited as appropriate. I would like to give you full authority to do what you will because my ability to further participate in the AICPA project is extremely doubtful until ARAC stops hemorrhaging cash by the minute. The pressure on me (even though this wasn’t my mess to begin with) is extreme. However, the stakes are high and this is what I do best so I don’t regret the assignment, other than to the extent that it conflicted with my prior promises to you.

Once again, I hope this will be acceptable or fixable and once again, thanks for everything.



When considering issues of computer security, it is sobering but important to realize that the deck is stacked almost entirely in favor of the determined cracker. For an invasion to succeed, it is sufficient that ONLY ONE of the attack modes be effective, whereas for an invasion to be repelled, it is necessary for ALL of the defenses to be effective.

The designer must be prepared to compromise between hopefully adequate (but certainly not unbreakable) security measures versus functionality. Especially when considering web-enabled or other Internet-accessible servers, it is not possible to ensure security beyond all doubt. The organizations marketing department typically insists on electronic commerce capabilities while the loss prevention department (or equivalent), wants guarantees against misuse. To resolve this inherent conflict, upper management must be verifiably made aware of the risks so that the proper trade-off can then be made.

The situation is comparable to retailers maximizing net sales revenue less the cost of shoplifted goods. All retailers understand that losses are a cost of doing business. Similarly, the potential for embarrassing and perhaps costly incidents is the cost of doing business on the Web.

When the U.S. military stores sensitive data on a computer, that system is locked in a vault and is not connected to even a local network (much less the Internet!). Anything less than "air-gap" security should be considered intrusion-resistant, perhaps, but never intrusion-proof.

Note that in the subject instance, the system administrator was actually rendered *more* vulnerable by his foreknowledge of the impending attack. In attempting to oppose those who would employ illicit means to compromise a system (or a network, or a web site), one must question everything and assume nothing. In practice, this is extremely difficult: how many managers would have called Digital Equipment Corporation to verify the bona fides of the shipment? How many users will refrain from opening an executable e-mail attachment or running an Excel or Word macro within a received document of unknown provenance? How many web surfers are willing to disable Java and ActiveX on their browsers or limit their searches to certificate-authenticated sites?

The best that can be done is to enforce carefully thought-out restrictions (e.g., floppy drives boot-disabled or disabled entirely) and procedures (e.g., no software installed other than from read-only media such as CD-ROM or authentic, verbatim, write-protected media such as factory-shrink-wrapped floppy disks) and apply automatic measures as well. Automatic measures include locking the system and browser options on client systems (work stations) in a safe configuration (e.g., no Java), running virus scanners on clients, servers, and post offices, and using security auditing software to check everything against known vulnerabilities. It is also almost essential to employ outside consultants on an ongoing basis - internal personnel, even if formally charged with security duties, inevitably are re-prioritized, re-directed, and re-allocated to apparently more-pressing and more-immediate tasks, and the defenses begin to crumble through neglect and entropy. Meanwhile, assuming the target is sufficiently attractive, such as a high-volume or high profile web site, the potential for attack continues unabated.

It is instructive to study the many (both celebrated and obscure) documented intrusions, both to understand and protect against known vulnerabilities and (perhaps more importantly) to realize that a complete defense is unattainable. It is necessary (unless a site enjoys the luxury of "security through obscurity") to accept the probability of an eventual successful attack and have a recovery and response strategy already in place.

It is also important for the computer or network or web site security manager or consultant to participate in private groups of professional peers with aligned interests and good connections to the larger security community and the hardware and software vendors. When a vulnerability is detected by a member of the cracker community there is often a very rapid communication of the attack method to others of similar persuasion (remember, they are motivated by the admiration of their fellow hobbyists). In contrast, manufacturers are loathe to broadcast the details of a "hole" before a fix is in place, not only due to the resultant bad public relations but more importantly, so as not to wake up the rest of the bad guys. This is when the security professional relies on previously cultivated friends for a "heads up" - even if no technical countermeasure is yet available, it is still possible to back up data more frequently, increase surveillance, and warn internal users.

In addition to these informal alliances the organization should be listed in the e-mail reflectors or news groups of the various non-profit security event tracking organizations such as the Computer Emergency Response Team (CERT), and join as well the security announcement mailing lists of its various software vendors.

In short, prevention is impossible but mitigation is a worthy and achievable objective. Substantial technical skill and access to current information are necessary resources. Equally important is the commitment to erect and maintain a defensive strategy, the pragmatism to accept the unpleasant events that may nonetheless occur, and the resilience to recover from, rather than abandoning the mission.


Note to Dr. Jensen:

I did not have time to develop references but I have some ideas to support the above that could be quickly looked up on the web if you or someone else has time:

Celebrated cases (e.g., the FBI web site intrusion of a few months ago)

CERT, etc. (list of security alert mailing lists, e.g.,



NTBugtraq (

Microsoft, Digital, Cisco, etc…

(e.g., Microsoft Product Security Notification Service, MICROSOFT_SECURITY@ANNOUNCE.MICROSOFT.COM)

The Cuckoo's Egg : Tracking a Spy Through the Maze of Computer Espionage, by Clifford Stoll; Mass Market Paperback Reprint edition (July 1995)Pocket Books; ISBN: 0671726889

Thanks again.



Incident 1 Case Incident 1 Solution Top of Present Document
Incident 2 Case Incident 2 Solution Top of Present Document
Appendix 1 to Case Appendix 2 to Case Appendix 3 to Case
Bob Jensen's Documents ACCT 5342 Documents Technology Glossaries