Text File

RISKS-LIST: RISKS-FORUM Digest Monday, 21 December 1987 Volume 5 : Issue 80

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: Re: IBM Christmas Virus (Ross Patterson) Logic Bomb case thrown out of court (Geoff Lane) Repository for Illicit Code (Steve Jong) Roger Boisjoly and Ethical Behavior (Stuart Freedman) Truncation and VM passwords (Joe Morris) Competing ATM networks (Chris Koenigsberg)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, FTP SRI.COM, CD STRIPE:<RISKS>, GET RISKS-i.j. Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97).

----------------------------------------------------------------------

Date: Mon, 21 Dec 87 15:22:26 EST From: Ross Patterson <A024012%RUTVM1.BITNET@CUNYVM.CUNY.EDU> Subject: Re: IBM Christmas Virus To: RISKS list <RISKS@csl.sri.com>

There have been several messages to RISKS lately about the CHRISTMAs EXEC virus on IBM's network. This was an extension of the same problem on BITNET and its European counterpart, EARN. Since I raised the general alarm about it, I'd like to answer a few questions.

The virus used two standard CMS files, called NAMES and NETLOG, to help it infect other users. The NAMES file contains a list of userids and system names that you correspond with frequently, allowing you to abbreviate them to a mnemonic nickname when sending mail, files, or interactive messages. I composed this mail by sending to "RISKS", which my NAMES file lists as user RISKS on system KL.SRI.COM. You can also list phone numbers, paper addresses, etc. There is a commonly available program that will print off a personal phonebook from your NAMES file ("Traveling Sidekick" from the days BB - Before Borland). The NETLOG file lists all users you've sent mail or files to, or received them from. It's a very nice audit trail when you're trying to remember where you got that copy of Space Wars.

After typing the Christmas Tree on your terminal, the virus proceeded to read both the NAMES and NETLOG files to get a set of target addresses. It then sent a copy of itself to each of them, and finally deleted itself.

>From: davy@intrepid.ecn.purdue.edu (Dave Curry) >Subject: IBM invaded by a Christmas virus {RISKS 5.72} > ... >This article seems to have a lot of things in it that the reporter didn't >understand. I assume that the "terminals" in question are really PC's >connected to the mainframes; for one thing.

The terminals mentioned are generally IBM 3270's, and PC's with IRMA-type cards. The virus ran on the host system, not on the PC.

> Plus, I presume the "Don't >browse it" refers to the VM/CMS "BROWSE" command used for looking through >files, and not just to the regular English word.

Both, actually. The intent was obviously to stop the reader from going further down into the file, where the real purpose of the program was quite obvious. The language used (IBM's REXX) is usually interpreted, so the program was sent in source form. Anyone who bothered to read below the second screen-full (like all of us paranoid Systems Programmers) began to see the trouble. It was slightly cloudy, as all the variable names were in German, but seeing was fair to good.

>Subject: IBM Xmas Prank {RISKS 5.79} >From: Fred Baube <fbaube@note.nsf.gov> > ... >"The culprit is unknown

That is no longer the case. The culprit has been tracked down, and barred from access to his/her system. A note to that effect was broadcast to a number of mailing lists by the General Secretary of EARN. The source system had recently been attached to the West German section of EARN, and the user who started it all only intended to send a greeting to a few friends. To quote a TV commerical, "... and they'll tell two friends, and so on, and so on, ...".

> .. but preliminary investigation suggests >that the message originated outside the company. IBM's mail >system is attached to those of several other institutions."

Quite so. No one seems quite sure which of the gateways between BITNET/EARN and IBM's internal network, VNET, passed the first copy of the virus. It matters very little, since it found the VNET environment even more conducive to reproduction than BITNET/EARN. VNET'ers apparently keep much larger NAMES files than BITNET'ers. It wasn't long before the links were carrying more CHRISTMA EXEC's than anything else.

>"From start to finish, the message survived only hours .."

Per copy, perhaps. The first known instance of infection was at about 1300 GMT on Wednesday, December 9. Within BITNET, it was generally stamped out by the following Monday, December 14. On VNET, it didn't show up until a day later, and was mostly killed in a massive network shutdown on Friday.

>... >Questions: >(1) An incoming message can contain an executable program, > that can easily be run ?

Yes. Please remember that the Internet is not the only network style in the world. In BITNET and VNET, mail is just another case of file transfer. File transfer is performed by the sender, not the receiver. These are store-and-forward networks, so the path from system A to system B need not be intact for the duration of the transfer. The viral program was transferred as a normal file, not as mail.

>(2) Such a message can be remailed under its contained program's > control, presumably with the name of the last victim in the > "From:" field ?

It wasn't mailed. Thus, there wasn't any From: field, etc. It did carry the system name and userid of the most recent victim, but not any trace-back information.

>(3) Can IBM trace it to an originator, or was anonymity possible ?

A task force of BITNET and EARN systems programmers traced it back to its source, by the usual disease-control procedures:

Doctor: "Miss X, you've got a nasty case of viral <Y>. Who have you had contact with recently?".

Miss X: "Just a moment, I'll check my notebook."

A byproduct of the tool used to transmit the virus is an entry in the NETLOG file listing the userid and system name of anyone it was sent to, making it easier than usual for Miss X to remember. In some cases, the user had suppressed the NETLOG facility, but that is the exception, not the rule.

>(4) How/where can readers of RISKS submit something similar ? > (strictly for professional testing purposes)

Noplace safely. Please don't try it on anything but an isolated network, and then coldstart your spool afterwards.

>(5) Is the Internet similarly vulnerable ?

Not to this one. It plays on several things that the Internet doesn't have:

1) A large number of IBM VM/CMS systems. The program would only run in a CMS environment. There is no reason one couldn't write something similar in any other language, though.

2) A suitable file transfer system. FTP doesn't apply. It must provide a way for a user to receive an unsolicited file, in a runnable form.

3) A good method of determining targets. The CMS NAMES and NETLOG files provided an excellent source of information. I suppose in a Unix environment, ".alias" and "/etc/aliases" would be ok, but .alias is comparatively rare, while NAMES files are almost universal in CMS.

>The prank seems to be benign, and therefore beneficial.

That is being debated in several circles. I, for one, agree with you.

>IBM seems to have dealt with it effectively (or have they ?).

Yes, they have.

>Browsing this message is no fun at all. Just type Christmas ..

The lesson of this one is the same as for PC viruses: Never run something you don't recognize. When the virus first appeared, several people suggested that it was the work of students, and that it might be used negatively in an ongoing argument over whether students belong on BITNET. When we heard that "professionals" inside IBM were also running programs they didn't recognize, that particular suggestion vanished.

This virus was quite sly, in that by sending itself to people listed in your NAMES and NETLOG files, those people would recognize the source (you) as a friend, and be generally less inquisitive, until things got nasty. Lesson #2: Even your friends sometimes make mistakes. Ross Patterson, Rutgers University

[RISKS received an unusually large number of messages on this subject -- from Fred Baube, John Owens (2), Allan Pratt, Anne Louise Gockel, and Bruce O'Neel. I started trying to edit them down, but rapidly gave up that strategy -- inordinate overlap. So, I will take a new tack, which is to put out Ross' message -- which was the most comprehensive -- and then give Fred, John, Allan, Anne and Bruce first priority if THEY wish to comment marginally or additionally thereupon. Please be terse -- and avoid replicating ALL of the foregoing text in your messages, as some of you have been doing. (One of the joys of mailers?) PGN]

------------------------------

Date: Mon, 21 Dec 87 16:03:05 GMT From: "ZZASSGL" <ZZASSGL@CMS.UMRCC.AC.UK> [Presumably Geoff Lane] To: risks@csl.sri.com Subject: Logic Bomb case thrown out of court

As I have not seen anything about this in RISKs yet ... The case brought against James McMahon, who was accused of placing logic bombs within the computer system used by Pandair Freight, has been thrown out of court because of "unsatisfactory evidence". The judge has ruled that there was no case to answer. This was reported in Computer Weekly dated December 17/24, 1987.

It will be interesting to learn in what way the evidence was unsatisfactory. There used to be a problem in British law(and it may still exist) in that evidence could only be given by humans. Information generated by a computer without the explicit involvement of a human could not be used in court. I may have got this legal point garbled as I don't speak legalese.

Geoff, UMRCC

------------------------------

From: jong%delni.DEC@decwrl.dec.com (Steve Jong/NaC Pubs) Date: 21 Dec 87 16:23 To: risks@decwrl.dec.com, JONG@decwrl.dec.com Subject: Repository for Illicit Code

If there is a legitimate need to study illicit code such as viruses and embezzlement routines, and not just a forensic need to try and track down the author, then there could indeed by a need for a repository. I suggest the model of the Center for Disease Control in Atlanta, which has samples of pathogens. However, note that there was (is?) a controversy surrounding CDC's wish to keep samples of smallpox, which, it is believed, has otherwise been eradicated from the face of the earth. Why leave one known source?

Personally, I'd just as soon not have the code samples around. I'd just be tempted to play with them. (Disclaimer: I'm not a programmer.)

[Program viruses, Trojan horses, etc., will never be competely eradicated. They tend to re-erupt spontaneously or be rediscovered. PGN]

------------------------------

Date: Mon, 21 Dec 87 13:20:18 EST From: Stuart_Freedman@BKR.CEO.DG.COM To: risks@csl.sri.com Subject: Roger Boisjoly and Ethical Behavior

To add my $0.02 to the conversation on Roger Boisjoly, I agree with Ronni Rosenberg, having seen a videotape of him telling his story. I seem to recall that he made reference to the same period of silence (the last time anyone called for objections to the launch) that Henry Spencer did. Boisjoly said that he was much too astonished at the decision to go through with the launch (despite his strong objections) to say anything at that point. He did not fully recover his senses until after the teleconference ended. I think that we can only expect the man to be human; we can't always act heroically when we're in shock...

Stuart Freedman stuart@bkr.ceo.dg.com or rti!xyzzy!freedman@mcnc.org Data General Corp.(Mail Stop E-219), Westboro, MA 01580 +1(617)870-9659 Pick an e-mail address -- any e-mail address...

------------------------------

Organization: The MITRE Corp., Washington, D.C. To: risks@csl.sri.com Subject: Truncation and VM passwords Date: Mon, 21 Dec 87 10:24:46 EST From: Joe Morris (jcmorris@mitre.arpa)

In RISKS 5:79 Alex Heatley reports that he can establish a password of more than eight characters in the IBM VM system, but that on login the system truncates the entered password to eight characters, then (correctly) reports that it fails to match the one in the access control file.

I don't know what security system his system uses, but IBM's DIRMAINT product, which is probably the most widely used directory maintenance facility used in VM installations, refuses to accept an oversized password. I just tried to enter one on our system, and was rebuffed with message DVHDIR017E.

Joe Morris (jcmorris@mitre.ARPA)

------------------------------

Date: Sun, 20 Dec 87 22:22:24 -0500 (EST) From: Chris Koenigsberg <ckk+@andrew.cmu.edu> To: risks@csl.sri.com Subject: competing ATM networks

The two competing local ATM cards in Pennsylvania are Cashstream and MAC. All the Pittsburgh banks with ATM cards are signed up for one or the other local networks. Cashstream is run mainly by Mellon Bank, MAC mainly by Pgh. National Bank. Both Cashstream and MAC extend into neighboring states. Meanwhile Cashstream is hooked up with the national ATM network called CIRRUS, while MAC is part of the national PLUS system.

I've used my Cashstream card in CIRRUS machines in other faraway states, and I've used my MAC card in PLUS machines across the country. But I always assumed that these two kinds of cards were big competitors at each level : bank vs. bank, local net vs. local net, and national vs. national, and that the two sides wouldn't cross.

But in New York, there are ATM machines which accept both MAC and Cirrus cards. I was surprised, since in Pennsylvania, MAC cards work in PLUS machines but not in Cirrus machines, as MAC's local competitor Cashstream is connected with Cirrus.

------------------------------

End of RISKS-FORUM Digest ************************